search

aarongable / draft-acme-ari

Internet Draft for the Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension
Other
4 stars 7 forks source link

URL Construction is Under-Specified #18

Closed AGWA closed 2 years ago

AGWA commented 2 years ago

The full request URL is computed by concatenating the renewalInfo URL from the server's directory with the following case-insensitive hex-encoded (see [@!RFC4648], Section [@!RFC4648, section 8]) elements, separated by forward slashes:

  • the SHA-1 hash of the issuer's public key (often included in the certificate as the Authority Key Identifier, see [@!RFC5280], Section [@!RFC5280, section 4.2.1.1]),

Is this hash computed over the DER encoding of the SubjectPublicKeyInfo (as in HPKP and CRLSets), just the public key minus tag and length (as in OCSP), or something else?

If the goal is to mimic OCSP, then I would recommend using the same language as RFC 6960, which is clear: "issuerKeyHash is the hash of the issuer's public key. The hash shall be calculated over the value (excluding tag and length) of the subject public key field in the issuer's certificate."

I strongly recommend dropping the reference to AKI. There is no requirement for AKI to be computed this way, and referencing it may lead some implementers to construct the URL from the AKI extension instead of from the issuer certificate, which may be easier but is definitely not correct.

  • the SHA-1 hash of the issuer's Distinguished Name, see [@!RFC5280], Section [@!RFC5280, section 4.1.2.4], and

Is this hash computed over the DER encoding? Should it come from the certificate's issuer field, or the issuer's subject field (which may not be byte-for-byte identical)? Again, I would recommend using RFC 6960's language: "The hash shall be calculated over the DER encoding of the issuer's name field in the certificate being checked."

  • the certificate serial number.

Encoded how? I see the example is uppercase hex, but this leaves two possibilities:

  1. It's a hex encoding of the integer. This means there may be an odd number of hexits. Are negative serial numbers prefixed with an ASCII minus sign? Is it OK to have leading zeros, or must it be the shortest possible representation of the integer?
  2. It's a hex encoding of the bytes in the DER encoding. This means there are always an even number of hexits, negative serial numbers are in twos-compliment, and positive serial numbers whose most-significant-bit is one are padded with a zero byte.

A major advantage to the scheme proposed in #17 is that it's inherently precise because it's just the DER encoding of an ASN.1 structure. The current scheme is going to require a lot of words to be sufficiently precise, and even then I foresee implementation divergences (e.g. some CAs accepting leading zeros in the serial and others not) and bugs (e.g. clients not properly encoding negative serials, or serials with a leading one bit) which will make ARI less reliable. With #17, clients can just leave the encoding to an ASN.1 library, possibly reusing existing, battle-tested code from OCSP implementations.

aarongable commented 2 years ago

Yep, I essentially agree. I intend to at the very least clarify this phrasing, and much more likely go with the plan outlined in #17 with the additional restriction of disallowing SHA-1 (or maybe requiring SHA-256?) for the hash algorithm used in the CertID.