mholt
July 26, 2024, 3:58pm
29
The ecosystem is already experiencing ripple effects because of this. Looks like Go will stop maintaining OCSP code and will not implement an OCSP verifier:
opened 04:29AM - 03 Jul 20 UTC
Proposal
Proposal-Hold
Proposal-Crypto
Although we have a golang.org/x/crypto/ocsp package, we don't in fact have an OC… SP verifier. The existing package provides serialization and parsing, but not APIs for "get me an OCSP response for this certificate" and "given this certificate and this OCSP response tell me if it's revoked". (They are separate because you only want the latter when checking stapled responses.)
There is a lot of complexity, subtlety, and dark knowledge involved in OCSP unfortunately. Here are a few notes on things the verifier needs to do (from reading [this thread](https://groups.google.com/d/msg/mozilla.dev.security.policy/EzjIkNGfVEE/XSfw4tZPBwAJ)):
* check that the response is signed directly by the issuer (without needing the OCSP EKU) or that it's signed by a Delegated Responder issued directly by the issuer (with the OCSP EKU)
* for Delegated Responders, **not** require the EKU to be enforced up the chain
* check that the signer has the correct KeyUsage
* for Delegated Responders, require them to be End Entity certificates (i.e. not a CA; this is an off-spec Mozilla check that protected them from the mess of CAs giving the OCSP EKU away to intermediates)
* for Delegated Responders, maybe check that the `id-pkix-ocsp-nocheck` extension is present (this is a BR requirement, but if it's not an IETF requirement we might want to skip it)
There are definitely a lot more things to consider (for example, the `id-pkix-ocsp-nocheck` extension needs to be processed itself), the list above are just notes of things I learned from that one incident.
A difficult question is where to put the code, and how to surface it. We'll want to use it in crypto/tls for Must-Staple (#22274) but it feels like the wrong place for the code to live. An obvious answer would be golang.org/x/crypto/ocsp, but then we can't use it from crypto/x509 without an import loop. Should `x509.VerifyOptions` have an option to verify a stapled response? Probably, I feel like we'd regret doing OCSP verification separately from path building and certificate verification anyway. What about the API to fetch a response? Maybe that can stay in golang.org/x/crypto/ocsp, separating the concerns of obtaining responses and verifying them.
We should also look around the ecosystem, because surely someone had to implement this, and we should compare results.
2 Likes