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

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Nov 2004 15:47:56 +0100

Santosh,

> Denis,

> The matching algorithm proposed checks/compares the ancestors.

The matching algorithm is missing to say "who" trusts "somebody" for "what".
Unless this is clearly said, there is no trust possible and thus no 
algorithm possible.

 > This algorithm is nothing more than formalism of something you agreed
 > to in 2003 on this list.

I don't think so.

Denis

> -----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
> 
> See responses inline in [DP:]
> 
> Santosh,
> 
>  > Denis:
> 
>  > 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>
> 
> 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".
> 
> [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"]
> 
> 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.
> 
> [SC: Your suggestion that a CA name is disambiguated by ancestors is what
> the algorithm does]
> 
> [DP: So you agree that name comparison alone is not sufficient since a CA 
> name MUST be disambiguated by ancestors].
> 
> 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.
> 
> [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.]
> 
> Before diving into the details of algorithms for CRL path processing, it is
> important to agree on which cases we will cover.
> 
> [SC: We cover all the cases]
> 
> [DP: This does not mean anything]
> 
> The case where the AC is the CRL Issuer is easy when it is the same key.
> 
> [SC: What is AC?  If you mean CA, this case is covered]
> [DP: For sure, "AC" is the acronym of CA in French]
> 
> The case where the AC is the CRL Issuer but there has been a key change is
> already more complex.
> 
> [SC: What is AC?  If you mean CA, this case is covered by the path matching
> algorithm]
> 
> 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),
> 
> [SC: We are not covering all the validation logic that is already in 3280.
> 
> [DP: The problem is that RFC 3280 does not have any well described 
> validation logic for a CRL Issuer diffrent from the CA.]
> 
> We are focusing on added rules for making sure we are dealing with the
> correct "X"]
> 
>     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).
> 
> [SC: We are not covering all the validation logic that is already in 3280.
> [DP: There is not such a logic in RFC 3280]
> 
> We are focusing on added rules for making sure we are dealing with the
> correct "X"]
> 
> 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.
> 
> [SC: Indirect CRL is defined in 3280.  The path matching algorithm covers
> this]
> 
> [DP: What is the trust model ?]
> 
> 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.
> 
> [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]
> 
> 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.
> 
> [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
> 
> 
>  > 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]
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 3 Nov 2004 10:19:16 -0500

Denis.

See responses in-line in [SC:]

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Wednesday, November 03, 2004 9:48 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

[SC: The two paths needs to be verified in accordance with 3280 in order to
establish trust]

 > This algorithm is nothing more than formalism of something you agreed  >
to in 2003 on this list.

I don't think so.

[SC: Go back to September 2003 archive of your response to my post and tell
me what is not covered]

Denis

>  > The following URL is the location for the briefing you requested to 
> be  > posted.  >  > www.orionsec.com/crldp-idp-v3.ppt  > 
> [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"]
> 
> 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.
> 
> [SC: Your suggestion that a CA name is disambiguated by ancestors is 
> what the algorithm does]
> 
> 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.
> 
> [SC: Since there could be two or more "X" as CRL issuers, that is why 
> we need the path matching algorithm].
> 
> 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 but there has been a key 
> change is already more complex.
> 
> [SC: What is AC?  If you mean CA, this case is covered by the path 
> matching algorithm]
> 
> Finally we would have to clarify what is an indirect CRL Issuer and 
> what kind of processing would be done in taht case.
> 
> [SC: Indirect CRL is defined in 3280.  The path matching algorithm 
> covers this]
> 
> 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.
> 
> [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]
> 
> 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.
>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 04 Nov 2004 18:40:13 +0100

Santosh,

See responses in-line in [DP:]

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, November 03, 2004 9:48 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

[DP: the certification path needs to be verified according to RFC 3280.
The problem is that RFC 3280 does not tell how to verify that the CRL comes 
from the right CRL Issuer. Your assumption that the "two paths needs to be 
verified in accordance with 3280 in order to establish trust" is thus 
incorrect].

I don't think so.

[DP: You would need to be more precise and provide me an extract of what you 
refer to]

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 4 Nov 2004 15:51:31 -0500

Denis,

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, November 04, 2004 12:40 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, November 03, 2004 9:48 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

[DP: the certification path needs to be verified according to RFC 3280. The
problem is that RFC 3280 does not tell how to verify that the CRL comes 
from the right CRL Issuer. Your assumption that the "two paths needs to be 
verified in accordance with 3280 in order to establish trust" is thus 
incorrect].

[SC: When you augment 3280 with the algorithm I proposed, that takes care of
it.  It goes without saying that 3280 needs to be augmented with the
algorithm]

to in 2003 on this list.

I don't think so.

refer to]

[SC: It was short string of e-mails on the subject matter in September 2003.
I am sure you can find it from the archives.  It may be overcome by events
since your recent postings show that you agree with me]

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 05 Nov 2004 16:04:41 +0100

Santosh,

> it.  It goes without saying that 3280 needs to be augmented with the

This is exactly what I disagree with.

Let us talk about the key issue. The question is: how can a RP (relying 
party) know that, for a given end-user certificate, the CRL he got is indeed 
issued by the right CRL Issuer ?

In the following discussion, I am only considering the case where the CRL 
Issuer is *not* the CA (this CA is called CA 1).

CA 2 is a CA that has issued a CA certificate to CA 1.

The text is currently so vague that different models are indeed 
theoritically possible. In particular:

  a) the CRL Issuer is nominated by CA 1 that has issued
     the end-user certificate. This case would make sense
     when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
     that role to one or more CRL Issuers. This means that
     a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.

  b) the CRL Issuer is nominated by CA 2 that has issued a CA
     certificate to CA 1. This case would make sense when CA 2
     has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
     certificate is issued by CA 2 to every CRL Issuer. CA 1 may
     then only choose a CRL Issuer that has been granted
     the authorization to issue CRLs by CA 2.

I wonder if I understand correctly the model you proposed, but (please 
correct if wrong) you have a set of trust points to verify the certification 
chain, and another set of trust points to verify what you call a 
certification path for the CRL Issuer.

There would be many problems with such a model to define correctly 
validation policies, since the two chains would be unrelated and any CA from 
that chain could nominate CRL Issuers used by any CA.

In options a) and b) mentioned above, a single trust point is used to 
validate both the certification chain and the CRL Issuer.

In any case, we need to clarify this topic in 3280bis, whatever the 
clarification will be.

> [SC: It was short string of e-mails on the subject matter in September 2003.

Hum !!! Hum !!!
Do not mention "free" assertions when you are not sure about.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 5 Nov 2004 16:13:51 -0500

Denis,

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Friday, November 05, 2004 10:05 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

> The matching algorithm is missing to say "who" trusts "somebody" for
> "what". Unless this is clearly said, there is no trust possible and 
> thus no algorithm possible.
> 
> [SC: The two paths needs to be verified in accordance with 3280 in
> order to establish trust]
> 
> [DP: the certification path needs to be verified according to RFC
> 3280. The problem is that RFC 3280 does not tell how to verify that 
> the CRL comes from the right CRL Issuer. Your assumption that the "two 
> paths needs to be verified in accordance with 3280 in order to 
> establish trust" is thus incorrect].
> 
> [SC: When you augment 3280 with the algorithm I proposed, that takes
> care of it.  It goes without saying that 3280 needs to be augmented 
> with the algorithm]

[SC: The DN of the trust anchor for the certificate certification path must
match with the DN of the trust anchors for the CRL certification path.  So,
I do not see what problem will occur]

[SC: That is what I have done]

> [SC: Go back to September 2003 archive of your response to my post and
> tell me what is not covered]
> 

Hum !!! Hum !!!

[SC: I am sure about it that you agreed to it.  You need to see the archive
to see what you wrote.  Separately, in this e-mail thread, I do not see any
specific error or flaw that you have pointed out.]

Denis

> I am sure you can find it from the archives.  It may be overcome by
> events since your recent postings show that you agree with me]
> 
> Denis

---

From: Tom Gindin <[email-masked]>
Date: Tue, 9 Nov 2004 07:45:43 -0500

Denis:

        Would a reasonable formulation of this rule be that a CRL Issuer 
certificate governing the certificates of a given CA must have been 
directly issued by one of the certificates in the chain being verified 
(including the CA's own certificate), by the trust anchor for that chain, 
or by a certificate which is a rollover of one of the certificates in the 
first two grouips?  For this purpose, a certificate is a rollover of its 
issuer certificate if it is self-issued but not self-signed, and the 
relationship is associative (i.e. if A is a rollover of B which is a 
rollover of C, A is a rollover of C as well as of B).  Thus, if a CA D has 
a CRL issuer and the path to D goes A (the anchor) to B to C to D, the CRL 
issuer certificate may be issued by A, B, C, or D, or by B' in the case 
where B is the issuer of B' and DN(B) = DN(B'); but it may not be issued 
through any other anchor nor through any CA whose DN is not in the path. 
Only one further liberalization of this rule might make sense, which is 
that C' would be considered a rollover of C on a path where C is issued by 
B if DN(C)=DN(C') and either C issued C' or B issued C'.  Who feels that 
this is safe?
        The good news about this heuristic is that it can be coded.  I 
think any of these variants resist Julien's attack, under the fairly 
reasonable assumptions that no CA issues certificates to bogus entities 
with its own name and that any CA which directly issued your 
cross-certificate and wants to have a CRL issuer masquerade as that CA can 
do so by issuing a bogus CA cert just as easily as by issuing a bogus CRL 
Issuer one.

                Tom Gindin

Denis Pinkas <[email-masked]>
Sent by: [email-masked]
11/05/2004 10:04 AM
 
        To:     Santosh Chokhani <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

> The matching algorithm is missing to say "who" trusts "somebody" for 
"what".
> [DP: the certification path needs to be verified according to RFC 3280. 
The
> [SC: When you augment 3280 with the algorithm I proposed, that takes 
care of

Let us talk about the key issue. The question is: how can a RP (relying 
party) know that, for a given end-user certificate, the CRL he got is 
indeed 
issued by the right CRL Issuer ?

I wonder if I understand correctly the model you proposed, but (please 
correct if wrong) you have a set of trust points to verify the 
certification 
chain, and another set of trust points to verify what you call a 
certification path for the CRL Issuer.

There would be many problems with such a model to define correctly 
validation policies, since the two chains would be unrelated and any CA 
from 
that chain could nominate CRL Issuers used by any CA.

> [SC: Go back to September 2003 archive of your response to my post and 
tell

Hum !!! Hum !!!

Denis

> I am sure you can find it from the archives.  It may be overcome by 
events

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Nov 2004 08:43:06 -0500

Tom,

How do you check the revocation status of a self-issued certificates?  If
the old key can be used to sign CRL, why not just issue CRL using the old as
well as new key and not worry about roll over certificate.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Tuesday, November 09, 2004 7:46 AM
To: Denis Pinkas
Cc: Santosh Chokhani; [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

        Denis:

                Tom Gindin

Santosh,

"what".
> order
to
> 3280.
The
care of

tell
> me what is not covered]
> 
> [DP: You would need to be more precise and provide me an extract of 
> what
you

Hum !!! Hum !!!

Denis

events

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 09 Nov 2004 15:17:58 +0100

Tom,

> first two grouips?  

No. This would not be a good formulation, since two different CAs from
the chain could choose the same DN to designate different CRL Issuers.

The RP needs to have an unambiguous way to know exactly which CA from
the chain is the one which has nominated the CRL Issuer.

Denis

> For this purpose, a certificate is a rollover of its 
>>[SC: The two paths needs to be verified in accordance with 3280 in order 
> 
> to
> 
>>establish trust]
>>
>>from the right CRL Issuer. Your assumption that the "two paths needs to 
> 
> be 
> 
>>[DP: You would need to be more precise and provide me an extract of what 
> 
> you
> 
>>refer to]
>>
>>[SC: It was short string of e-mails on the subject matter in September 
> 
> 2003.
> 
> Hum !!! Hum !!!

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Nov 2004 11:35:23 -0500

Denis.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Tuesday, November 09, 2004 9:18 AM
To: Tom Gindin
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Tom,

> or by a certificate which is a rollover of one of the certificates in the 

No. This would not be a good formulation, since two different CAs from the
chain could choose the same DN to designate different CRL Issuers.

[SC: For indirect CRL to work, it is a fair assumption that two CAs will not
share a name in the trust path nominated by the certificate issuing CA]

The RP needs to have an unambiguous way to know exactly which CA from the
chain is the one which has nominated the CRL Issuer.

[SC: I suspect you mean that the relying party needs to have an unambiguous
way to know exactly which authority was nominated as the indirect CRL Issuer
by the certificate issuer.  What you say does not make sense.]

Denis

---

From: Tom Gindin <[email-masked]>
Date: Tue, 9 Nov 2004 13:39:32 -0500

Denis:

        It is indeed possible for two CA's to choose the same CRL issuer 
DN, while meaning two distinct entities.  However, what are the 
consequences?  In one case, a CA which has certified a subordinate CA can 
"take over" the issuer ID of that subordinate (outside hierarchies, only 
RP's who are trusting the CA through the issuer of that cross-certificate 
are affected).  In the other, a CA which originally delegated revocation 
to its superior can reclaim it.  Which of these is an attack?
        I don't know why the RP needs a rule which declares "a CRL issuer 
must be certified by the CA whose certificates it is issuing a CRL for", 
and which prohibits subordinate CA's from having their hierarchical 
superior issue CRL's for them.  In replying to Santosh, you have discussed 
attacks which come from unrelated CA's as the primary security threat 
associated with CRL issuers.  I agree with that, and have blocked those.
        BTW, Santosh is right that a certificate issued to a CRL Issuer by 
a CA which ordinarily delegates CRL's to that issuer is not practically 
revocable by CRL.  However, IMO a certificate may be useful even if a 
revocation check on it is not feasible.  Much client software checks 
certificate chains without checking revocation, being satisfied with the 
certification that "this key pair was once possessed by the subject". This 
applies equally to self-issued certificates.
        Before declaring that a rule should (or should not) prevent the 
use of a superior CA's CRL Issuer to produce CRL's for a subordinate CA, 
we should probably find out if anybody actually does that.  I hope that 
nobody actually has sibling CA's producing their CRL's.

                Tom Gindin

11/09/2004 09:17 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     [email-masked]
        Subject:        Re: Briefing on CRL Path for IETF PKIX WG Meeting

Tom,

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Nov 2004 16:10:11 -0500

Tom,

Can you explain the following from your post in relation of CRL path
matching and how you mitigate it and CRL path matching does not.  I quote
you:

"In replying to Santosh, you have discussed attacks which come from
unrelated CA's as the primary security threat associated with CRL issuers.
I agree with that, and have blocked those."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Tuesday, November 09, 2004 1:40 PM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

        Denis:

                Tom Gindin

Tom,

Denis

---

From: Tom Gindin <[email-masked]>
Date: Tue, 9 Nov 2004 21:07:38 -0500

Santosh:

      I apologize for not having realized exactly how close the effects of
your algorithm and mine actually are.  I started from some of Denis'
formulations without having fully analyzed your initialization part 3, and
rederived something very close to yours.  In practice, the difference
between the matching algorithms mainly reduces to the difference between
"the subject and issuer DN's of the non-self-issued certificates must
match" and "must be the same certificate or a rollover thereof", and your
formulation allows a superior CA to rekey its subordinate without any
rollovers while mine forbids that.  Of course, I'm not really sure why the
issuer DN's need to be compared separately, since Issuer (N) must match
Subject (N-1) and the subjects are being compared.
      More substantively, I don't understand why it's permissible in your
algorithm for NCert to be NCRL-2 or NCRL-3, which corresponds to a
subordinate CA issuing its superior's CRL Issuer certificate.  In mine,
NCert may never be less than NCRL.  This difference does allow an attack
against yours which doesn't work against mine, but it is not an "unrelated
CA" attack.  Instead, it's a case of a subordinate CA of the EE's issuer
issuing a CRL Issuer certificate with the same DN (but a different key) as
that used in the EE certificate.
      In view of the minimal effective differences, it is probably
reasonable to consider my technique an optimization of yours in that it
doesn't need to perform independent path building.  You can easily enough
get rid of the difference cited in my second paragraph by replacing your
MIN step by "Verify that NCert >= NCRL", and using NCRL as the upper bound
of the loop.

            Tom Gindin

                      "Santosh                                                                                                         
                      Chokhani"                To:       <[email-masked]>                                                           
                      <chokhani@orionse        cc:                                                                                     
                      c.com>                   Subject:  RE: Briefing on CRL Path for IETF PKIX WG Meeting                             
                      Sent by:                                                                                                         
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      

                      11/09/2004 04:10                                                                                                 
                      PM                                                                                                               

Tom,

-----Original Message-----

        Denis:

                Tom Gindin

Tom,

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Nov 2004 22:22:34 -0500

Tom,

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Tuesday, November 09, 2004 9:08 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting

      Santosh:

      I apologize for not having realized exactly how close the effects of
your algorithm and mine actually are.  I started from some of Denis'
formulations without having fully analyzed your initialization part 3, and
rederived something very close to yours.  In practice, the difference
between the matching algorithms mainly reduces to the difference between
"the subject and issuer DN's of the non-self-issued certificates must match"
and "must be the same certificate or a rollover thereof", and your
formulation allows a superior CA to rekey its subordinate without any
rollovers while mine forbids that.

[SC: My algorithm permits roll over certificates.  I simply ignore them.  I
think a more secure and practical model is a CA getting a certificate from
parent when it re-keys.  There is no mechanism in X.509 that is both simple
and secure to promulgate revocation status of self-issued certificates.
Thus, it is important to account for a practice that is more secure.]

  Of course, I'm not really sure why the issuer DN's need to be compared
separately, since Issuer (N) must match Subject (N-1) and the subjects are
being compared.

[SC: Defense in depth.  I thought about comparing one sets of names only
since X.509 and 3280 requires name chaining during path validation.  But, I
also know that some well known and well used products do not do it.  I see
this an opportunity to reinforce the name chaining need.]

      More substantively, I don't understand why it's permissible in your
algorithm for NCert to be NCRL-2 or NCRL-3, which corresponds to a
subordinate CA issuing its superior's CRL Issuer certificate.  In mine,
NCert may never be less than NCRL.

[SC: If you note on slide 11, for direct CRL, Ncert = NCRL +1.  For indirect
CRL, we should add a rule that NCRL < NCERT (after NCRL has been decremented
by 1 in bullet 2.  I have added that.]

  This difference does allow an attack against yours which doesn't work
against mine, but it is not an "unrelated CA" attack.  Instead, it's a case
of a subordinate CA of the EE's issuer issuing a CRL Issuer certificate with
the same DN (but a different key) as that used in the EE certificate.
      In view of the minimal effective differences, it is probably
reasonable to consider my technique an optimization of yours in that it
doesn't need to perform independent path building.  You can easily enough
get rid of the difference cited in my second paragraph by replacing your MIN
step by "Verify that NCert >= NCRL", and using NCRL as the upper bound of
the loop.

            Tom Gindin

                      "Santosh

                      <chokhani@orionse        cc:

                      c.com>                   Subject:  RE: Briefing on CRL
Path for IETF PKIX WG Meeting                             
                      Sent by:

                      owner-ietf-pkix@m

                      ail.imc.org

                      11/09/2004 04:10

                      PM

Tom,

"In replying to Santosh, you have discussed attacks which come from
unrelated CA's as the primary security threat associated with CRL issuers. I
agree with that, and have blocked those."

-----Original Message-----

        Denis:

        It is indeed possible for two CA's to choose the same CRL issuer DN,
while meaning two distinct entities.  However, what are the consequences?
In one case, a CA which has certified a subordinate CA can "take over" the
issuer ID of that subordinate (outside hierarchies, only RP's who are
trusting the CA through the issuer of that cross-certificate are affected).
In the other, a CA which originally delegated revocation to its superior can
reclaim it.  Which of these is an attack?
        I don't know why the RP needs a rule which declares "a CRL issuer
must be certified by the CA whose certificates it is issuing a CRL for", and
which prohibits subordinate CA's from having their hierarchical superior
issue CRL's for them.  In replying to Santosh, you have discussed attacks
which come from unrelated CA's as the primary security threat associated
with CRL issuers.  I agree with that, and have blocked those.
        BTW, Santosh is right that a certificate issued to a CRL Issuer by a
CA which ordinarily delegates CRL's to that issuer is not practically
revocable by CRL.  However, IMO a certificate may be useful even if a
revocation check on it is not feasible.  Much client software checks
certificate chains without checking revocation, being satisfied with the
certification that "this key pair was once possessed by the subject". This
applies equally to self-issued certificates.
        Before declaring that a rule should (or should not) prevent the use
of a superior CA's CRL Issuer to produce CRL's for a subordinate CA, we
should probably find out if anybody actually does that.  I hope that nobody
actually has sibling CA's producing their CRL's.

                Tom Gindin

Tom,

Denis

> issuer certificate may be issued by A, B, C, or D, or by B' in the 
> case where B is the issuer of B' and DN(B) = DN(B'); but it may not be 
> issued

> Only one further liberalization of this rule might make sense, which 
> is that C' would be considered a rollover of C on a path where C is 
> issued
by

> reasonable assumptions that no CA issues certificates to bogus 
> entities with its own name and that any CA which directly issued your 

>>problem is that RFC 3280 does not tell how to verify that the CRL 
>>comes from the right CRL Issuer. Your assumption that the "two paths 
>>needs to
>
> be
>
> indeed issued by the right CRL Issuer ?
>
> certification chain, and another set of trust points to verify what 
> you call a certification path for the CRL Issuer.
>
> validation policies, since the two chains would be unrelated and any 
> CA from that chain could nominate CRL Issuers used by any CA.
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 10 Nov 2004 10:48:45 +0100

Santosh,

This was a response to Tom. It would be fair if you let Tom some time to 
respond to it.

See my two responses below.

> share a name in the trust path nominated by the certificate issuing CA]

[DP: there is no such "fair assumption"].

> by the certificate issuer.  

[DP: Your suspicion is incorrect. This is not what I said. Another way to 
express the same point would be:

"the relying party needs to have an unambiguous way to know exactly which CA 
has nominated the CRL Issuer, whose DN is present in the cRLIssuer field 
from the CRL DP extension".]

[SC: What you say does not make sense.]

See above.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Nov 2004 22:22:34 -0500

Tom,

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Tuesday, November 09, 2004 9:08 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting

      Santosh:

            Tom Gindin

                      "Santosh

                      <chokhani@orionse        cc:

                      owner-ietf-pkix@m

                      ail.imc.org

                      11/09/2004 04:10

                      PM

Tom,

-----Original Message-----

        Denis:

                Tom Gindin

Tom,

Denis

by

---

From: Tom Gindin <[email-masked]>
Date: Tue, 9 Nov 2004 13:39:32 -0500

Denis:

                Tom Gindin

Tom,

Denis

---

From: Tom Gindin <[email-masked]>
Date: Tue, 9 Nov 2004 21:07:38 -0500

Santosh:

            Tom Gindin

                      "Santosh                                                                                                         

                      11/09/2004 04:10                                                                                                 
                      PM                                                                                                               

Tom,

-----Original Message-----

        Denis:

                Tom Gindin

Tom,

Denis

> case

> is

>>comes

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 10 Nov 2004 10:48:45 +0100

Santosh,

See above.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Nov 2004 16:10:11 -0500

Tom,

-----Original Message-----

        Denis:

                Tom Gindin

Tom,

Denis