Consider changing URL construction away from OCSP CertID

[aarongable]

Feedback from client authors (forum, email) is making it clear that using the OCSP CertID structure is not actually making client implementation easier. It comes with real benefits for sure: algorithm agility, uniquely identifying cert even across CAs, etc. But most libraries don't expose a way to easily access this structure (they produce fully OCSP requests instead), so authors are often copy-pasting segments of code from their language's crypto libraries.

[aaomidi]

Thanks for making this issue!

I'm too new to the space to know the historical context of why OCSP is the way it is. But I think with ARI enough time has past to make the ecosystem of databases, etc be able to handle a different structure to query it.

I'm wondering, since certificate fingerprints has been used for certificate identification in the past - are there any problems you foresee if ARI used that for the GET handling?

[aarongable]

One immediate disadvantage is that the lack of algorithm agility. In fact, the only IETF documents I've found (although I easily could have missed some) that define the concept of a "certificate fingerprint" use SHA-1 to do so! (https://datatracker.ietf.org/doc/html/rfc4572, https://datatracker.ietf.org/doc/html/rfc4387). If you scour stack overflow and forums you will find many people dying on the hill that "fingerprint" means SHA-1 and "thumbprint" means SHA-256, or that you're supposed to compute it over the PEM instead of the DER, or various other forms of confusion. I'd prefer not to perpetuate any of that.

Another disadvantage is opacity. With the OCSP CertId, you can inspect each part separately: do I recognize this serial? do I recognize this issuer hash? If you recognize some of the parts, you may be able to know what went wrong with the client's request (or your own database lookup!) and provide a good error message. If all you're handed is an opaque bytestring, you either recognize it or you don't and that's it.

And selfishly, I think it is disadvantageous to define a new way to uniquely identify a cert when we already have a perfectly good way: hash algorithm, hash of issuer info, serial. I'm fine with coming up with some other way to convey that triplet of information, but I do find myself preferring that tuple over an opaque blob.