This mandates SHA1, which on the one hand is in-line with RFC5019 "Lightweight OCSP Profile", but on the other hand mandates an out-of-date hashing algorithm.
This could instead be formulated as
[directory base path] / base64url(CertID)
where CertID is the ASN.1 Sequence specified in RFC6960
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of issuer's DN
issuerKeyHash OCTET STRING, -- Hash of issuer's public key
serialNumber CertificateSerialNumber }
This would allow different ACME servers to set different policies around what hash algorithms they accept, and would allow some amount of agility around hash algorithms in the future. On the other hand, it would make requests relatively opaque (can't tell from the URL alone what issuer is being requested, due to the base64url encoding), it would make requests larger (due to the ans.1 and encoding overhead), and it would directly couple this spec to OCSP instead of just borrowing its ideas.
Currently, renewalInfo URLs are constructed as
This mandates SHA1, which on the one hand is in-line with RFC5019 "Lightweight OCSP Profile", but on the other hand mandates an out-of-date hashing algorithm.
This could instead be formulated as
where
CertIDis the ASN.1 Sequence specified in RFC6960This would allow different ACME servers to set different policies around what hash algorithms they accept, and would allow some amount of agility around hash algorithms in the future. On the other hand, it would make requests relatively opaque (can't tell from the URL alone what issuer is being requested, due to the base64url encoding), it would make requests larger (due to the ans.1 and encoding overhead), and it would directly couple this spec to OCSP instead of just borrowing its ideas.