Hi Rob, thanks for the clarification. What will be the situation if the issuer is a Root CA instead of the "TLS capable (intermediate or subordinate) CA"? As far as I understood till now, it is not misissued, if the root CA cannot be considered as an "Mozilla-trusted, TLS-capable CA".
And considering chapter 7.1.2.1 b) of CAB Forum BRG, extendedKeyUsage MUST NOT be present in root CA certificates, but "If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set", which is the same in the 7.1.2.2 e) : ". If the Subordinate CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set." I have not seen that the SQL query considered with digitalSignature bit, but as I interpreted until now, the CA cannot sign OCSP responses without setting the digitalSignature bit even the OCSPSigning EKU is used. And Mozilla requires the BRG-conformant CAs also, isn't it? So, I am a bit confused. Thanks again, Peter On Thu, Jul 2, 2020 at 1:21 PM Rob Stradling <r...@sectigo.com> wrote: > 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
