aarongable
commented
2 years ago It's a good question, but one that has already been addressed in prior discussion here, on the mailing list, and in IETF meetings.
Serial numbers alone cannot be used because the serial uniqueness constraint (imposed by the Baseline Requirements) applies on a per-issuer basis, while the uniqueness of these URLs needs to apply on a per-ACME-server basis. An ACME server may issue certificates from many different intermediates, so cannot guarantee serial uniqueness across the whole server.
Given that we need to be able to unambiguously uniquely identify the end-entity certificate in question, re-using the scaffolding from OCSP (which the ecosystem has accepted as a sufficiently-unique ID) allows clients to also re-use code. This will make life less difficult in the long run, rather than more difficult.
Hi,
As in #26, I'm sorry for joining the part so late and do let me know if this discussion would be better placed on the mailing list.
As in the name of the issue: why are the renewal-info resource URLs using certIDs? I appreciate that because POST-as-GET has been specifically banned to aid in caching then there is an argument for not using IDs that would have to be remembered or accessed via a POST-as-GET but I'm wondering if RFC6960 certIDs are just making life more difficult than it needs to be by introducing all the complexity of choosing which hash algorithms to support and then having to somehow communicate which ones those are.
Would it not make life easier to just use the certificate serial number either hex or base64 URL encoded with trailing '='s removed?
I appreciate that this seems to have already been the subject of discussion in #17 but I can't see much discussion there about if a serial number only solution was considered?