- 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.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
