Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt

[Vladimir Dzhuvinov <[e-mail]>]

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 <[e-mail]>
> 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 <
>> [e-mail]> 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: <[e-mail]> <[e-mail]>
>>> Date: Fri, Jul 28, 2017 at 12:25 PM
>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
>>> To: [e-mail]
>>> Cc: [e-mail]
>>>
>>>
>>>
>>> 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>