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 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, 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 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 (5) and (6)

dev-security-policy mailing list

Reply via email to