The key authorization file from the server did not match Root Cause

And regardless, it's the JWK RFCs that would want the errata, as RFC8555 has nothing to say about how to compute a thumbprint except for referencing those docs.


I submitted an 8555 eratea for 8.1

My proposed new text:
The "Thumbprint" step indicates the computation specified in
[RFC7638], using the SHA-256 digest [FIPS180-4]. As noted in
[RFC7518] any additional prepended zero octets in the fields of a JWK object
MUST be stripped before doing the computation.
Fixed length fields such as found in ECDSA keys should be their natural length and
leading zero octets should not be stripped.

1 Like

It does somewhat make a summary of what the user should do based on the referenced RFC. IMO such summary should either be "crystal clear" or omitted at all.

But as I said, I've never written an RFC, so I'm certainly no expert on this matter.


Sorry, I'm still confused. RFC 7518 references leading zeros in exactly two places that I can find:

Section 3.4 Digital Signature with ECDSA
The octet sequence representations MUST NOT be shortened to omit any leading zero octets contained in the values.

This one already clearly says that leading zeros MUST NOT be removed.

Section "n" (Modulus) Parameter
Note that implementers have found that some cryptographic libraries
prefix an extra zero-valued octet to the modulus representations they
return, for instance, returning 257 octets for a 2048-bit key, rather
than 256. Implementations using such libraries will need to take
care to omit the extra octet from the base64url-encoded

This section a) is only talking about RSA keys, not ECDSA, and b) is clearly only talking about extra zero octets that some libraries prepend.

I think it's pretty clear already that leading zeros of ECDSA parameters should not be stripped, and that "additional prepended" zeros should be. It explicitly says to do the thing that RFC 8555 reminds people to do. It explicitly says not to do the thing that your implementation did.

I say this not because I think that additional clarity in RFC 8555 would be bad, but simply because the IETF takes the definition of "errata" pretty seriously: there's no mistake here, no error. I wish you the best of luck, but find it unlikely that the IETF will accept an errata along these lines.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.