Subject: RE: CA Rekey and CRL Validation

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 16 Sep 2004 09:38:11 +0100

Yes I have noted that.

Still I think we can conclude then that there are no place in RFC 3280
or X.509 where this is explicitly stated.

That is not what I call "crystal clear"

In the revision of RFC 3280 I would suggest adding a section that deals
with the aspects of CA re-keying and how that explicitly affects the use
of the standard and what it takes to achieve that. E.g. what
certificates you need to cover in a "full" CRL, that a re-keyed CA
instance don't re-use certificate serial numbers from certificates
issued by previous CA instances etc.

CMP 4.4.1 tries to cover some of that ground but doesn't cover the
aspects above and is neither normative for X.509 or RFC 3280

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 19:03
> To: [email-masked]
> 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: "Santosh Chokhani" <[email-masked]>
Date: Thu, 16 Sep 2004 07:03:39 -0400

Stefan:

See responses in-line.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Thursday, September 16, 2004 4:38 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Yes I have noted that.

Still I think we can conclude then that there are no place in RFC 3280 or
X.509 where this is explicitly stated.

[In this mail thread, we first determined that a CA is defined by name only
and not be name+key.  We determined that both 3280 and X.509 are clear on
that.  If you want add this sentence explicitly, I do not have objections.]

[In this mail thread, we then determined that standards are clear in that
absence of IDP means a CRL is complete for the CA.] 

In the revision of RFC 3280 I would suggest adding a section that deals with
the aspects of CA re-keying and how that explicitly affects the use of the
standard and what it takes to achieve that. E.g. what certificates you need
to cover in a "full" CRL, that a re-keyed CA instance don't re-use
certificate serial numbers from certificates issued by previous CA instances
etc.

[If you are using the same name and then reusing the serial numbers when
rekeying, you have a bigger problem than just revocation checking.  I hope
no product is doing that.]

CMP 4.4.1 tries to cover some of that ground but doesn't cover the aspects
above and is neither normative for X.509 or RFC 3280

Stefan Santesson

CA
all
and
shall
reasons
since
that
Annex
deals
of
issuer

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 16 Sep 2004 14:25:19 +0200

Santosh,

See may response in-line with [Denis: ]

> that.  If you want add this sentence explicitly, I do not have objections.]

[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].

> absence of IDP means a CRL is complete for the CA.] 

[Denis : I have difficulties to agree with this. There is a situation where 
this is not the case. If the certificate includes a CRL DP extension with 
the field cRLIssuer present, then it means that the CRL present at the 
distributionPoint MUST be signed by that CRL Issuer. Then the relying party 
MUST find a certificate issued by the CA that has delivered that certificate 
which has the keyUsage bit 6 set (cRLSign) and which includes the name of 
this CRL issuer as the subject name. It MUST then verify that the CRL which 
has been found is indeed signed by the key included in that certificate.

DistributionPoint is copied below:

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

Absence of IDP does not necessarilly mean that it is a CRL is complete for 
the CA.

Going back to RFC 3280, RFC 3280 is not sufficiently explicit about the ways 
to find the right CRL, when the CRL issuer is different from the CA. More 
text would be needed to cover this aspect.

/Denis ]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 16 Sep 2004 09:26:13 -0400

Denis:

Please see responses with [Santosh:]

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, September 16, 2004 8:25 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> [In this mail thread, we first determined that a CA is defined by name 
> only and not be name+key.  We determined that both 3280 and X.509 are 
> clear on that.  If you want add this sentence explicitly, I do not 
> have objections.]

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

> [In this mail thread, we then determined that standards are clear in 
> that absence of IDP means a CRL is complete for the CA.]

[Santosh: We are talking about IDP in CRL and not CRL DP in certificate.
Please look at Carl Wallace posting pointing to a section in 3280 in this
thread and my posting pointing to Section B.5.1.1 of X.509]

[Santosh: We are not discussing how to find a CRL.  We are discussing how to
determine if the CRL you have is appropriate.]

/Denis ]

> In the revision of RFC 3280 I would suggest adding a section that 
> deals with the aspects of CA re-keying and how that explicitly affects 
> the use of the standard and what it takes to achieve that. E.g. what 
> [If you are using the same name and then reusing the serial numbers 
> when rekeying, you have a bigger problem than just revocation 
> checking.  I hope no product is doing that.]
>

---

From: "Laudon Williams" <[email-masked]>
Date: Thu, 16 Sep 2004 07:11:28 -0700

Inline...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Thursday, September 16, 2004 4:04 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

[LW] Actually, this was stated, but I'm not so sure everyone agrees to this
point. I think we can all agree that difference in opinion on this
fundamental can lead to significantly different interpretations of the
standards. I would say that something this critical to should be as explicit
as possible.

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 16 Sep 2004 11:28:49 -0400

> [Denis : I have difficulties to agree with this. There is a 
> situation where this is not the case. If the certificate 
> includes a CRL DP extension with the field cRLIssuer present, 
> then it means that the CRL present at the distributionPoint 
> MUST be signed by that CRL Issuer. Then the relying party 
> MUST find a certificate issued by the CA that has delivered 
> that certificate which has the keyUsage bit 6 set (cRLSign) 
> and which includes the name of this CRL issuer as the subject 
> name. It MUST then verify that the CRL which has been found 
> is indeed signed by the key included in that certificate.
> 
> Absence of IDP does not necessarilly mean that it is a CRL is 
> complete for the CA.
> 
> Going back to RFC 3280, RFC 3280 is not sufficiently explicit 
> about the ways to find the right CRL, when the CRL issuer is 
> different from the CA. More text would be needed to cover this aspect.
> 
> /Denis ]

You are correct that absence of IDP does not necessarily mean that it is a
CRL is complete for the CA.  It means more.  Absence of IDP means the CRL is
complete for all certificates issued by all CAs that identify the CRL issuer
in their public key certificates (including certificates issued by the CRL
issuer).  See X.509: "it is the responsibility of the CRL issuer to ensure
that the CRL is complete in that it contains all revocation entries...from
all authorities that identify this CRL issuer in their certificates."

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 16 Sep 2004 17:35:30 +0200

Carl,

(text deleted)

> in their public key certificates 

Correct, .. and CAs can used different CRL Issuers.

> (including certificates issued by the CRL issuer).  

This is incorrect: a CRL issuer cannot issue certificates.

Denis

> See X.509: "it is the responsibility of the CRL issuer to ensure

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 16 Sep 2004 11:42:06 -0400

> This is incorrect: a CRL issuer cannot issue certificates.

Why is that?  Given the limited use of the indirectCRL mechanism, most CRL
issuers issue certificates.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 16 Sep 2004 18:02:41 +0200

Carl,

> issuers issue certificates.

A CRL issuer only issues CRLs.
A CA issues certificates and may also issue CRLs and/or OCSP responses.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 16 Sep 2004 12:52:49 -0400

But, the point remains that the CRL is complete for the Issuing CA.

-----Original Message-----
From: Carl Wallace [mailto:[email-masked]] 
Sent: Thursday, September 16, 2004 12:49 PM
To: 'Denis Pinkas'; 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: CA Rekey and CRL Validation

> You are correct that absence of IDP does not necessarily mean that it 
> is a CRL is complete for the CA.  It means more.
> Absence of IDP means the CRL is complete for all certificates 
> issued by all CAs that identify the CRL issuer in their 
> public key certificates (including certificates issued by the 
> CRL issuer).  See X.509: "it is the responsibility of the CRL 
> issuer to ensure that the CRL is complete in that it contains 
> all revocation entries...from all authorities that identify 
> this CRL issuer in their certificates."  
 
Ack.  Without an IDP, the CRL can't be indirect.  I was still stuck in the
missing DP field mindset of a few days ago.  Kindly ignore my post:-)

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 16 Sep 2004 12:52:19 -0400

But, the point is the CRL is complete for the Issuing CA.

-----Original Message-----
From: Carl Wallace [mailto:[email-masked]] 
Sent: Thursday, September 16, 2004 12:49 PM
To: 'Denis Pinkas'; 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: CA Rekey and CRL Validation

> You are correct that absence of IDP does not necessarily mean
> that it is a CRL is complete for the CA.  It means more.

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 16 Sep 2004 12:49:24 -0400

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 16 Sep 2004 13:11:45 -0400

Denis:

In X.509, a CA when it issues a CRL is called CRL issuer.  Please look at
the text of all the extensions descriptions related to CRL issuance.

Thus, saying a CA is not a CRL Issuer is incorrect in general.

In addition, if we assumed your interpretation that a CRL Issuer does not
issue any certificates, the following sentence which began this debate will
be meaning less.

"If this field is absent, the CRL shall contain entries for all revoked
unexpired certificates issued by the CRL issuer."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Thursday, September 16, 2004 12:03 PM
To: Carl Wallace
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Carl,

> Why is that?  Given the limited use of the indirectCRL mechanism, most 
> CRL issuers issue certificates.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 17 Sep 2004 09:10:25 +0200

Santosh,

> Thus, saying a CA is not a CRL Issuer is incorrect in general.

I did not say this.

> unexpired certificates issued by the CRL issuer."

This sentence is not present in RFC 3280.

On page 59, we have the following sentence:

    If the distributionPoint field is absent, the CRL MUST contain
    entries for all revoked unexpired certificates *issued* by the CRL
    issuer, if any, within the scope of the CRL

This sentence is either ambiguous or incorrect: a CRL issuer does not 
*issue* certificates. On page 7, the definition of a CRL issuer is:
CRL issuer: an optional system to which a CA delegates the publication of 
certificate revocation lists.

Besides this "battle" around words, since I have not followed all the 
messages of this thread, a summary would be interresting to answer the two 
following questions:

1) under which circumstances would the distributionPoint field within the 
issuing distribution point structure really useful for ?

2) what kind of processing should a relying party make of it, when this 
field is present ?

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 17 Sep 2004 08:56:08 -0400

Denis:

See responses in-line in [].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Friday, September 17, 2004 3:10 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

> In X.509, a CA when it issues a CRL is called CRL issuer.  Please look 
> at the text of all the extensions descriptions related to CRL 
> issuance.

I did not say this.

> In addition, if we assumed your interpretation that a CRL Issuer does 
> not issue any certificates, the following sentence which began this 
> debate will be meaning less.
> 
> "If this field is absent, the CRL shall contain entries for all 
> revoked unexpired certificates issued by the CRL issuer."

This sentence is either ambiguous or incorrect: a CRL issuer does not 
*issue* certificates. On page 7, the definition of a CRL issuer is: CRL
issuer: an optional system to which a CA delegates the publication of 
certificate revocation lists.

[Santosh Says: This sentence says that when the DP field is absent the CRL
must cover all reason codes, all certificates type asserted or implied by
the absence of those fields in the IDP.  Thus, when the IDP is entirely
absent, it means that all reason codes and all certificates (EE and CA) are
covered.]

[Santosh Says: For details, please see X.509 Annex B.  An abridged version
of these is also in 3280 CRL processing section.  I have provided a very
brief overview of this to give the high-level approach]

[Santosh Says: The DP in IDP is useful when the CRL is split more or other
than reason code and certificate type.  This does not mean that the
compliant implementations can not assert it even when the CRL is complete
for the scope as specified by the presence and absence of onlySomeReasons
and entity type assertion fields in the IDP.] 

[Santosh Says: The relying party should match the DP in CRL DP with the DP
in DP.  See the X.509 Annex B for further detail on calculating the DP in
CRL DP]

Denis

> [mailto:[email-masked]] On Behalf Of Denis Pinkas

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 17 Sep 2004 10:05:15 -0400

Please read "DP in DP" as DP in CRL DP".  My apologies for the typo.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Friday, September 17, 2004 8:56 AM
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Denis:

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

Santosh,

I did not say this.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 23 Sep 2004 14:28:35 +0200

Santosh,

I have been away so I could not respond immediately.

(text deleted)

> in DP.  See the X.509 Annex B for further detail on calculating the DP in

[Denis] Hum !!! I guess you did not meant "should", but "SHALL", and also 
"IDP" instead of "DP". The correct sentence would then be:

"The relying party SHALL match the DP in CRL DP with the DP in IDP."

In RFC 3280 we currently have:

    If the distributionPoint field is present and contains a URI, the
    following semantics MUST be assumed: the object is a pointer to the
    most current CRL issued by this CRL issuer.  The URI schemes ftp,
    http, mailto [RFC1738] and ldap [RFC1778] are defined for this
    purpose.  The URI MUST be an absolute pathname, not a relative
    pathname, and MUST specify the host.

A note should be added:

    Note: For a given certificate that contains a cRLDistributionPoints
          extension with a distributionPoint field, in order to make
          sure that the right CRL is being accessed, a relying party
          SHALL match the distributionPoint field from the
          issuingDistributionPoint with the distributionPoint
          field from the cRLDistributionPoints extension.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 23 Sep 2004 09:10:03 -0400

Denis:

Your suggestion on the text to be added is incomplete and rather than adding
the text to the description of the extension, it is covered by the path
validation logic.  The following is an example of incompleteness:

When a DP is absent in the IDP, there us no need to match the DP from the
CRL DP.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, September 23, 2004 8:29 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

(text deleted)

> [Santosh Says: The relying party should match the DP in CRL DP with 
> the DP in DP.  See the X.509 Annex B for further detail on calculating 
> the DP in CRL DP]

A note should be added:

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 23 Sep 2004 09:49:29 -0400

Denis:

When I read this, "If distribution point field is present.." applies to DP
in CRL DP.  My comment is on the DP in IDP.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, September 23, 2004 9:42 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

> Denis:
> 
> Your suggestion on the text to be added is incomplete and rather than 
> adding the text to the description of the extension, it is covered by 
> the path validation logic.  The following is an example of 
> incompleteness:
> 
> When a DP is absent in the IDP, there us no need to match the DP from 
> the CRL DP.

If you read more carefully, you will see that this note is to be part of the

paragraph: If the distributionPoint field is present ...

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 23 Sep 2004 15:41:56 +0200

Santosh,

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 23 Sep 2004 11:19:33 -0400

I have no objection to adding this to the IDP Section.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, September 23, 2004 11:10 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

> Denis:
> 
> When I read this, "If distribution point field is present.." applies 
> to DP in CRL DP.  My comment is on the DP in IDP.

If you read even more carefully, you will see that this note is to be part 
of the paragraph: "If the distributionPoint field is present ..." that is 
part of section 5.2.5 (on page 59) which only relates to the IDP. If you 
still have problems, please be more specific.

Denis

>>>2) what kind of processing should a relying party make of it, when 
>>>this field is present ?
>>
>>
>>>the DP in DP.  See the X.509 Annex B for further detail on 
>>>calculating the DP in CRL DP]
>>
>>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 23 Sep 2004 17:09:49 +0200

Santosh,

Denis

>>>this