What are the potential uses of the x5c parameter? Vladimir
On 04/08/17 21:13, Brian Campbell wrote: > Just wanted to note that, in an off-list exchange, John has pushed back on > the idea to potentially drop mention of using x5c. > > On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > >> Thanks for the review, Vladimir. >> >> The text about which you have questions was written by Torsten (credit or >> blame where it's due!) but I believe he's out of the office for a bit so >> I'll try and answer. >> >> Your 1st question: >> I've had the same thought regarding the public key method and using the >> JWK x5c parameter. A JWK already has the public key, which is sufficient >> for comparison in the public key method. So x5c is just superfluous here. I >> believe that's a change that the next revision should have and will look to >> make it unless someone wants to make a strong case for needing x5c. >> >> Your 2nd question: >> I also found the sentence, "When used in conjunction with a trusted X.509 >> certificate source, it also allows the client to rotate its X.509 >> certificates without the need to change its respective authentication data >> at the authorization server." somewhat difficult to understand when I first >> read it. The intended meaning relies on content earlier in the same >> paragraph that says, "As pre-requisite, the client registers a X.509 >> certificate or *a trusted source for its X.509 certificates (jwks uri as >> defined in [RFC7591])* with the authorization server." Basically what >> it's trying to say is that when a client is registered or configured with a >> jwks_uri, then client key rotation can be done without needing to >> explicitly update the client config/registration with the AS. Does that >> explain it? I believe the text could be more straightforward and will >> endeavor to make it more clear in the next draft update. >> >> >> >> >> >> >> >> >> >> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov < >> vladi...@connect2id.com> wrote: >> >>> Thanks everyone for the update! Having a clear distinction between the >>> PKIX vs public key bound methods will help interop, implementers' job, and >>> it also appears good for security. >>> >>> Questions: >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- >>> 03#section-2.3 >>> >>> where the X.509 certificates are represented using the "x5c" parameter from >>> [RFC7517 <https://datatracker.ietf.org/doc/html/rfc7517>] >>> >>> For the public key method, is it really necessary for the client to >>> include its certificate in the JWK x5c parameter? This will make >>> implementation harder for developers, and I'm not sure it adds anything in >>> terms of security. Registering the public key parameters seems sufficient >>> to me. >>> >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- >>> 03#section-2.1 >>> >>> When used in conjunction with a trusted X.509 certificate source, it also >>> allows the client to rotate its X.509 certificates without the need to >>> change its respective authentication data at the authorization server. >>> >>> I don't understand this - "in conjunction with a trusted X.509 >>> certificate source" >>> >>> >>> Thanks, >>> >>> Vladimir >>> >>> On 28/07/17 21:33, Brian Campbell wrote: >>> >>> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with >>> the changes listed below based on comments and dissuasion in Prague. >>> >>> >>> draft-ietf-oauth-mtls-03<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03> >>> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03> >>> >>> >>> o Introduced metadata and client registration parameter to publish >>> and request support for mutual TLS sender constrained access >>> tokens >>> o Added description of two methods of binding the cert and client, >>> PKI and Public Key. >>> o Indicated that the "tls_client_auth" authentication method is for >>> the PKI method and introduced "pub_key_tls_client_auth" for the >>> Public Key method >>> o Added implementation considerations, mainly regarding TLS stack >>> configuration and trust chain validation, as well as how to to do >>> binding of access tokens to a TLS client certificate for public >>> clients, and considerations around certificate bound access tokens >>> o Added new section to security considerations on cert spoofing >>> o Add text suggesting that a new cnf member be defined in the >>> future, if hash function(s) other than SHA-256 need to be used for >>> certificate thumbprints >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: <internet-dra...@ietf.org> <internet-dra...@ietf.org> >>> Date: Fri, Jul 28, 2017 at 12:25 PM >>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >>> To: i-d-annou...@ietf.org >>> Cc: oauth@ietf.org >>> >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Web Authorization Protocol WG of the IETF. >>> >>> Title : Mutual TLS Profile for OAuth 2.0 >>> Authors : Brian Campbell >>> John Bradley >>> Nat Sakimura >>> Torsten Lodderstedt >>> Filename : draft-ietf-oauth-mtls-03.txt >>> Pages : 17 >>> Date : 2017-07-28 >>> >>> Abstract: >>> This document describes Transport Layer Security (TLS) mutual >>> authentication using X.509 certificates as a mechanism for OAuth >>> client authentication to the token endpoint as well as for >>> certificate bound sender constrained access tokens. >>> >>> >>> The IETF datatracker status page for this draft >>> is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ >>> >>> There are also htmlized versions available >>> at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 >>> >>> A diff from the previous version is available >>> at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP >>> at:ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
