Subject: [Trans] revised text for colluding, malicious CAs

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Mar 2016 14:07:58 -0400

- removed the reference to DKG (it will appear in the 
Acknowledgements section)

     - used "doppelganger" to refer to the bogus EE cert, trying to 
avoid the
       question of whether there are one or two bogus certs

     - removed reference to X.509 (to make David Cooper happier)

     - clarified why revocation by one malicious CA does not cause the 
doppleganger
       EE cert to be treated as revoked by relying parties

     - noted the constraint that the two malicious CAs must not have a 
common trust anchor

Steve
-----

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. (Also note that X. 
RFC 5280 do not preclude creation of doppelganger certificates for 
either CAs or EEs. Requirements for Subject name uniqueness apply 
individually to each CA but not across CA boundaries, and there is no 
requirement for public key uniqueness across CAs.)

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 watching the log(s) to which the certificate was 
posted. Thus the detection aspect of CT still works with regard to this 
certificate. When this certificate is detected, the CA that logged the 
certificate may 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; revocation status checking is performed in the 
context of a certificate path and the doppelganger certificates have 
different certificate paths. Revoking a detected, bogus certificatemay 
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 browser vendors may not feel the need to make an entry on their 
blacklists for the bogus certificate or 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. 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.