cc @golang/security

Notably, the RFC makes no assertions about the contents of these certificates, whether they are strictly delegated OCSP issuers (as discussed in #40017 or whether they can include or not include intermediate CAs necessary to tie the OCSP responder's cert back to a concrete root.

I think the RFC is a little vague and confusing (in an extremely PKIX-y way) here. There is no restriction put on what can be in certs, just saying that they help the OCSP client verify the responder's signature. That said RFC 6960 Section 4.2.2.2. requires that if a delegated signing certificate is used it should be issued by the certificate that signed the certificate being checked. In the delegation case certs then only really needs to contain a single certificate, but the RFC leaves the door open to put whatever else you want in there.

In theory you can put the rest of the chain (e.g. delegated signer -> intermediate issuer -> root) in the response, but we have no interest in verifying the rest of that chain (or any other chain in the response) since we only care that the delegated signer links back to the issuer of the certificate being checked (https://go.dev/cl/57510 contains some previous discussion of this behavior, and why we do what we do).

I think one of the reasons the API is designed in the way it is, and assumes that the caller has the issuer on hand, is that if you are verifying the validity of a certificate, you are, 99% of the time, going to have its issuer on hand. In theory there could be value in verifying OCSP responses that contain the fully chain from OCSP signer to certificate issuer for cases where you do not have the issuer already, but I'm not sure there are any real world cases where this is the case (at least ones I'd want to explicitly support).

For private CAs

These are interesting examples, and given there are implementations in the wild we probably need to consider supporting them, but I'm not entirely clear what value is being added here.

From the Vault perspective, what is the rationale for including the issuing certificate (which isn't delegated) to the response? Is it expected that the relying party won't already have it? It seems like this unnecessarily inflates the size of the response.

1. Update the docs to more adequately warn about specifying a nil issuer here.

Seems reasonable to say this should only be done if the response was provided over an otherwise trusted channel. Even with that said though we probably also should be explicit that if issuer == nil you need to check that the response was signed by a certificate issued by the certificate that signed the response (I wish we'd never included signature verification in parsing, this API is cursed).

2. Update the API to correctly return all certs fields, allowing callers to perform more advanced chain building with a nil issuer parameter if they desire.

Not sure I'm convinced this is something we really want to support. Just exposing all of the certificates sent isn't particularly complicated, but it encourages users to use OCSP in a way that isn't really relevant to web PKI (which is the subset of PKIX that we target, in an attempt to prune away the overwhelming complexity that is PKIX), and that I don't think we have any particular interest in providing broader support for elsewhere (i.e. in the standard library).

3. Fix the library to not err if issuer == certs[0] (i.e., if issuer != certs[0], do the signature check that exists today).

Seems reasonable to handle this redundancy, since it does appear in the wild.

@rolandshoemaker writes:

That said RFC 6960 Section 4.2.2.2. requires that if a delegated signing certificate is used it should be issued by the certificate that signed the certificate being checked. In the delegation case certs then only really needs to contain a single certificate, but the RFC leaves the door open to put whatever else you want in there.

I don't think this is quite a valid read, though I agree in practice.

Notably, that paragraph in RFC 6960 goes on to write:

The CA SHOULD use the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation.

and further, the extended note is of relevance:

Note: For backwards compatibility with RFC 2560, it is not
prohibited to issue a certificate for an Authorized
using a different issuing key than the key used to issue the
certificate being checked for revocation. However, such a
practice is strongly discouraged, since clients are not
required to recognize a responder with such a certificate as an
Authorized Responder.

Which is to say, this is likely another case where the CA the Entity (with a capital E) is different than "the concrete certificate with the IsCA basis constraint assert) and something legacy did happen, I agree.

But, more to the point, nothing guarantees the first item is also the responder.

Finishing the investigation, I think EJBCA has the same issue:

• responseChain is built from fullCertificateChain.
• It builds the OCSP response with this full chain -- either of the signing CA or with the delegated signer AND the signing CA's chain.
• BouncyCastle will happily include that chain in the ASN.1 response.

Following that BouncyCastle lead:

• Maritime Connectivity PKI seems to have the same behavior as Vault, assuming it is configured to directly use the ICA and not a delegated signer (unverified whether this is possible or not).
• If my read of otoroshi is correct this directly uses the root CA and again places it in the certs field.

So yeah, we can fix this on the Vault side, but this is a lot of additional private CAs--including EJBCA--that have this same behavior.

Go is broken validating all of them.

Yeah, I think it'd probably also be reasonable to just iterate across all of the certificates in certs to find one that validates the signature, rather than always picking the first one 🤷.

Change https://go.dev/cl/485055 mentions this issue: ocsp: better validate OCSP response's certificates

It looks like the linked Gerrit CL was filed over a year ago, but it was never reviewed and no further progress was made.

This has become relevant again in this (invalid) bugzilla CA incident report. The incident report was filed because an external tool (SSLMate's OCSP Watch) was reporting that the CA's OCSP responses are malformed because it can't verify their signature. However what is actually happening is that the CA has embedded the issuing certificate (which is not a delegated responder) in the OCSP response's certs field. Therefore x/crypto/ocsp's requirement that certs[0] be signed by issuer fails, because those are in fact the same CA.

What is the status of the attached CL? Does the Go crypto team intend to review it and move towards merging it? Has there been a decision to not move forward with a slightly-more-permissive ocsp.ParseResponseForCert API?

I'd be happy to take over moving this forward, if Alex Scheel no longer wants to drive it.

(note for the purpose of keeping this cross-referenced: the fact that ocsp.ParseResponse does signature verification at all is somewhat surprising and bad. It would likely be better if there were separate dedicated parsing and verification APIs. This would also allow bugs like not verifying the delegated responder's validity period to be fixed. Such a separation is proposed in this bug, but that appears to be blocked on moving OCSP out of //x/crypto and into //crypto itself.)

While the CA in question might not be explicitly violating RFC 6960, their responder is nevertheless misconfigured, and they have agreed to fix their responder to omit the superfluous certificate, which would make their responses work with x/crypto/ocsp. In light of that, I'm not sure that addressing this issue is necessary or desirable.

In particular, I'd like to echo this comment by @agl:

So the PKIX RFCs err strongly on the side of complexity, but that results in an over-complex mess and must be subsetted. The trick is pick the right battles and, over time, try to bring the complexity down.

In that case, a considerable number of WebPKI CAs had misconfigured OCSP responders, so it was pragmatic for Go to become more permissive. In this case, there is only one (brand new) WebPKI CA affected, and they're fixing their responder, which makes this a good place for Go to hold the line.

Regardless of the outcome of this CL, I will ensure that OCSP Watch continues to reject these broken respones, in order to prevent a regression towards more complexity and brokenness in the WebPKI.

This slipping through the cracks is my fault. Given this is the first time we've heard about it cropping up in the wild again though makes me agree with @AGWA that perhaps this does not seem so widespread of a misconfiguration to warrant additional complexity.

Our behavior here is strange though, in that the documentation is vague in what we enforce, and we should at least be documenting the constraints that ParseResponse has (and perhaps why), since they are clearly not obvious (especially to anyone who hasn't been staring at PKIX RFCs for multiple hours a day).

I think really what we need, as @aarongable mentions, is a new, somewhat less cursed OCSP API, but that requires investing the time to design one.

...their responder is nevertheless misconfigured...
...reject these broken respones...

I strongly disagree with both of these characterizations. Their OCSP responses are fully compliant with both the letter and the spirit of RFC 6960, and with other major OCSP-validation implementations. Their responder is not misconfigured, and their responses are not broken. They are just incompatible with Go's implementation decisions.

In this case, there is only one (brand new) WebPKI CA affected, and they're fixing their responder, which makes this a good place for Go to hold the line.

But I think this is a totally reasonable stance to have. I think it's fine for Go to take a strongly opinionated stance here, with two caveats:
a) as Roland says, that stance needs to be well-documented (I'm happy to file a PR to improve the documentation here, and then this issue and other related CLs should be closed); and
b) ideally the WebPKI community should have some way to know that violating Go's constraints here is a meaningful finding that should be fixed, but not a CA incident.

I think really what we need is a new, somewhat less cursed OCSP API

My back-of-the-napkin proposal would be to mirror x509.RevocationList, i.e. only provide two methods:

func ParseOCSPResponse(der []byte) (*OCSPResponse, error)
func (or *OCSPResponse) CheckSignatureFrom(parent *Certificate) (error)

The CheckSignatureFrom method would require that the signature "chain up to" to the provided issuer certificate, but would be willing to use one of the certificates from the response's certs field as a delegated responder between the response itself and the provided issuer. It would enforce that the delegated responder has the id-kp-OCSPSigning EKU, but nothing else (e.g. it wouldn't check that the delegated responder is not expired or not revoked).