Subject: AW: Briefing on CRL Path for IETF PKIX WG Meeting

From: [email-masked]
Date: Wed, 27 Oct 2004 14:06:55 +0200

See below 

> -----Ursprüngliche Nachricht-----
> Von: Jean-Marc Desperrier [mailto:[email-masked]]
> Gesendet: Mittwoch, 27. Oktober 2004 13:18
> An: [email-masked]
> Betreff: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> 
> Denis Pinkas wrote:
> 
> > A minor point first. On slide 3, it is written:
> >
> > "A CA is defined by a name alone".
> >
> > This is contradicted 3 slides after when it is said:
> > "There can be more than one CA with the same name".
> 
> I'd say that the X509 rule is that a CA is defined by it's DN alone, 
> therefore one should never try to create two CA with the same DN in a 
> properly managed hierarchy.

Jean-Marc, what do you mean by "creating two CAs with the same DN"? What you
mean is to "create two certificates containing the same DN". And this means
both certificates belong to the same CA. This is IMHO useful e. g. for key
turnover. The fraud you mentioned below is only applicable on TAs. The
naming of subordinate CAs is within the responsibility of the certificate
issuing CA(TA). In the case of TAs you will ever have the problem, that
somebody may create a certificate with the TAs DN an publish it.

Regards

Thomas Beckmann

> 
> But that the pkix Internet profile has to envision cases 
> where it's will 
> not be possible to absolutly garantee this will never happen and 
> therefore must protect itself against the security issues 
> raised by such 
> a situation and impose more stringent rules for certification 
> paths that 
> wil properly handle even that case.
> 
> One interesting question this raises is the following :
> If we don't consider the restriction we need for pkix, what 
> would be the 
> X509 compliant way to handle the case where you have two CA 
> certificates 
> with the same DN inside separate certification path ?
> I see two possible answer :
> - This is forbidden, and one or both of the certificates should be 
> handled as invalid when a client discovers such a case.
> - They validly cover the same CA, and validation may be made using 
> either path.
> 
> What is raised here is that the second solution is not acceptable for 
> pkix, because it makes it possible for anybody who was given the 
> autority to emit a CA certificate to impersonate any other CA in the 
> hirarchy.
> Several aspects of X509 make me believe it's not really intended for 
> X509 either.
>

---

From: Tom Gindin <[email-masked]>
Date: Thu, 28 Oct 2004 22:46:04 -0400

Thomas:

        One comment below, clarifying the meaning of a "trust anchor"

                Tom Gindin

[email-masked]
Sent by: [email-masked]
10/27/2004 08:06 AM
 
        To:     [email-masked], [email-masked]
        cc: 
        Subject:        AW: Briefing on CRL Path for IETF PKIX WG Meeting

See below 

> properly managed hierarchy.

Jean-Marc, what do you mean by "creating two CAs with the same DN"? What 
you
mean is to "create two certificates containing the same DN". And this 
means
both certificates belong to the same CA. This is IMHO useful e. g. for key
turnover. The fraud you mentioned below is only applicable on TAs. The
naming of subordinate CAs is within the responsibility of the certificate
issuing CA(TA). In the case of TAs you will ever have the problem, that
somebody may create a certificate with the TAs DN an publish it.

[TG] This isn't the problem, since the definition of a TA is required to 
include a public key as well as a DN, even though most displays of a 
certificate within a local store of anchors skip the key.  The danger is 
that a CA (either a TA or some other CA certified by a TA) can create a 
certificate which creates a fraudulent subordinate CA with the same DN as 
an existing CA, but a key under his own control.  That's a good example of 
why some of us have been advocating the assertion of constraints on TA's. 
This sort of false delegation would still be an issue even if the RP did 
not trust any legitimate path to a given CA.

Regards

Thomas Beckmann