David,
I appreciate your persistence, but we will just have to agree to
disagree on the
topic of whether 5280 requires global name uniqueness.
First, I cited text from Secyion 4.1.2.6, which is the one place in 5280
where global
name uniqueness should be mandated if it were a requirement. That
section establishes a
requirement for local (per-CA) name uniqueness, not for global name
uniqueness. IMHO
that is the definitive statement on this topic.
RFC 5280, like its predecessors, has deviated from X.509 where we felt
necessary. Your
argument that PKIX docs will maintain compatibility with X.509 is just
an indication
of overall intent, not a promise to never deviate. You acknowledge this
later when you
discuss CRL issuer paths and say ".. a requirement imposed by RFC 5280,
but not X.509."
Yes, the Security Considerations section of 5280 notes that problems
that can arise if
names are not globally unique. However, that is not the same as saying
that 5280 requires
them to be so. Rather it is a warning of the bad things that may happen
if name collisions
occur. A warning in the Security Considerations section the way we
usually note a residual
vulnerability in a standard. It is NOT a backdoor way to add a
requirement to a standard.
Your other comments cite text that, in your opinion, suggests the need
for global name
uniqueness, rather than citing text that establishes this requirement.
Hence I'm not going
to spend time addressing those comments.
Aside from the gratuitous parenthetical in your text falsely stating
that RFC 5280 "doe not preclude the creation of two CAs with the same
name, so long as the parent CAs are distinct," you still write about
two CAs issuing two EE certificates that are identical. If it walks
like a duck and it quacks like a duck, then chances are its a duck. In
the scenario you are trying to describe, there is one CA that issues
one EE certificate.
One might argue that two entities acting as CAs that have the same name
and same public
key are the same CA. But if the entities happen to be different
organizations, perhaps
in different geopolitical regions, others might argue that they are
different CAs.
Can you name even one RP that maintains a cache of revocation status
info organized by cert path?
BBN has implemented RP code for at least 4 products over the past 20
years. Some were part
of PKI systems developed for clients in the financial services area. The
most recent is
the RPSTIR code for the RPKI. All of them operate as I described.
I'll discuss whether my attack scenarios are accurate and match the
spirit of DKGs original
message with him, not you.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
