A couple of the draft-ietf-oauth-mtls editors recived some off-list questions and feedback from an implementer, which resulted in a few small potential clarifying updates to the document that I think are worth incorporating despite the post WGLC status.
Barring reasonable objections from the WG or process objections from the chairs, I'd like to make these updates. Basically, there were two points of confusion. First, there was some uncertainty about the order of operations and encoding steps when computing the "x5t#S256" value. In order to be more specific/clear, I propose changing the relevant text in sec 3.1 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-11#section-3.1> from: To represent the hash of a certificate in a JWT, this specification defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" for the X.509 Certificate SHA-256 Thumbprint. The value of the "x5t#S256" member is the SHA-256[SHS] hash (a.k.a. thumbprint, fingerprint or digest) of the DER encoding of the X.509 certificate [RFC5280] base64url-encoded [RFC4648] with with all trailing pad '=' characters omitted and without the inclusion of any line breaks, whitespace, or other additional characters. to: To represent the hash of a certificate in a JWT, this specification defines the new JWT Confirmation Method [RFC7800] member "x5t#S256" for the X.509 Certificate SHA-256 Thumbprint. The value of the "x5t#S256" member is a base64url-encoded [RFC4648] SHA-256 [SHS] hash (a.k.a. thumbprint, fingerprint or digest) of the DER encoding of the X.509 certificate [RFC5280]. The base64url-encoded value MUST omit all trailing pad '=' characters MUST NOT include any line breaks, whitespace, or other additional characters. And also, as a way for developers to check their work. to add an example with a certificate and the "x5t#S256" value for it. Second was some confusion about matching the cert/key against the keys in the client's JWK Set for the self-signed mode. It was said that having some text to the effect of '(e.g. "n" and "e" for RSA, "x" and "y" for EC)' along with the text note at the end of Section 2.2.2 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-11#section-2.2.2>. would have been helpful. So that paragraph would change from: For the Self-Signed Certificate method of binding a certificate to a client using mutual TLS client authentication, the existing "jwks_uri" or "jwks" metadata parameters from [RFC7591 <https://tools.ietf.org/html/rfc7591>] are used to convey the client's certificates and public keys, where the X.509 certificates are represented using the JSON Web Key (JWK) [RFC7517 <https://tools.ietf.org/html/rfc7517>] "x5c" parameter (note that Sec 4.7 of RFC 7517 <https://tools.ietf.org/html/rfc7517> requires that the key in the first certificate of the "x5c" parameter must match the public key represented by other members of the JWK). to: For the Self-Signed Certificate method of binding a certificate to a client using mutual TLS client authentication, the existing "jwks_uri" or "jwks" metadata parameters from [RFC7591 <https://tools.ietf.org/html/rfc7591>] are used to convey the client's certificates and public keys, where the X.509 certificates are represented using the JSON Web Key (JWK) [RFC7517 <https://tools.ietf.org/html/rfc7517>] "x5c" parameter. Note that Sec 4.7 of RFC 7517 <https://tools.ietf.org/html/rfc7517> requires that the key in the first certificate of the "x5c" parameter must match the public key represented by other members of the JWK (e.g. "n" and "e" for RSA, "x" and "y" for EC). -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
