I described some of the vulnerabilities that I was referring to in a
message on March 25, and they had nothing to do with CT or DKG's attack.
The problem is that Steve's proposed text for Section 3.3 includes a
false statement about RFC 5280. The rest of the text then seems to have
been written in a way to try to justify the inclusion of this false
statement, with the result that it is very confusing, and it is leading
some people on this list to believe that X.509 must be broken.
My point was that both X.509 and PKIX (RFC 5280 is just a profile of
X.509) work well as long as there are not two different trusted entities
(e.g., CAs, CRL issuers, OCSP responders) that operate under the same
entity, but that if Steve's claim about RFC 5280 was true, there would
be vulnerabilities in PKIX profiles/protocols even if all of the CAs in
the PKI were honest and followed the requirements in RFC 5280. An
example of a vulnerability (see the March 25 email) would be that a
relying party might use a CRL issued by one CA to determine the status
of a certificate issued by another CA, even though the CAs are unrelated
and the CRL doesn't actually provide any status information about
certificates issued by the other CA. This would happen even though
neither CA was trying to "attack" the other, and they were just each
operating in a way that Steve claims that RFC 5280 allows.
I agree with you about "metaphysics." When I read Steve's text, I
couldn't understand what it was trying to say, even though I was the
primary author of RFC 5280 and have been working in PKI for almost 20
years. When I then read DKG's email, it was very easy for me to
understand the attack he was trying to describe, and it was clear that
it was not the same as what Steve was describing in his text.
If Steve would just describe DKG's attack instead of trying to use this
as a forum for advancing his personal beliefs about X.509, then we
wouldn't have to deal with these metaphysical arguments.
On 03/30/2016 12:09 PM, Watson Ladd wrote:
On Wed, Mar 30, 2016 at 9:02 AM, David A. Cooper <[email protected]> wrote:
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.
What "vulnerability" is created? The reason DKG's attack functions is
CT records the end entity certificate,
In the attack model the conspiring CAs can just ignore the requirement
on name validity. I don't see why X509 protects against this more.
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.
Define "entity". End of the day there are only bits: the question is
how implementations will behave when given two bitstrings concocted in
the way described by DKG. Disputes over the metaphysics are really
in(trans)substantial.
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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
