Hi all, Thanks for the clarification.
Best Regards, Thamindu Jayawickrama On Wed, Jan 17, 2024 at 3:00 AM Filip Skokan <panva...@gmail.com> wrote: > I agree and share Neil's position. > > Furthermore, to answer your question, no you should not use or accept both > of the approaches as valid methods. Only Method 1 is valid. > > S pozdravem, > *Filip Skokan* > > > On Tue, 16 Jan 2024 at 20:54, Neil Madden <neil.e.mad...@gmail.com> wrote: > >> JWS refers to FIPS 180-4 as the definition of SHA-256. That spec defines >> the message digest produced by SHA-256 as a 256-bit binary value, not a >> hex-encoded string. So the "base64url-encoded SHA-256 thumbprint (a.k.a. >> digest)" is your Method 1. Anyone doing Method 2 has a bug. >> >> -- Neil >> >> On 10 Jan 2024, at 04:10, Thamindu Dilshan Jayawickrama < >> thamindudill...@gmail.com> wrote: >> >> Hi all, >> >> I have initiated this mail thread to get your opinion on the correct >> approach of calculating the "x5t#S256" parameter in the JWKS response. JWS >> specification [1 >> <https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.8>] defines >> the "x5t#S256" parameter as follows. >> >> """ >> The "x5t#S256" (X.509 certificate SHA-256 thumbprint) Header >> Parameter is a base64url-encoded SHA-256 thumbprint (a.k.a. digest) >> of the DER encoding of the X.509 certificate [RFC5280] corresponding >> to the key used to digitally sign the JWS. >> """ >> >> Different parties seem to be using two different methods when calculating >> this field. >> >> *Method 1:* >> >> 1. Take DER encoding of the certificate which produces a 32 byte array >> 2. Take the base64 url encoding >> >> In this method, we compute this "x5t#S256" parameter by directly url >> encoding the 32 byte array without taking the hex string. Example given at >> appendix A of the MTLS token spec [2 >> <https://datatracker.ietf.org/doc/html/rfc8705#section-appendix.a>] >> appears to be following this method. >> >> *Method 2:* >> >> 1. Take DER encoding of the certificate which produces a 32 byte array >> 2. Convert it into a hexadecimal string and transform it into a 64 byte >> array >> 3. Take the base64 url encoding >> >> In some places I have seen the following approach is used to obtain a >> value equal to the "x5t#S256" field. >> >> 1. Display the certificate with a tool like Keytool Explorer and copy the >> SHA 256 fingerprint. >> 2. Remove colons (":"s) and convert it to all lowercase. >> 3. Base64url encode the value. >> >> This approach requires the above hexifing step (method 2) in order to >> produce a similar result when computing the "x5t#S256" field. >> >> Hence I would like to query about the correct approach to follow when >> calculating the "x5t#S256" parameter. Or can we accept both these forms as >> correct methods to calculate the mentioned field? >> >> Thanks in advance. >> >> [1] https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.8 >> [2] https://datatracker.ietf.org/doc/html/rfc8705#section-appendix.a >> >> Best Regards, >> Thamindu Jayawickrama >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- Best Regards Thamindu Jayawickrama B. Sc in Engineering (Hons) Department of Computer Science & Engineering University of Moratuwa +94 71 485 2364 | +94 77 512 7790
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
