|
So, your contention is that PKIX
diverged from X.509 by removing the requirement for names to be
unambiguous, and did nothing to address the vulnerability created
by this divergence other than noting the vulnerability in the
Security Considerations sections of its documents? The working
group then went on to develop protocols and profiles that relied
on names being unambiguous, and then just noted in the Security
Considerations that an unnecessary vulnerability had been created?
I have even looked for evidence that the PKIX WG discussed the
idea of deviating from X.509 and allowing names to be ambiguous
(i.e., unrelated entities operating under the same name) and have
been unable to find any evidence of that on the mail list. I have,
however, heard an explanation for why the text in Section 4.1.2.6
says what it does, and it was not about a deliberate decision to
deviate from X.509.
The proposed text for Section 3.3 seems to be written with the
goal of advancing your personal belief about what RFC 5280 does or
does not require rather than trying to explain a potential attack
in the clearest way possible. Removing the parenthetical about RFC
5280 and simply referring to the intermediate CA and EE as the
single entities that they are would go a long way towards
improving the text.
On 03/30/2016 10:25 AM, Stephen Kent wrote:
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
|
