what rules apply to dedicate OCSP signer or OCSP signing certificate?

[passerby184]

Because "OCSP signing Certificate" shows only once in entire BR, only requirement for them are having id-kp-OCSPSigning and id-pkix-ocsp-nocheck. this doesn't fit anywhere in current requirement: this isn't CA certificate nor subscriber certificate by itself, although ocsp signing role technically added into any of them as BR 7.1.2's extkeyusege limit is 'SHOULD NOT' for this key usage. if we consider this type of certificate isn't a CA, can they be sit outside of HSM and use full CPU power to sign OCSP, which may benefit high volume CAs this may not that dangerous as it sounds if its lifetime is short enough, like a week or 3 days.

[Peter Bowen]

On Fri, Dec 24, 2021 at 2:49 AM passerby184 <tjt...@gmail.com> wrote:
>
> Because "OCSP signing Certificate" shows only once in entire BR, only requirement for them are having id-kp-OCSPSigning and id-pkix-ocsp-nocheck. this doesn't fit anywhere in current requirement: this isn't CA certificate nor subscriber certificate by itself, although ocsp signing role technically added into any of them as BR 7.1.2's extkeyusege limit is 'SHOULD NOT' for this key usage. if we consider this type of certificate isn't a CA, can they be sit outside of HSM and use full CPU power to sign OCSP, which may benefit high volume CAs this may not that dangerous as it sounds if its lifetime is short enough, like a week or 3 days.

From my knowledge of Mozilla policy, the CA/Browser Forum (CA/BF)
documents, RFC, and other trust store requirements, you are accurate
that there are no specific key protection requirements for the private
keys matching OCSP responder certificates. The OCSP responders
provide "validity status", so are "Certificate Systems" and "Issuing
Systems" according to the CA/BF Network and Certificate System
Security Requirements, so the systems that hold and use the keys must
meet security requirements from that document. Nothing in those
requirements precludes "us[ing] the full CPU power to sign OCSP"
responses.

Thanks,
Peter

(my personal view and does not necessarily reflect the views of anyone else)
(posting for myself, not on behalf of anyone)

[Ryan Sleevi]

Right, I think the consequence of OCSP Responder certificates lacking the CA bit (e.g. as enforced by mozilla::pkix and as discussed in the past on this list) means that the protections of the Baseline Requirements, v1.8.0, Section 6.1.1 may no longer apply. That said, given the BRs require id-kp-pkix-nocheck, and RFC 6960/2560 4.2.2.2.1 discusses the security risks that exist in such a scenario, it's entirely reasonable to look a bit askance at a CA that were to use the full CPU power to sign OCSP responses, or, for example, to treat the infrastructure as outside the scope of their audit (as you touched on in your reply).

I had previously proposed in the CA/Browser Forum two efforts to improve this, in light of revelations from the StartCom/WoSign incident, namely, a validity lifetime for OCSP authorized responders of 90 days (or less), and a requirement to treat them to the same key protections afforded to CA keys, given that their compromise is "as serious as the compromise of a CA key used to sign CRLs". 90 days was an upper-bound to try to reflect the costs of distinct ceremonies for every responder. Equally, one matter discussed during one of the F2F was the risk of pre-generation of responder certificates and/or responses substantially far in the future ("pre-dating"), since such certificates/responses would naturally extend the "lifetime" of a compromise. However, this may be less important if the compromise of a responder was simply treated as a compromise of the CA key, and the CA key immediately removed from trust.