The BR and Delegated OCSP responder signing certificates

[arvid-vermote]

Section 7.1.2.8.1 OCSP Responder Validity of the TLS BR does not stipulate a maximum validity for OCSP responder certificates. This implies such a certificate can effectively be valid as long as the issuing CA itself.

There might be risk associated with long-validity OCSP responder signing certificates as, if no pre-signing is performed, they must be close to a CA’s outer perimeter in order to perform real-time signing of OCSP requests.

Due to the presence of id-pkix-ocsp-nocheck in OCSP responder signing certificates a key compromise of such a certificate effectively renders the validation services of issuing CA and hence the issuing CA itself compromised for as long as the OCSP responder certificate(s) are valid.

RFC 6960 4.2.2.2.1 recommends limiting the validity of OCSP responder signing certificates and is also stipulating above risk:

CAs issuing such a certificate should realize that a compromise of the responder's key is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently.

Further there are no requirements in terms of segregating OCSP responder certificate keys in multiple HSM / isolated environments, so there is the potential for CA’s having all their OCSP responder certificate keys, including those for root CA’s, in a single, shared environment meaning certain types of breaches might lead to a compromise of a CAs complete certificate validation services.

For (online) issuing CA, short lifetimes for OCSP responder signing certificates would be achievable through automation however, for Root CA, having short lifetimes for OCSP responder signing certificates will generally be more complex, expensive, and requiring human effort due to the offline nature of those CA.

Should we modify Section 7.1.2.8.1 to only allow short-lifetime subordinate CA OCSP responder certificate and prohibit the issuance of delegated OCSP responder certificates for Root CA?

[XolphinMartijn]

prohibit the issuance of delegated OCSP responder certificates for Root CA?

No. That would prohibit any existing Root CA that does not have the Digital Signature Key Usage bit set to no longer be able to support OCSP.

[arvid-vermote]

You are right - I think they can support it but they would violate the BR :) (https://bugzilla.mozilla.org/show_bug.cgi?id=1652581).

So for Root CA delegated certificates should be allowed but they must be stored in an offline state in order to address the risk at hand?

[XolphinMartijn]

I don't see a direct benefit of limiting lifetime on these more than whatever the corresponding CA certificate is limited to.

I'd say addressing Private Key security requirements for Delegated OCSP Responder certificates has more effect than limiting lifetimes on them, and would support an effort to setup that

[XolphinMartijn]

It seems worth mentioning cabforum/netsec#22. Wether or not we put it in the BRs, or the NSRs remains to be seen

[arvid-vermote]

Hi @XolphinMartijn as just discussed my recommendation is to insert a limit on delegated OCSP responder leaf validity for those CA that perform real-time OCSP response signing on the edge at the minimum, not sure if there is any impact to just generalize this limited validity to al delegated OCSP responder signing certificates regardless of pre-signing (in which its assumed they would be in a better protected zone) vs, real-time (where they would live in an edge zone of the CAs network)

[dzacharo]

Notes from the 2024-12-19 SCWG Teleconference:

• Section 7.1.2.8.1 could be modified to include some expected validity period for OCSP responder certificates
• Try to get some input from CAs about the maximum validity of their OCSP responder certificates
• Keeping the issue open until someone decides to take ownership and drive to a ballot