All,
Thank you to Ryan for identifying this problem, and to all of you who are earnestly investigating what this problem means and the impact to your CA hierarchies. Mozilla::pkix requires that an OCSP responder certificate be an end entity certificate, so we believe that Firefox and Thunderbird are not impacted by this problem. Historically, as per https://bugzilla.mozilla.org/show_bug.cgi?id=991209#c10, Mozilla has allowed CA certificates to have the OCSP signing EKU because some CAs reported that some Microsoft server software required CA certificates to have the id-kp-OCSPSigning EKU. The comments in the code[1] say // When validating anything other than an delegated OCSP signing cert, // reject any cert that also claims to be an OCSP responder, because such // a cert does not make sense. For example, if an SSL certificate were to // assert id-kp-OCSPSigning then it could sign OCSP responses for itself, // if not for this check. // That said, we accept CA certificates with id-kp-OCSPSigning because // some CAs in Mozilla's CA program have issued such intermediate // certificates, and because some CAs have reported some Microsoft server // software wrongly requires CA certificates to have id-kp-OCSPSigning. // Allowing this exception does not cause any security issues because we // require delegated OCSP response signing certificates to be end-entity // certificates. Additionally, as you all know, Firefox uses OneCRL for checking the revocation status of intermediate certificates, so as long as the revoked intermediate certificate is in OneCRL, the third-party would not be able to “unrevoke” their certificate (for Firefox). Therefore, Mozilla does not need the certificates that incorrectly have the id-kp-OCSPSigning EKU to be revoked within the next 7 days, as per section 4.9.1.2 of the BRs. However, as Ryan has pointed out in this thread, others may still have risk because they may not have a OneCRL equivalent, or they may have certificate verification implementations that behave differently than mozilla::pkix in regards to processing OCSP responder certificates. Therefore, it is important to identify a path forward to resolve the security risk that this problem causes to the ecosystem. We are concerned that revoking these impacted intermediate certificates within 7 days could cause more damage to the ecosystem than is warranted for this particular problem. Therefore, Mozilla does not plan to hold CAs to the BR requirement to revoke these certificates within 7 days. However, an additional Incident Report for delayed revocation will still be required, as per our documented process[2]. We want to work with CAs to identify a path forward, which includes determining a reasonable timeline and approach to replacing the certificates that incorrectly have the id-kp-OCSPSigning EKU (and performing key destruction for them). Therefore, we are looking forward to your continued input in this discussion about the proper response for CAs to take to resolve the security risks caused by this problem, and ensure that this problem is not repeated in future certificates. We also look forward to your suggestions on how we can improve OCSP responder requirements in Mozilla’s Root Store Policy, and to your continued involvement in the CA/Browser Forum to improve the BRs. Thanks, Ben [1] https://dxr.mozilla.org/mozilla-central/rev/c68fe15a81fc2dc9fc5765f3be2573519c09b6c1/security/nss/lib/mozpkix/lib/pkixcheck.cpp#858-869 [2] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation On Wed, Jul 1, 2020 at 3:06 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
