[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: CA Rekey and CRL Validation

To: Denis.Pinkas@xxxxxxxx, chokhani@xxxxxxxxxxxx
Subject: AW: CA Rekey and CRL Validation
From: thomas.beckmann@xxxxxxxxxxxxxx
Date: Thu, 16 Sep 2004 15:22:44 +0200
Cc: ietf-pkix@xxxxxxx
List-archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-id: <ietf-pkix.imc.org>
List-unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Sender: owner-ietf-pkix@xxxxxxxxxxxx
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:Denis.Pinkas@xxxxxxxx]
> Gesendet: Donnerstag, 16. September 2004 14:25
> An: Santosh Chokhani
> Cc: ietf-pkix@xxxxxxx
> Betreff: Re: CA Rekey and CRL Validation
> 
> 
> 
> Santosh,
> 
> See may response in-line with [Denis: ]
> 
> > Stefan:
> > 
> > See responses in-line.
> > 
> > -----Original Message-----
> > From: owner-ietf-pkix@xxxxxxxxxxxx 
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
> > Behalf Of Stefan Santesson
> > Sent: Thursday, September 16, 2004 4:38 AM
> > To: Santosh Chokhani; ietf-pkix@xxxxxxx
> > 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: owner-ietf-pkix@xxxxxxxxxxxx
> > 
> > [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> > 
> >>On Behalf Of Santosh Chokhani
> >>Sent: den 15 september 2004 19:03
> >>To: ietf-pkix@xxxxxxx
> >>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:stefans@xxxxxxxxxxxxx]
> >>Sent: Wednesday, September 15, 2004 12:56 PM
> >>To: Santosh Chokhani; ietf-pkix@xxxxxxx
> >>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: owner-ietf-pkix@xxxxxxxxxxxx
> >>
> >>[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> >>
> >>>On Behalf Of Santosh Chokhani
> >>>Sent: den 15 september 2004 17:24
> >>>To: ietf-pkix@xxxxxxx
> >>>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:stefans@xxxxxxxxxxxxx]
> >>>Sent: Wednesday, September 15, 2004 11:01 AM
> >>>To: Santosh Chokhani; ietf-pkix@xxxxxxx
> >>>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)
> >>>
> >>>
> >>>
> >>>
> >>
> > 
> > 
> > 
> 
>
Follow-Ups:
- RE: CA Rekey and CRL Validation
  - From: Santosh Chokhani
- Re: AW: CA Rekey and CRL Validation
  - From: Denis Pinkas
Prev by Date: Re: CA Rekey and CRL Validation
Next by Date: RE: CA Rekey and CRL Validation
Previous by thread: AW: CA Rekey and CRL Validation
Next by thread: Re: AW: CA Rekey and CRL Validation
Index(es):
- Date
- Thread