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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
