Yeah, both of these clarifications (the existing one about additional prepended zero octets, and the new one about leading zeros) are explicitly laid out in RFC 7518:
> 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. > Section 6.3.1.1 "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 > representation. It's not clear to me why RFC 8555 has a reminder for *either* of them, but I don't think there's any particular harm in having a reminder for both, either. Aaron On Thu, Jul 13, 2023 at 1:31 PM Richard Barnes <[email protected]> wrote: > This seems correct to me. I would mark it Verified. > > On Thu, Jul 13, 2023 at 12:19 PM RFC Errata System < > [email protected]> wrote: > >> The following errata report has been submitted for RFC8555, >> "Automatic Certificate Management Environment (ACME)". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid7565 >> >> -------------------------------------- >> Type: Technical >> Reported by: Paul Breed <[email protected]> >> >> Section: 8.1 >> >> Original Text >> ------------- >> The "Thumbprint" step indicates the computation specified in >> [RFC7638], using the SHA-256 digest [FIPS180-4]. As noted in >> [RFC7518] any prepended zero octets in the fields of a JWK object >> MUST be stripped before doing the computation. >> >> Corrected 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. >> >> Notes >> ----- >> This comment was really aimed at the leading 0 octet sometimes used with >> RSA, but the comment is not RSA specific. ECDSA keys can have fixed length >> fields (X,Y) where there can be leading zeros. This led me astray in >> implementing an ECDSA thumbprint routine for ACME. The result was that >> 1/128 ECDSA keys failed to generate t humbp[rint as leading zeros were >> removed. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC8555 (draft-ietf-acme-acme-18) >> -------------------------------------- >> Title : Automatic Certificate Management Environment (ACME) >> Publication Date : March 2019 >> Author(s) : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. >> Kasten >> Category : PROPOSED STANDARD >> Source : Automated Certificate Management Environment >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
