Subject: RE: CA Rekey and CRL Validation

From: "wcwang" <[email-masked]>
Date: Thu, 16 Sep 2004 09:23:19 +0800 (CST)

Basically, I agree that a CA should be identified by its DN and
there is no need to change its DN when it rekey. However, there
are security issues if the RP blindly trust the CRL issuer's DN.
See the following example.

Suppose EE1 is the target of which certificate is to be validated
by the RP.

CA2, CA2', and CA2'' are three CAs with the same DN but with
different keys.

CRL1, CRL2, and CRL3 and three CRLs, and the signature of each one
of them can be verified with the puiblic key of each CA (CA2, CA2',
and CA2'') respectively and their issuer name matched.

Suppose the RP discover the following cert path:

TA->CA1->CA2->EE1

and the RP want to check if EE1's certificate is revoked.

To check the status of EE1's certificate, the RP has to
construct a acceptable "CRL path" (I mean valid cert path + CRL).

The question is what kind of "CRL path" is acceptable?
What are the criteria for an acceptable "CRL path"?

Let's consider the following "CRL paths":

CRL Path 1: TA->CA1->CA2->CRL

CRL Path 2: TA->CA1->CA2'->CRL

CRL path 3: TA->CA1->CA2->CA2'->CRL

CRL Path 4: TA->CA3->CA4->CA2''->CRL

Obviously, CRL Path 1 is acceptable since the target certificate and
the CRL are issued by the same CA with the same key. However, in the
situation where CA2 perform a key rollover and no longer use its old
key to issue CRL. In such situation, it is not possible to construct
CRL Path 1, and therefore the RP needs to find another CRL path.
Suppose the RP find CRP path 2, CRL path 3, and CRL path 4. Are
all of them accptable?

I think CRL path 2 is acceptable under the condition where CA1 guarantees
that it have never and will never issue cross-certificate with the same
subject DN to two different CAs. Under such condition, the RP is safely
to assume the CA2' and CA2 are the same CA and CA2' is the one with the
new key. CRL path 2 represents the situation where a CA performed its rekey
and applied to it parent CA for a new cross-certificate.

I think CRL path 3 is also acceptable. CRL path 3 is the situation where
a CA performed its rekey and issued a self-issued certificate (key-rollover
certificate).

However, I think it is dangerous if the RP accpets CRL path 4. Since
CA2'' is not issued by CA1, and there is no way to guarantee the name
uniqueness, therefore CA2'' might simply be anothor CA which happened
to have the same DN. Even worse, CA2'' might be a fake CA, which is
intend to create fake CRLs to fool the RP.

My conclusion is that the criteria to accept a CRL path are:

1. The last non-self-issued CA-certificate in the CRL path and
   the last non-self-issued CA-certificate in the target cert path
   must be issued by the same CA. 

   (As you can see, the the last non-self-issued CA-certificate in
    CRL path 1, 2, and 3 are all issued by the same CA, CA1.)
2. The issuer CA of the last non-self-issued CA-certificate must
   guarantee (maybe in its CP or CPS) that it have never and will
   never issue cross-certificate with the same subject DN to two
   different CAs.

In addition, although I did not discuss the indirect-CRL above, I believe
that the same rule also apply to the indirect-CRL situation.

I think the X.509 standard and RFC 3280 (or other PKIX RFC) should
clarify the criteria for an acceptable "CRL path" and highlight the
security consideration behind.

Wen-Cheng Wang
Chunghwa Telecom

-----Original Message-----
From: Santosh Chokhani <[email-masked]>
To: [email-masked]
Date: Wed, 15 Sep 2004 13:03:11 -0400
Subject: RE: CA Rekey and CRL Validation

Stefan:

That knows lies in several posting here where we have concluded that a CA =
Issuer Name and a CA != Issuer Name + Key

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2004 12:56 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

Thanks.

I must conclude though that the term "crystal clear" has completely
different meaning in our vocabularies :-)

All this is clear IF you understand that "complete" means not only
certificate issued under one CA key, but all certificates issued under all
keys of that CA.

But where do you gain that knowledge?
THAT is what interests me.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 15 september 2004 17:24
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Stefan:
> 
> See Section B.5.1.1 Complete CRL and I quote it below:
> 
> "In order to determine that a CRL is a complete CRL for end-entity and 
> CA-certificates, for all reason codes of interest, the following shall
be
> true:
> -	Delta CRL indicator extension shall be absent; and
> -	Issuing distribution point extension may be present; and
> -	Issuing distribution point extension shall not contain
> distribution
> point field; and
> -	Issuing distribution point extension shall not contain
> onlyContainsUserCerts field set to TRUE; and
> -	Issuing distribution point extension shall not contain
> onlyContainsAuthorityCerts field set to TRUE; and
> -	Issuing distribution point extension shall not contain
> onlyContainsAttributeCerts field set to TRUE; and
> -	If the reasonCodes field is present in the issuing distribution
> point extension, the reasons code field shall include all the reasons
of
> interest to the application; and
> -	Issuing distribution point extension may or may not contain
> indirectCRL field (hence, this field need not be checked)."
> 
> 
> 
> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Wednesday, September 15, 2004 11:01 AM
> To: Santosh Chokhani; [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> > [Since I have been involved in crafting portions of X.509 and since
> Annex
> > B
> > that is normative makes this abundantly clear, I beg to differ that
it
> is
> > not clear enough or authors of the text did not have this in mind.
> Any
> > suggestion to make it clearer in X.509 are welcome.]
> 
> 
> Well, since I'm talking to the expert :-)
> 
> I would be very grateful if you could point me to the section in Annex
B
> that makes this "abundantly clear".
> 
> In fact, I would be even more grateful, to find the section that deals 
> with CA generation management where it is clearly stated what the 
> effect
are
> when
> re-keying a CA with a new key but the same name. E.g. that this is
still
> part of the same CA and that all language that mention the concept of
a CA
> or CRL issuer explicitly means all instances of that CA or CRL issuer
(for
> all generations of issuing keys).
> 
> All I have seen is text from which you can derive this truth. I have
NOT
> seen any text presented where this has been explicitly stated.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> 
>

---

From: "Yasir Khan" <[email-masked]>
Date: Thu, 16 Sep 2004 12:13:19 +0500

Hi,

I have been looking at IETF archives and found many threads discussing the Delta-CRLs. Also I saw David A. Cooper's paper "A More Efficient Use of Delta-CRLs"  and Russ, Tim and Cooper's "Strawman on Delta-CRLs"
After going through many threads and papers, still I couldn't find any final document/discussion describing the issuance/usage of Delta-CRLs. If a standard way has been concluded for issuance/usage of Delta-CRLs then please refer me to that information. Thanx

Reagrds,
Yasir

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 16 Sep 2004 07:17:47 -0400

Wen-Cheng:

The actual DN matching algorithm needs to be a bit more robust.  See the
prior e-mails in this thread.  We need to ensure that the names match at all
levels ignoring self-issued certificates in both paths.

Also, the last certificate in both paths is not relevant.

For indirect CRL, the way to accommodate the name matching is to terminate
the name comparison at n-1 where n(min n1, n2) and n1 and n2 are the two
paths.  This requires the assumption that a CA has nominated another CA for
indirect CRL issuer who is in its trust hierarchy (above or below).  That
seems to be a safe, practical assumption.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of wcwang
Sent: Wednesday, September 15, 2004 9:23 PM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Basically, I agree that a CA should be identified by its DN and there is no
need to change its DN when it rekey. However, there are security issues if
the RP blindly trust the CRL issuer's DN. See the following example.

Suppose EE1 is the target of which certificate is to be validated by the RP.

CA2, CA2', and CA2'' are three CAs with the same DN but with different keys.

CRL1, CRL2, and CRL3 and three CRLs, and the signature of each one of them
can be verified with the puiblic key of each CA (CA2, CA2', and CA2'')
respectively and their issuer name matched.

TA->CA1->CA2->EE1

To check the status of EE1's certificate, the RP has to construct a
acceptable "CRL path" (I mean valid cert path + CRL).

Obviously, CRL Path 1 is acceptable since the target certificate and the CRL
are issued by the same CA with the same key. However, in the situation where
CA2 perform a key rollover and no longer use its old key to issue CRL. In
such situation, it is not possible to construct CRL Path 1, and therefore
the RP needs to find another CRL path. Suppose the RP find CRP path 2, CRL
path 3, and CRL path 4. Are all of them accptable?

I think CRL path 2 is acceptable under the condition where CA1 guarantees
that it have never and will never issue cross-certificate with the same
subject DN to two different CAs. Under such condition, the RP is safely to
assume the CA2' and CA2 are the same CA and CA2' is the one with the new
key. CRL path 2 represents the situation where a CA performed its rekey and
applied to it parent CA for a new cross-certificate.

I think CRL path 3 is also acceptable. CRL path 3 is the situation where a
CA performed its rekey and issued a self-issued certificate (key-rollover
certificate).

However, I think it is dangerous if the RP accpets CRL path 4. Since CA2''
is not issued by CA1, and there is no way to guarantee the name uniqueness,
therefore CA2'' might simply be anothor CA which happened to have the same
DN. Even worse, CA2'' might be a fake CA, which is intend to create fake
CRLs to fool the RP.

   (As you can see, the the last non-self-issued CA-certificate in
    CRL path 1, 2, and 3 are all issued by the same CA, CA1.) 2. The issuer
CA of the last non-self-issued CA-certificate must
   guarantee (maybe in its CP or CPS) that it have never and will
   never issue cross-certificate with the same subject DN to two
   different CAs.

I think the X.509 standard and RFC 3280 (or other PKIX RFC) should clarify
the criteria for an acceptable "CRL path" and highlight the security
consideration behind.

Wen-Cheng Wang
Chunghwa Telecom

-----Original Message-----
From: Santosh Chokhani <[email-masked]>
To: [email-masked]
Date: Wed, 15 Sep 2004 13:03:11 -0400
Subject: RE: CA Rekey and CRL Validation

Stefan:

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2004 12:56 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

Thanks.

Stefan Santesson

be
of
it
B
are
still
a CA
(for
NOT

---

From: Russ Housley <[email-masked]>
Date: Thu, 16 Sep 2004 12:00:43 -0400

I think that it would be very good for David Cooper to lead an effort to
develop a document in this area.  I am not sure that he has
time.

Russ

At 03:13 AM 9/16/2004, Yasir Khan wrote:

Hi,

I have been looking at IETF
archives and found many threads discussing the Delta-CRLs. Also I saw
David A. Cooper's paper "A More Efficient Use of
Delta-CRLs"  and Russ, Tim and Cooper's
"Strawman
on
Delta-CRLs"

After going through many threads and papers, still I couldn't find any
final document/discussion describing the issuance/usage of Delta-CRLs. If
a standard way has been concluded for issuance/usage of Delta-CRLs then
please refer me to that information. Thanx

Reagrds,

Yasir