GlobalSign recognizes the reported security issue and associated risk, and is working on a plan to remediate the impacted CA hierarchies with first priority on terminating those branches that include issuing CA with private keys outside of GlobalSign's realm. We will soon share an initial plan on our Bugzilla ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1649937.
One question we have for the root store operators specifically is what type of assurance they are looking for on the key destruction activities. In the past we've both done key destruction ceremonies without and with (e.g. in the case of addressing a compliance issue like https://bugzilla.mozilla.org/show_bug.cgi?id=1591005) an external auditor witnessing the destruction and issuing an independent ISAE3000 witnessing report. > -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: woensdag 1 juli 2020 23:06 > To: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous > Delegated Responder Cert > > 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_C As > _to_comply_with_the_new_policy > [2] > https://censys.io/certificates?q=%28parsed.extensions.extended_key_usage.ocs p > _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/bXYj t > 1mZAwAJ > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
