Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Jim Manico <> Thu, 03 November 2016 12:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A479129578 for <>; Thu, 3 Nov 2016 05:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AkoqkBFvTjIm for <>; Thu, 3 Nov 2016 05:48:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E3BC12946E for <>; Thu, 3 Nov 2016 05:48:43 -0700 (PDT)
Received: by with SMTP id p16so27186900qta.0 for <>; Thu, 03 Nov 2016 05:48:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6aPmNpYjVkJQ1+d0mPQ6AQF7YK/D2OR9mPbrrvoiG6Y=; b=HbYJlb4IdY+EqQ7INlJciPZM84PIKRhvLWTw965Mqb4NYMJBBId6++Zxv5l6a7LA95 K/VFmZnwaNAlXGVNioXE6YeBtdL4S6IK8laqhqUDMgNAR5Rm0lG2qoWi4e9m1QbMh+zx B6c49kZcL+zyhR4qZg4r+p2i/c56TczrD2YglC77wYokwPNVkpwy+umoqGa3aV4NkOEU 4d5rns+BvDRdXJ5l+HeJXHS81w4SMNN7MmxbGhsKQFIPNn7YF3TAW6+q76NINaQ2h4wR 6J0ssDFOUkGQJtM1wtm6kxVf1b2hUHluBUk4aOHP2RP77rsdpvcmGOTwzzB4klMdjSzG REZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6aPmNpYjVkJQ1+d0mPQ6AQF7YK/D2OR9mPbrrvoiG6Y=; b=ftmao8Kp9aYdEtSG0TRff0LrxUpccqkMpDjw9rVHEvVBzZgco+2fcCYfC1CvR8TNQA pIpGXv9dNTFWHqGRj4D7LxJkBHxCuJQp6DFewxZDNfTHcECm8ksdCwOLKR5IJJTplDWu 1PHh0Ge/Dg1015YJQwlDS9HyUp4bSkNJijSINKymykiOtpqWYU6b9aNT0Nrr1g8+PEoc wd2sxv9F1c1+O2zMw/7iEuVBrGkD9lY1sqfAov+TG2Q9wFX+zl94rr1hYEFL8UluDjT2 ROOCT/Rlx46b8fDj0+ODIuMP54AW1MNb4XMak6t6u+9e2+OI4bJWUxtjCRtRX3bMgQ3Z MepA==
X-Gm-Message-State: ABUngvfawRj3EqdASTlzKczG0wwP76taNLwZi08kmRbVgleeuy1lcgRVXgOZpEuN+GVwO34m
X-Received: by with SMTP id 5mr7951345qtu.145.1478177322286; Thu, 03 Nov 2016 05:48:42 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id s66sm4273668qkb.17.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 05:48:41 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-7070A0C4-C21F-4D47-8D1C-10580ADA6B8E"
Mime-Version: 1.0 (1.0)
From: Jim Manico <>
X-Mailer: iPhone Mail (14B100)
In-Reply-To: <>
Date: Thu, 03 Nov 2016 08:48:41 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Justin Richer <>
Archived-At: <>
Cc: Nat Sakimura via Openid-specs-fapi <>, OAuth WG <>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Nov 2016 12:48:45 -0000

Just to be clear, the relationship should more like...

AS issues public key to clients, or client sends public key to AS. The authorities job is NOT to give the client the public key, but to sign the public key for authenticity. It's bad practice to accept the full cert (pub key+signature) from an authority. If an authority is creating your public key, they are also creating your private key.... bad.

> The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id. 

This seems like a bad idea. I suggest a separate key/signature for each service.
Jim Manico
Secure Coding Education
+1 (808) 652-3805

> On Nov 3, 2016, at 8:41 AM, Justin Richer <> wrote:
> I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id. 
> Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today. 
> I do think that more examples and guidance are warranted, though, to help AS developers.
>  -- Justin
>> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <> wrote:
>>> I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.
>> That's fair. I agree it can be made more explicit and that it be good to do so. 
>>> When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
>> In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly common. 
>> I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward. 
>>> I´m not saying it is a bad Idea just that I would prefer if it was not a MUST. 
>>> With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.
>> Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list