Subject: Briefing on CRL Path for IETF PKIX WG Meeting

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 26 Oct 2004 05:32:38 -0400

Denis:
 
The following URL is the location for the briefing you requested to be
posted.
 
 <http://www.orionsec.com/crldp-idp-v3.ppt>
www.orionsec.com/crldp-idp-v3.ppt
 
Santosh Chokhani 
Orion Security Solutions, Inc. 
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101 
(703) 917-0060  Ext. 35 (voice) 
(703) 917-0260 (Fax) 
[email-masked] 
Visit our Web site 
http://www.orionsec.com <http://www.orionsec.com/>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 27 Oct 2004 11:28:37 +0200

Santosh,

> www.orionsec.com/crldp-idp-v3.ppt <http://www.orionsec.com/crldp-idp-v3.ppt>

Many thanks. I browsed thru it.

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".

Unless it is aid which CA provides the name of tha tCA, this is meaningless.
If we apply this recursively, then a CA name is composed of a name given by 
another CA, whose name is given by another CA, whose name is given by 
another CA, ..., whose name is given by a TA.

This could be what is meant in the last bullet point of slide 8 :
"Starting with a TA, the relying party can match the CA names in the 
certificate and CRL certification paths", but this is far from crystal clear.

Now the major points.

The same would apply to a CRL issuer name, UNLESS it is clear which CA can 
nominate that CRL Issuer. Unfortunately, this point is also far from crystal 
clear.

Before diving into the details of algorithms for CRL path processing, it is 
important to agree on which cases we will cover.

The case where the AC is the CRL Issuer is easy when it is the same key.

The case where the AC is the CRL Issuer but there has been a key change is 
already more complex.

Now when the CRL Isssuer is not the CA we need to consider two cases:

   a) the CA got no right to issue CRLs (it only got a CA certificate
      with the keyCertSign bit (bit 5),

   b) the CA got the right to issue CRLs (it got a CA certificate with both
      bits sets, i.e. keyCertSign bit (bit 5) and cRLSign bit (bit 6).

These two cases would need to be addressed in details.

Finally we would have to clarify what is an indirect CRL Issuer and what 
kind of processing would be done in taht case.

Now, if we go just a litte bit under the details of some slides, there is no 
notion of a certification path with CRL isssuer names.

A path may end up with a CRL Issuer name, but only CA names are allowed in 
the certification path. So slide 10 is incorrect and by implication 
subsequent slides 11 and 12 are incorrect too.

Denis

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 27 Oct 2004 13:18:04 +0200

> "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.

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: Denis Pinkas <[email-masked]>
Date: Wed, 27 Oct 2004 13:59:32 +0200

Jean-Marc,

>> "There can be more than one CA with the same name".

You cut the original message I sent and thus you missed the explanation.
See later down.

> properly managed hierarchy.

For X.509, I do *not* say X.500, a DN is only relative to the CA who has 
given it.

> with the same DN inside separate certification path ?

It is perfectly allowed to have two CA certificates with the same CA DN 
inside which do not refer to the same CA (i.e.entity).

> handled as invalid when a client discovers such a case.

No, since this is allowed.

> - They validly cover the same CA, and validation may be made using 

This is neither true.

The sentence you cut provides you with the explanation:

"If we apply this recursively, then a CA name is composed of a name given by 
another CA, whose name is given by another CA, whose name is given by 
another CA, ..., whose name is given by a TA."

The single rule is: every CA MUST never assign the same DN to two different 
entities.

Denis

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 27 Oct 2004 17:31:57 +0200

Denis Pinkas wrote:

> For X.509, I do *not* say X.500, a DN is only relative to the CA who 
> has given it.

I had no idea we had established that.
I only remember several messages asking why we would try to handle in 
PKIX the case of several CA with the same DN as it's invalid.

In his presentation, to show that a CA is defined by name alone, Santosh 
refers specifically only to section 7 of X.509, and I think that must be 
in reference to the following sentence :
NOTE 1 — Although the CAs are unambiguously defined by a distinguished 
name in the DIT, this does not imply that there is any relationship 
between the organization of the CAs and the DIT
which I don't see as supporting what you say.

I can see that you already said the same thing from this message
http://www.imc.org/ietf-pkix/mail-archive/msg03305.html
Quote :
"[Denis : a CA can never be defined by a name only. It is a name issued 
by a given CA. It can also be a root key with a sequence of names. These 
are the only ways names can be unambiguous].

[Santosh: I do not find support for anything other than Issuer being identified by DN only in X.509 and 3280.]"

But I can not find any message in which you gave additional info in answer to Santosh's doubts.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 27 Oct 2004 14:40:45 -0400

Denis,

See responses inline in [SC:]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Wednesday, October 27, 2004 5:29 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

[SC: There is no contradiction.  This concern is what the path matching
logic is all about.  When there are two or more "X", we are trying to sure
that we are talking about the same "X"]

This could be what is meant in the last bullet point of slide 8 : "Starting
with a TA, the relying party can match the CA names in the 
certificate and CRL certification paths", but this is far from crystal
clear.

[SC: Your suggestion that a CA name is disambiguated by ancestors is what
the algorithm does]
Now the major points.

clear.

[SC: Since there could be two or more "X" as CRL issuers, that is why we
need the path matching algorithm]

[SC: We cover all the cases]

[SC: What is AC?  If you mean CA, this case is covered]

[SC: What is AC?  If you mean CA, this case is covered by the path matching
algorithm]

[SC: We are not covering all the validation logic that is already in 3280.
We are focusing on added rules for making sure we are dealing with the
correct "X"]

[SC: We are not covering all the validation logic that is already in 3280.
We are focusing on added rules for making sure we are dealing with the
correct "X"]

[SC: Indirect CRL is defined in 3280.  The path matching algorithm covers
this]

[SC: All the certificates on slide 10 are issued by CAs with the possible
exception to the last one.  The node names are different, but does not mean
that the CAs are not issuing certificates]

[SC: These are all CA names.  We can change the tags if that helps you]

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 27 Oct 2004 17:24:32 -0400

Jean-Marc:

I agree that X.509 and 3280 define a CA by name.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean-Marc Desperrier
Sent: Wednesday, October 27, 2004 11:32 AM
To: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

NOTE 1 - Although the CAs are unambiguously defined by a distinguished 

[Santosh: I do not find support for anything other than Issuer being
identified by DN only in X.509 and 3280.]"

But I can not find any message in which you gave additional info in answer
to Santosh's doubts.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 28 Oct 2004 15:58:40 +0200

Santosh,

> I agree that X.509 and 3280 define a CA by name.

You disagree since you said: "a CA name is disambiguated by ancestors",
which is true.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 28 Oct 2004 15:58:22 +0200

Santosh

See responses inline in [DP:]

Santosh,

[DP: So you agree that name comparison alone is not sufficient since a CA 
name MUST be disambiguated by ancestors].

Now the major points.

[SC: Since there could be two or more "X" as CRL issuers, that is why we
need the path matching algorithm].

[DP: Before knowing the algorithm, we need to know what are the trust 
conditions.]

[DP: This does not mean anything]

[SC: What is AC?  If you mean CA, this case is covered]
[DP: For sure, "AC" is the acronym of CA in French]

[DP: The problem is that RFC 3280 does not have any well described 
validation logic for a CRL Issuer diffrent from the CA.]

[SC: We are not covering all the validation logic that is already in 3280.
[DP: There is not such a logic in RFC 3280]

[DP: What is the trust model ?]

[SC: These are all CA names.  We can change the tags if that helps you]
[DP: That change will certainly help. Please do it and re-issue the slides].

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 28 Oct 2004 15:32:18 -0400

Denis,

The CA name is defined by DN.  Since multiple CAs could have the same name,
in order to disambiguate the CA, you should consider the ancestors.  That is
what the algorithm does.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, October 28, 2004 9:59 AM
To: Santosh Chokhani
Cc: 'Jean-Marc Desperrier'; [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

Denis

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jean-Marc 
> Desperrier

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 28 Oct 2004 15:30:30 -0400

Denis,

The matching algorithm proposed checks/compares the ancestors.  This
algorithm is nothing more than formalism of something you agreed to in 2003
on this list.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, October 28, 2004 9:58 AM
To: Santosh Chokhani
Cc: [email-masked]; David A. Cooper
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh

Santosh,

 > The following URL is the location for the briefing you requested to be  >
posted.  >  > www.orionsec.com/crldp-idp-v3.ppt  >
<http://www.orionsec.com/crldp-idp-v3.ppt>

This could be what is meant in the last bullet point of slide 8 : "Starting
with a TA, the relying party can match the CA names in the certificate and
CRL certification paths", but this is far from crystal clear.

Now the major points.

Denis