Closed robstradling closed 5 months ago
Thanks for pointing this out! This is a really good point, and I've addressed it in the PR above. I'm going to merge that PR so I can publish the next version of this document, but definitely let me know if you see any issues with my updated phrasing or example. Thanks again!
Thanks @aarongable. LGTM!
https://www.ietf.org/archive/id/draft-ietf-acme-ari-02.html#section-4.1 refers to "the bytes of the certificate's Serial Number value", and provides an example "certificate's Serial Number field" that is described as an "ASN.1 Integer value".
The Summary in the ASN.1 specification (X.680 02/2021) says: "The ASN.1 notations can be applied whenever it is necessary to define the abstract syntax of information without constraining in any way how the information is encoded for transmission."
Since a certificate's signature is calculated over its DER encoding, I'm guessing that "the bytes of the certificate's" is intended to imply that it is the contents octets of the DER encoding of the ASN.1 INTEGER Serial Number field that should be used to produce the ARI request. However, I think this should be stated explicitly, to avoid ambiguity.
Clarity on this point will be particularly important when dealing with Serial Numbers whose DER encoded contents octets begin with a 0x00 octet, which serves to indicate that the integer is non-negative. Such octets are part of the (two's complement) DER encoding of an ASN.1 INTEGER, but AIUI are not considered part of the abstract notation of an ASN.1 INTEGER. (Consider, for example, how
openssl x509 -text
displays serial numbers without these leading 0x00 contents octets). If an ARI client omits the 0x00 but the ARI server is expecting the 0x00 (or vice versa), the ARI server will respond with an error.I think it would also be helpful to change the example serial number in section 4.1 to be one whose DER encoding requires a leading 0x00 contents octet.