3.3 Malicious, Colluding CAs
Section 3.2 examined attacks in which a single CA issued a bogus
certificate. There is also the potential that two or more CAs might
collude to issue a bogus certificate in a fashion designed to foil the
remediation safeguards envisioned by CT.
In general, any two CAs that are not name-constrained and do not share a
common path to a trust anchor can collude to create a “doppelganger” EE
certificate that is bogus. The attack need not be initiated by trust
anchors; any subordinate pair of (not name-constrained) CAs can effect
this attack without the knowledge of superiors CAs. (RFC 5280 doe not
preclude the creation of two CAs with the same name, so long as the
parent CAs are distinct. Requirements for Subject name uniqueness apply
individually to each CA but not across CA boundaries. There also is no
requirement for public key uniqueness across all CAs. However, the
creation of doppelganger EE certificates by these CAs may be a violation
of RFC 5280 (if one views the CAs that appear on different certification
paths as one CA).
The attack requires that each of the colluding CAs issues a certificate
for a targeted Subject (e.g., web site). These two (EE) certificates are
identical, hence the use of the term “doppelganger”; they contain the
same name, public key, serial number, etc. Only one of the malicious CAs
logs the bogus certificate and acquires an SCT for it.
The logged bogus certificate can be detected by a Monitor (third party
or self), that is observing the log(s) to which the certificate was
posted. Thus the detection aspect of CT still works with regard to this
(bogus) certificate. When this certificate is detected, the CA that
logged the certificate might choose to revoke it, i.e., place it on a
CRL or create an OCSP response for it. However, a browser checking a CRL
or OCSP response may not match this revocationstatus data against the
doppelganger certificate. This is because revocation status checking is
performed in the context of a certificate path. The doppelganger
certificates have different certificate paths and thus the revocation
status data for each might be acquired and stored independently. (RFC
5280 does not provide implementation guidance for management of
revocation data.) Revoking a detected, bogus certificatemight be the
best strategy for the malicious CA that logged the certificate; it makes
issuance of the bogus certificate appear to be an accident, and thus a
browser vendor might not feel the need to make an entry on its
blacklists for the bogus certificate or for the CA that issued it. (If
the bogus certificate included an AIA extension providing information
for revocation status checking, revocation by the CA that logged the
bogus certificate would not be an effective strategy for these colluding
CAs. However, inclusion of this extension is not mandated by RFC 5280.
Also the extension is not critical, meaning that relying parties are not
required to be able to process it.)
If the CA that logged the bogus certificate fails to revoke it, browser
vendors might blacklist the certificate. However, as noted above, the
doppelganger, which was not logged, will match the SCT created for the
logged certificate. If remediation is effected by blacklisting (instead
of revocation by one of the malicious CAs) then the ability of CT to
deal with this sort of attack may be diminished. Some forms of
blacklisting will cause the not-logged bogus certificate to be detected
and rejected, while others will not, depending on the details of the
blacklisting mechanism. Mechanisms for blacklisting by browsers are not
specified in any IETF standards. The mechanisms are browser-specific,
and the choice of how to blacklist (e.g., the bogus certificate vs. the
CA that issued it) are the purview of each browser vendor. Thus,
depending on the details of the blacklist mechanism and the way that a
browser vendor chooses to manage this list, a doppelganger CA attack
might or might not pose a problem in terms of successful remediation of
the attack.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
