David,
No text in 5280 requires name uniqueness across all CAs. It does require
uniqueness
on a per-CA basis (Section 4.1.2.6 of 5280). So, when two CAs with
different parents
are created with the same name, that is not a violation of 5280. The
creation of
the doppelganger EE certs may violate 5280. The relevant text says:
The DN MUST be unique for each subject entity certified by _the one
CA_ as defined
by the issuer field.
The two CAs in my scenario have different parents, but the same name and
same public key. So
whether they are "the one CA" named in the issuer field is open to
debate. I have modified
my text to avoid this issue.
As I explained, my description of an colluding CA attack differs from
DKGs in that it
is more general and thus. I think, more useful for discussion in the
threat analysis.
Yes, it is true that CRLs and OCSP responses would not generally be tied
to the
two CA instances on different cert paths. But, that's not the point. It
would be dangerous
to assume that an RP can be confident that the revocation status data it
acquires comes
from a specific instance of a CA, when there are two CAs with the same
names and
same public keys. RFC 5280 does not provide implementation guidance that
calls for
pooling of revocation status info based on CA name. An RP may maintain a
cache organized
by cert path, associating revocation status info with each CA in each
cert path. Such
an implementation strategy is attractive because it can allow an RP to
avoid redundant
cert path validation processing when a target cert shares a portion of a
cert path with
other certs that have been validated. In such an implementation an RP
would not be aware that
there are two CAs with the same name on different cert paths, and
revocation status data
associated with each of these CAs would be acquired and maintained
separately. In such
circumstances an attack of the sort I described is feasible.
Thus I stand by my analysis of the vulnerability, in the more general case.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
