Good catch, Vladimir. Thanks! On Sat, Oct 13, 2018 at 2:52 AM Vladimir Dzhuvinov <vladi...@connect2id.com> wrote:
> Thanks Brian, this makes the spec even better! > > I have just this one small note, there seems to be an "and" missing here: > > The base64url-encoded value MUST omit all trailing pad '=' characters _and_ > MUST NOT include any line breaks, whitespace, or other additional characters. > > Vladimir > > On 10/10/18 03:18, Brian Campbell wrote: > > 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> > <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> > <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> > <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> > <https://tools.ietf.org/html/rfc7517>] > "x5c" parameter (note that Sec 4.7 of RFC > 7517<https://tools.ietf.org/html/rfc7517> > <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> > <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> > <https://tools.ietf.org/html/rfc7517>] > "x5c" parameter. Note that Sec 4.7 of RFC > 7517<https://tools.ietf.org/html/rfc7517> > <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). > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- _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
