Hi Peter. The "following CA certificate" (which I'll call Certificate X) is not capable of issuing id-kp-serverAuth leaf certificates that will be trusted by Mozilla, but that fact is entirely irrelevant to this discussion. Notice that Ryan wrote "issued by a Mozilla-trusted, TLS-capable CA" rather than "is a Mozilla-trusted, TLS-capable CA".
Certificate X contains the id-kp-OCSPSigning EKU. This means that it can be used as a delegated OCSP signer, to sign OCSP responses on behalf of its issuer. If its issuer is "a Mozilla-trusted, TLS-capable CA", then all of its issuer's delegated OCSP signer certificates are in scope for the BRs and for the Mozilla Root Store Policy. Certificate X is an intermediate CA certificate, which is capable of issuing id-kp-timeStamping leaf certificates. That's all very nice, but it doesn't alter the fact that Certificate X is also a (misissued) delegated OCSP signing certificate that is in scope for the BRs and the Mozilla Root Store Policy. ________________________________ From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> on behalf of Peter Mate Erdosi via dev-security-policy <dev-security-policy@lists.mozilla.org> Sent: 02 July 2020 12:04 To: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert Just for my better understanding, is the following CA certificate "TLS-capable"? X509v3 Basic Constraints critical: CA:TRUE X509v3 Key Usage critical: Certificate Sign, CRL Sign X509v3 Extended Key Usage: Time Stamping, OCSP Signing Peter On Thu, Jul 2, 2020 at 12:14 PM Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > 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. > > I just reproduced this result. I've posted my SQL query and (thanks to > GitHub) a searchable TSV report of all 293 certificates here: > https://gist.github.com/robstradling/6c737c97a7a3ab843b6f24747fc9ad1f > > ________________________________ > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > on behalf of Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> > Sent: 01 July 2020 22:05 > 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 > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > > 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 > _______________________________________________ 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
