David,
I have never believed that "the X.500 directory tree is the basis for
all names in certs.," and you know that!
your assertion that X.509 requires all name uniqueness across CA
boundaries makes sense
only in the context of an X.500 DIT world. We had this debate already in
the RPKI context
a few years ago. That WG disagreed with your assertion, and nothign has
changed to suggest
a different resolution this time. But, I.ve removed the mention of X.509
from my proposed
text, so this is moot.
Nor does that have anything to do with what I said in my previous email.
it was an attempt to explain your statement about global name uniqueness.
There's no reason for you to rebut my analysis. What is needed is for
someone to write a description of the attack scenario that accurately
describes the attack scenario DKG presented, and the text you proposed
doesn't do that.
DKG's description was a bit narrow compared to the full range of
possible attacks enabled
by colluding CAs. I changed the description to try to capture the
broader attack space. That's
why it differs from DKG's original wording.
If my description of the scenario is so wrong, then please explain (in
detail) how a relying party would be able to determine that there are
two distinct intermediate CAs in this scenario and not a single CA
that has been issued cross-certificates by two different roots (as
depicted in my diagrams) and how that fits in with your response to
Ben Laurie that:
the two colluding CAs appear in different cert paths, and thus an RP
following one cert
path may see revocation status info for only the CA that issued and
logged the bogus cert.
Remember that the two malicious CAs have the same Subject name but
different Issuer names
in their certs, so they are distinct in terms of cert paths. A malocious
web site can send
a full cert path to the browser and thus direct the browser to validate
the EE cert relative
to the CA that did not log the cert and did not revoke it.
The fact that Ben (and Rob) questioned why the revocation status info
from one CA would
not match the other CA is an issue I addressed in my replies to them.
What information (specifically) would appear in a CRL or OCSP response
issued by a CA on one path that would make it distinguishable to a
relying party from a CRL or OCSP response issued by a CA on the other
path in the scenario DKG described?
I'm afraid this question is not relevant to the attack I described.
A web server also can supply OCSP data to a browser as part of the TLS
handshake (RFC 6066),
thus it may influence the revocation status info that the browser sees.
(RFC 6066 allows a
client to send a list of OCSP servers that it trusts, but it also allows
a null list to
indicate that the client assumes that the server knows what this list
is, implicitly.
The client should verify that the returned OCSP response matches what it
asked for, but
given the history of buggy browser PKI software, I would not be too
confident in how
rigorously this is implemented in all browsers.) In this fashion a bogus
web server, aided
by a malicious CA, may be able to supply revocation status data that
reflects the not-logged and
not-revoked instance of the bogus cert.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
