I've created a new batch of certificates that violate 4.9.9 of the BRs, which was introduced with the first version of the Baseline Requirements as a MUST. This is https://misissued.com/batch/138/
A quick inspection among the affected CAs include O fields of: QuoVadis, GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus, Actalis, Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC. Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP Delegated Responder within Section 4.2.2.2 as indicated by the presence of the id-kp-OCSPSigning as an EKU. These certificates lack the necessary extension, and as such, violate the BRs. As the vast majority of these were issued on-or-after 2013-02-01, the Effective Date of Mozilla Root CA Policy v2.1, these are misissued. You could also consider the effective date as 2013-05-15, described later in [1] , without changing the results. This batch is NOT comprehensive. According to crt.sh, there are approximately 293 certificates that meet the criteria of "issued by a Mozilla-trusted, TLS-capable CA, with the OCSPSigning EKU, and without pkix-nocheck". misissued.com had some issues with parsing some of these certificates, due to other non-conformities, so I only included a sample. Censys.io is aware of approximately 276 certificates that meet this criteria, as you can see at [2]. The differences in perspectives underscores the importance of CAs needing to carefully examine the certificates they've issued to understand. It's important for CAs to understand this is Security Relevant. While they should proceed with revoking these CAs within seven (7) days, as defined under the Baseline Requirements Section 4.9.1.2, the degree of this issue likely also justifies requiring witnessed Key Destruction Reports, in order to preserve the integrity of the issuer of these certificates (which may include the CA's root). The reason for this is simple: In every case I examined, these are certificates that appear to nominally be intended as Issuing CAs, not as OCSP Responder Certificates. It would appear that many CAs were unfamiliar with RFC 6960 when constructing their certificate profiles, and similarly ignored discussion of this issue in the past [3], which highlighted the security impact of this. I've flagged this as a SECURITY matter for CAs to carefully review, because in the cases where a third-party, other than the Issuing CA, operates such a certificate, the Issuing CA has delegated the ability to mint arbitrary OCSP responses to this third-party! 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. Unfortunately, revocation of this certificate is simply not enough to protect Mozilla TLS users. This is because this Sub-CA COULD provide OCSP for itself that would successfully validate, AND provide OCSP for other revoked sub-CAs, even if it was revoked. That is, if this Sub-CA's key was maliciously used to sign a GOOD response for itself, it would be accepted. These security concerns are discussed in Section 4.2.2.2.1 of RFC 6960, and is tied to a reliance on the CRL. Mozilla users COULD be protected through the use of OneCRL, although this would not protect other PKI participants or use cases that don't use OneCRL. A little more than a third of the affected certificates have already been revoked, which is encouraging. However, I'm not aware of any incident reports discussing this failure, nor am I aware of any key destruction reports to provide assurance that these keys cannot be used maliciously. While this seems like a benign failure of "we used the wrong profile", it has a meaningful security impact to end users, even if it was made with the best of intentions. This has been a requirement of the BRs since the first version, and is spelled out within the OCSP RFCs, and CAs are expected to be deeply knowledgeable in both of these areas. There is no excusing such an oversight, especially if it was (most likely) to work around an issue with a particular CA Software Vendor's product. Recall that the same justification (work around an issue in a vendor's product) has been used to justify MITM interception. Ignorance and malice are, unfortunately, often indistinguishable, and thus have to be treated the same. While I'll be looking to create Compliance Incidents for the affected CAs, and attempting to report through their problem reporting mechanisms, the fact that it is the constrained CAs which are not yet required to be disclosed, and most likely invisible to CT (e.g. S/MIME issuing CAs that do not issue TLS), still pose substantial risk, that it requires every CA closely examine their practices. CAs affected MUST ensure they revoke such certificates within 7 days, as per 4.9.1.2 (5) and 4.9.1.2 (6) [1] https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy [2] https://censys.io/certificates?q=%28parsed.extensions.extended_key_usage.ocsp_signing%3Atrue+and+validation.nss.valid%3Atrue+and+parsed.validity.start%3A%5B2013-05-15+TO+*%5D%29+and+not+parsed.unknown_extensions.id%3A1.3.6.1.5.5.7.48.1.5 [3] https://groups.google.com/d/msg/mozilla.dev.security.policy/XQd3rNF4yOo/bXYjt1mZAwAJ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
