Paul,
...
If the certificates are doppelgangers, wouldn't that mean that they
cannot have AIA's ? Otherwise at least one CA would be using an "unusual"
AIA revocation location that monitors would detect.
The doppelgangers could have AIAs, but they need not, and that is the
assumption
I adopted here. In general it is in the interest of the CAs to not put
AIAs in these certs,
if the plan is to revoke one, but not the other. (Unless the CAs can
control which
revocation status info is accessible to targeted browser users, in which
case it doesn't
matter.)
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 revocation status data against the doppelganger
certificate.
So either the EE-certificates have different AIA's and are not
doppelgangers,
or they would have the same AIA's and a browser would always find the
matching CRL/OCSP responses?
There is no requirement that certs contain an AIA extension. It also is
not mandated by
5280, nor is it required for EE certs that meet the CABF DV or EV profiles.
Or the EE-certs cannot contain AIA
revocation information (which in itself should be unusual enough for
monitors to pick up)
Because there is no requirement in 5280 (or in DV/EV profiles) that any
cert to contain an AIA
extension, that is hardly a reason for a Monitor to flag these cert. CA
certs
MUST contain a CRL DP extension if they conform to the DV or EV
profiles. But, it appears
that most browsers do not fetch CRLs, so this mandate for DV/EV certs is
probably moot.
The proposal that I put forth over a year ago would allow a CA to assert
that it was
issuing a cert that conformed to DV or EV profiles. If that extension to
the cert submission
data and SCT were adopted, then it would make sense for a Monitor to
flag a CA cert
that lacked a CRL DP extension, and which claimed to be issued under
these profiles.
But, that proposal went nowhere, so ...
A Monitor should notify a Subject if the Monitor detects a logged cert
that does not
have the same public key as a registered by the Subject with the same DN
or AltName
(as described in draft-kent-trans-monitor-auditor-00.txt, but not
mentioned in 6962-bis).
My understanding is that a lot of code (eg NSS) ignores AIA revocation
information specified on the Root CA's, but do check them on the
intermediate CA's and EE-certs, so I guess the attack can work if the
EE-cert has no AIA but the intermediate CA's do? But I guess it would
also be odd for an intermediate CA with AIA revocation on it, to issue
EE-certifications with no AIA revocation information in it?
As I noted above, there is no requirement (in 5280 or in CABF profiles)
that a cert
contain an AIA extension. Also, the colluding CA certs can contain AIA
extensions,
but those point to revocation data issued by their parents. If the
colluding CA certs
contained CRL DP data it could be different for each. Tthere is no
requirement that those
certs be identical; they need only share the same Subject name for the
attack to work.
In fact using two different CRLs for these two colluding CAs might even
help, as it would
naturally direct RPs to different sources for revocation status info.
Thus the CA that
revoked the bogus cert would have a different CRL from its partner, and
an RP would
associate the tow different CRLs with the two CAs (on different paths),
thus supporting
the attack.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
