In general, hints in headers are supposed to help you obtain a verification key.
If you get a key from your "trust store" through `kid` or `x5t`, the important part is that you trust the key, not so much that the identifier you used to find the key is "a consistent globally unique identifier"... Method 2 seems to be erroneously double encoding the thumbprint. Last time I needed to implement thumbprints, I used this as a reference: - https://github.com/PeculiarVentures/x509/discussions/34#discussioncomment-3481870 - https://github.com/PeculiarVentures/x509/blob/08270969c8a3a9093fac7e2af9d5e7ccb334698b/src/x509_cert.ts#L270 OS On Mon, Jan 15, 2024 at 10:40 PM Thamindu Dilshan Jayawickrama < thamindudill...@gmail.com> wrote: > Hi all, > > Any idea whether we can use both of the above approaches as valid methods > to calculate the "x5t#S256" parameter? Appreciate your input on this. > > Best Regards, > Thamindu Jayawickrama > > On Wed, Jan 10, 2024 at 9:40 AM 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 >> >> > > -- > 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 > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
