Subject: AW: CA Rekey and CRL Validation

From: [email-masked]
Date: Thu, 16 Sep 2004 15:22:44 +0200

Denis,

what do you mean with "a sequence of names" in case of a root CA?

What consequence will your remark have in case of a re-key of a CA? Is it
necessary to change the name or not?

In my understanding a CA has got a specific name, e. g. "Atos Origin
TrustCenter", and a coresponding DN, e. g. "C=DE, O= Atos Origin
TrustCenter". In my opinion it is no good idea of changing the name ervery
time I have a re-key.

Regards

Thomas Beckmann

> -----Ursprüngliche Nachricht-----
> Von: Denis Pinkas [mailto:[email-masked]]
> Gesendet: Donnerstag, 16. September 2004 14:25
> An: Santosh Chokhani
> Cc: [email-masked]
> Betreff: Re: CA Rekey and CRL Validation
> 
> 
> 
> Santosh,
> 
> See may response in-line with [Denis: ]
> 
> > 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.
> > 
> > That is not what I call "crystal clear"
> > 
> > [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.]
> 
> [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].
> 
> > [In this mail thread, we then determined that standards are 
> clear in that
> > 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 ]
> 
> > 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
> > 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: Denis Pinkas <[email-masked]>
Date: Thu, 16 Sep 2004 15:40:29 +0200

Thomas,

> what do you mean with "a sequence of names" in case of a root CA?

This is not what I wrote. I wrote: "a root key with a sequence of names".

The name "C=DE, O= Atos Origin TrustCenter" does not identify the ATos 
Origin Trust Center you are thinking of, unless you also provide all the 
upper CA names and the root key that has certified the first name of the 
certification chain.

> What consequence will your remark have in case of a re-key of a CA? 

 > Is it necessary to change the name or not?

Unless your question is rephrased to be more specific, I am not sure I 
understand your question, since it is out of context.

> TrustCenter". In my opinion it is no good idea of changing the name ervery

When there is a new key for a CA, it is not necessary to change the CA name. 
However, when a root key changes, the story is more complicated and the 
scenario is not explained at all from a relying party point of view in RFC 
3280. Several pages, based on different trust assumptions, would be 
necessary to explain it.

Denis.

---

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

Denis:

With the rules for certificate and CRL certification paths match, we are
trying to ensure that uniqueness of the CA name along the lines you
suggested.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, September 16, 2004 9:40 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: AW: CA Rekey and CRL Validation

Thomas,

> TrustCenter". In my opinion it is no good idea of changing the name 
> ervery time I have a re-key.

Denis.

---

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

Thomas:

I agree with you.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, September 16, 2004 9:23 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: AW: CA Rekey and CRL Validation

Denis,

Regards

Thomas Beckmann