Re: [Acme] [Technical Errata Reported] RFC8555 (7565)

[Aaron Gable <[e-mail]>]

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 <[e-mail]> wrote:

> This seems correct to me.  I would mark it Verified.
>
> On Thu, Jul 13, 2023 at 12:19 PM RFC Errata System <
> [e-mail]> 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 <[e-mail]>
>>
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>