On Wed, Dec 29, 2021 at 11:53 AM Peter Bowen <[email protected]> wrote:
> On Fri, Dec 24, 2021 at 2:49 AM passerby184 <[email protected]> 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. > 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. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHF__7YsnfkiVJ5qmNnkKRE5o%3D_q655_0iAUPaT_Ap-ADA%40mail.gmail.com.
