| > Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST
include an id-pkix-ocsp-nocheck extension. >For example, consider a certificate like https://crt.sh/?id=2657658699 .
This certificate, from HARICA, meets Mozilla's definition of "Technically
Constrained" for TLS, in that it lacks the id-kp-serverAuth EKU. However,
because it includes the OCSP Signing EKU, this certificate can be used to
sign arbitrary OCSP messages for HARICA's Root! >This also applies to non-technically-constrained sub-CAs. For example,
consider this certificate https://crt.sh/?id=21606064 . It was issued by
DigiCert to Microsoft, granting Microsoft the ability to provide OCSP
responses for any certificate issued by Digicert's Baltimore CyberTrust
Root. We know from DigiCert's disclosures that this is independently
operated by Microsoft. So my understanding is this: The CA's have issued certificates/sub-CA certs without the proper extension (or with too many extensions), causing those to be able to sign a OCSP response. And the Online Certificate Status Protocol (OSCP) is used to check the revocation status of certificates with the CA. So, this would allow e.g Microsoft to generate a fake OCSP response? That would perhaps be useful in some kind of MITM-attack scenario? While not good, perhaps not an end of the world problem either? However, I wonder how much problem will come for people needing to replace those soon to be revoked sub-CA certs... |
Would you trust someone who doesn't take issues seriously because they think they're small or unimportant?
EDIT: reading the full report, it seems that the underlying risk is that if one of the intermediate CAs were to be compromised, even if it was revoked it could theoretically forge an OCSP response that it is still valid (and as a trusted CA issue certs for anything). So the response is very appropriate given the potential impact.