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

Justin Richer <> Thu, 03 November 2016 12:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 008B012957F for <>; Thu, 3 Nov 2016 05:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.697
X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y3OyhopytANR for <>; Thu, 3 Nov 2016 05:42:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C99F12955F for <>; Thu, 3 Nov 2016 05:42:07 -0700 (PDT)
X-AuditID: 1209190f-ad7ff70000004c24-1e-581b309d8554
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E2.71.19492.D903B185; Thu, 3 Nov 2016 08:42:06 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id uA3Cg53C004966; Thu, 3 Nov 2016 08:42:05 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id uA3Cg2dM023635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Nov 2016 08:42:03 -0400
To: Brian Campbell <>, Samuel Erdtman <>
References: <> <> <> <> <> <> <> <> <>
From: Justin Richer <>
Message-ID: <>
Date: Thu, 03 Nov 2016 08:41:55 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------C7006D8E48835A0C09F5585D"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixCmqrDvPQDrCoOuklMXq/zcZLU6+fcVm 8fnWYVaL/0tPMTmweLz4t4fRY8mSn0wez3f2M3ncPXqRJYAlissmJTUnsyy1SN8ugSvj4bSJ bAWXvCs+rz3L2MC4zKiLkZNDQsBE4tuVA0xdjFwcQgJtTBK3nvcwQzgbGCW2952Fytxikvh7 4w4rSIuwQLrE61n/mEFsEYEYifMnVrBDFF1hkdiz/RYbSIJZIF/iw6WbYA1sAqoS09e0MIHY vAJWEmebJ4A1swioSEz7ORusXhRo0PVnj9ggagQlTs58wgJicwoESrx8dIUZYmaYRMeEZrYJ jPyzkJTNQpKCsG0l7szdzQxhy0s0b50NZetKLNq2gh1ZfAEj2ypG2ZTcKt3cxMyc4tRk3eLk xLy81CJdE73czBK91JTSTYzgKJDk38E4p8H7EKMAB6MSD2/GD8kIIdbEsuLK3EOMkhxMSqK8 bzSlI4T4kvJTKjMSizPii0pzUosPMUpwMCuJ8CrqAeV4UxIrq1KL8mFS0hwsSuK8/92+hgsJ pCeWpGanphakFsFkZTg4lCR4D+sDNQoWpaanVqRl5pQgpJk4OEGG8wANPwBSw1tckJhbnJkO kT/FqCglzntSByghAJLIKM2D6wUlqYS3h01fMYoDvSLMWwvSzgNMcHDdr4AGMwENNk+SABlc koiQkmpg3Hpkc3VUpbiwHkflPZYvJoY79zzsDz7KH35mccwqjfNTvnbub5kRmcrw6/5dsTXS zpWOpxQnuRpMNwiSSPg5Me3tgec1M/afYy1uCr8ey7/tuNqv9MlzbGe+7o6tkEgyXWKxYMIZ L9avq8qE5GambGIxE5vsy53Zxb3jwILH1UukOOp2bfydpcRSnJFoqMVcVJwIAKUAMrgtAwAA
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:42:09 -0000

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