Subject: RE: CA Rekey and CRL Validation

From: "Manger, James H" <[email-masked]>
Date: Tue, 14 Sep 2004 14:36:26 +1000

Same name, different key = SAME CA.

Without this, if a CA's private key is destroyed no CRLs can ever be issued again for the certs it has issued so that CA's whole PKI crumbles in an instant.
Without this, every CA needs to keep operating (issuing CRLs) after it has issued its last cert for the lifetime it was putting in certs (eg 2, 5, 10 years?).
Without this, every certifier wanting to periodically change keys (which is good practice) needs to run multiple CAs.

P.S. There are ways to ensure name uniqueness for CAs -- either concatenate issuer names from a trust anchor to the CA of interest to get that CA's "name", or just use the issuer field for that CA and rely on your configured trusted anchors to name CAs in a way that avoids ambiguity (which is, in fact, the primary reason for a PKI in the first place).

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Tuesday, 14 September 2004 8:53 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh,

I realize that the standard is not crystal clear on this issue and I
suggest that you either have the wrong interpretation, or at least use
an interpretation that ought to be wrong.

The core issue is whether two CAs having the same name but different
private issuing keys, are regarded as 1 CA or 2 separate CAs.

I suggest (and hope) that these are NOT defined anywhere as being the
same CA. This is also supported by the reality fact that there is no way
that you can ensure name uniqueness between CAs and therefore, key-match
should be a requirement.

From this perspective standards states the following:

X.509 Annex B states:

   If the cRLIssuer field is absent from the CRL distribution point
extension of the certificate, the CRL shall be signed by the same CA
that signed the certificate; and
   If the cRLIssuer field is present in the CRL distribution point
extension of the certificate, the CRL shall be signed by the CRL Issuer
identified in the CRL distribution point extension of the certificate
and the CRL shall contain the indirectCRL field in the issuing
distribution point extension.

RFC 3280 5.2.5 states:

   The CRL issuer MUST assert the indirectCRL boolean, if the scope of
   the CRL includes certificates issued by authorities other than the
   CRL issuer.  

So IF different signing keys means that CA(old) and CA(new) are
different CAs (despite identical names), then in order to allow CRL(new)
from CA(new) to be used to validate certificates from CA(old), then
CRL(new) need to contain an IDP with indirectCRL asserted, certificates
from CA(old) must also contain a CDP with cRLIssuer field.

I suggest therefore that a CRL without IDP with indirectCRL is required
to be signed with the same key that was used to sign the certificate
being validated.

If that is not clear by today's standard text, then I suggest that it
should.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 14 Sep 2004 20:13:03 +0100

I think this requires for some kind of response.

> And anyway, the solution Microsoft employees favor is to use IDP
> everytime the CRL is not signed with the same key as the CA.

Participation on this list is done by individuals contributing to
development of good public standards.

In doing so some of us share open facts and experiences from the
products we work with.
That is NOT intended as a public declaration of best practices.

And your conclusion is wrong. What I ask this group to consider is
whether validation of a CRL without IDP should require both name AND key
match.

Stefan Santesson

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Jean-Marc Desperrier
> Sent: den 14 september 2004 19:42
> To: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> Laudon Williams wrote:
> 
> >Who is not employed by Microsoft, no matter how much Steve wants to
make
> >this political :-)
> >
> >
> And anyway, the solution Microsoft employees favor is to use IDP
> everytime the CRL is not signed with the same key as the CA.
> 
> What you present us is what I would call the Verisign way of solving
the
> problem by avoiding it all fully ...
> 
> I agree it's the only method that would work with currently deployed
> software, but a perfectly clearly defined way to correctly rekey for a
> future generation of products would be useful. And does not have to be
> that complex ...

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 14 Sep 2004 15:30:33 -0400

Stefan:

There was a minor error in step 2. N1 should be reduced by 1 since the end
entity certificate does not play a role in name matching.  (Of course both
standard and X.509 already require that for direct CRL Issuer field in end
certificate = Issuer field in CRL)

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Tuesday, September 14, 2004 2:58 PM
To: [email-masked]'
Subject: RE: CA Rekey and CRL Validation

Stefan:

If the relying party has two CA's with the same name X, but really represent
different real entities, the relying party is going to have bigger problem
of disambiguation than correct CRL.

Similarly, if the relying party has two intermediate CAs named Y, under the
same certification path, you have bigger problem of disambiguation than
correct CRL.  Also, no CA I know will certify the two different CAs with the
same name.  That has to happen for this to occur.

So, I will assume that neither of these two is the case.

Then, the problem boils down of matching the certification path for the
certificate and the certification path for the CRL used to check the
revocation status of the certificate.

The following rules should be used to ensure that you have the CRL from the
appropriate CA:

1.  The DN of the root in both cases must match.

2.  Set I = 1.  N1 = number of certificates in the "certificate
certification path" - 1, ignoring self-issued certificates.  Set N2 = number
of certificates in the "CRL certification path", ignoring self-issued
certificates. 

3.  If I = N1 or I = N2 exit with success

4.  Verify that the issuer DN in certificate I in the "certificate
certification path" matches the issuer DN in certificate I in the "CRL
certification path", ignoring self-issued certificates.

5.  Verify that the subject DN in  certificate I in the "certificate
certification path" matches the subject DN in certificate I in the "CRL
certification path", ignoring self-issued certificates.

6.  I = I + 1.  Go to step 3

{BTW, this has been explored and explained on this mail list couple of
times)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, September 14, 2004 9:52 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

Santosh.

CA1 and CA1(bis) have the same name but different keys.

They are both valid in the RPs trust configuration.

Both CAs issue CRLs without IDP (which is RFC 3280 and X.509 compliant
practice).

Result: The RP can't determine what CRL and what CA belongs together
resulting in false acceptance of revoked certificates.

You can call it what you want. 
I call that a security vulnerability. 

/Stefan

> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 14:36
> To: [email-masked]
> Stefan:
> There is no security problem in building a certification path for the
CRL
> Issuer when the same CA issues the CRL, but signs the CRL using a 
> different key (i.e., different from the one used to sign the 
> certificate being validated).
> 
> You can build a path.  You do need to do name matching as I have said
in
> several previous postings.
> 
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, September 14, 2004 7:09 AM
> To: Manger, James H; [email-masked]
> James,
> I don't agree with your examples.
> 
> The "simple" structure that dominates deployment today is 1 CA = 1 key 
> which has the consequences you mention.
> 
> However, the stanards define also indirect CRLs which can be used to
solve
> all your issues below EVEN if you stick with the definition 1 CA = 1
key.
> 
> The issue at hand, previously stated to Santosh is whether a CRL
without
> IDP
> can be validated with another key than the one used to validate 
> certificates issued by the CA.
> 
> If that is allowed, then we have identified a security problem that
ought
> to
> be fixed.
> /Stefan
> > On Behalf Of Manger, James H
> > Sent: den 14 september 2004 06:36
> > To: [email-masked]
> > Without this, if a CA's private key is destroyed no CRLs can ever be 
> > issued again for the certs it has issued so that CA's whole PKI
> crumbles
> > in an instant.
> > Without this, every CA needs to keep operating (issuing CRLs) after
it
> has
> > issued its last cert for the lifetime it was putting in certs (eg 2,
> 5, 10
> > years?).
> > Without this, every certifier wanting to periodically change keys
> (which
> > is good practice) needs to run multiple CAs.
> >
> >
> >
> >
> > P.S. There are ways to ensure name uniqueness for CAs -- either 
> > concatenate issuer names from a trust anchor to the CA of interest
to
> get
> > that CA's "name", or just use the issuer field for that CA and rely
on
> > your configured trusted anchors to name CAs in a way that avoids
> ambiguity
> > (which is, in fact, the primary reason for a PKI in the first
place).

---

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

Santosh, Stefan,

following the diskussion a couple of days, my opinion is, that this is the
point of misunderstandings. That people have a different view of what a CA
is. Is it the technical entity that signs the certifictes, i. e. the key, or
is it the body that issues the certificates, i. e. the organisation (the
name)?
If we do not clearify what exactly we are talking about and what is written
in the standards it seems to me like comparing apples to pears.

Regards
Thomas Beckmann

> -----Ursprüngliche Nachricht-----
> Von: Santosh Chokhani [mailto:[email-masked]]
> Gesendet: Mittwoch, 15. September 2004 19:03
> An: [email-masked]
> Betreff: 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
> 
> Sent: Wednesday, September 15, 2004 12:56 PM
> 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
> > Sent: den 15 september 2004 17:24
> > To: [email-masked]
> > 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)."
> > 
> > 
> > 
> > Sent: Wednesday, September 15, 2004 11:01 AM
> > > [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

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 17 Sep 2004 11:19:33 +0100

You don't, those aspects are completely unrelated

Stefan Santesson

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: den 17 september 2004 09:48
> To: [email-masked]
> Subject: AW: CA Rekey and CRL Validation
> 
> 
> Hi all,
> 
> there is an other point I am wondering about: For what purpose do I need
> indierkt CRLs within the PEM valitity model (i. e. the validity of an
> entities certificate lies between the notBefore an notAfter limits of the
> issuing CAs certificate)?
> 
> Thomas
> 
> > Von: Denis Pinkas [mailto:[email-masked]]
> > Gesendet: Freitag, 17. September 2004 09:10
> > An: Santosh Chokhani
> > Cc: [email-masked]
> > Betreff: Re: CA Rekey and CRL Validation
> >
> >
> >
> > Santosh,
> >
> > > 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.
> >
> > 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 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
> >
> > [mailto:[email-masked]] On
> > > Behalf Of Denis Pinkas
> > > Sent: Thursday, September 16, 2004 12:03 PM
> > > To: Carl Wallace
> > > Cc: [email-masked]
> > > Carl,
> > >>>>(including certificates issued by the CRL issuer).
> > >>>
> > >>>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.
> > >
> > >
> > > A CRL issuer only issues CRLs.
> > > A CA issues certificates and may also issue CRLs and/or
> > OCSP responses.
> > >
> > > Denis
> > >
> > >
> > >
> > >
> >
> >

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 21 Sep 2004 14:54:41 +0100

Santosh,

Maybe we are not talking about the same problem then :-)

It certainly would have helped in the case discussed in Geneva this
spring but no need to dwell on this here.

The important thing is that the schema is OK.

Stefan Santesson 

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: den 21 september 2004 13:09
To: [email-masked]
Subject: RE: CA Rekey and CRL Validation

Stefan:

The circular problem discussed in last September X.509 meeting is not
related to this.  That one relates to pitfalls of self-issued
certificates.

But, in general, revocation status of a certificate (call is X) must not
be checked using a CRL issuing authority or OCSP Responder whose
certification path validation requires X in the path.

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
	Sent: Tuesday, September 21, 2004 4:49 AM
	To: David A. Cooper; [email-masked]
	Subject: RE: CA Rekey and CRL Validation

	David,

	Thanks for the summary.

	Some corrections in line:

	Stefan Santesson 

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of David A. Cooper
	Sent: den 20 september 2004 21:41
	To: [email-masked]
	Subject: Re: CA Rekey and CRL Validation

	All,
	
	I have been on vacation for the past couple of weeks and have
just finished reading through the messages in this thread.  So, I would
now like to comment on some of the issues that have been raised.
	
	First, as David Kemp noted, the text on page 7 is not a
definition of CRL issuer, it is simply describing one of the components
depicted in figure 1.  Paragraph 3 of section 5 (on page 48) clearly
states:
	
	   CRL issuers issue CRLs.  In general, the CRL issuer is the
CA.  CAs
	   publish CRLs to provide status information about the
certificates
	   they issued.  However, a CA may delegate this responsibility
to
	   another trusted authority.  Whenever the CRL issuer is not
the CA
	   that issued the certificates, the CRL is referred to as an
indirect
	   CRL.
	
	As to the main question on this thread, I believe that X.509 is
very clear that a CA is identified by name, not name+key.  Here are a
few quotes from X.509:

	1.   
	Section 7: "NOTE 1 - Although the CAs are unambiguously defined
by a distinguished name in the DIT, this does not imply that there is
any relationship between the  organization of the CAs and the DIT." [DC:
If same DN but different keys meant different CAs, then CAs would not be
unambiguously defined by a DN.]

	2.   Section 7: "issuer identifies the entity that has signed
and issued the certificate." [DC: note that this says that the issuer
field of the certificate identifies the entity, not issuer field in
combination with key]

	3.   Section 7: "Self-issued certificate - This is a certificate
where the issuer and the subject are the same CA. A CA might use
self-issued certificates, for example, during a key rollover operation
to provide trust from the old key to the new key." [DC:  If CA were
defined as name+key, then one would not say that a key rollover
certificate had the same CA as both issuer and subject.]

	One is also required to ensure that two different entities are
not assigned the same name:

	1.	Section 8.3.2.1 (subject alternative name extension):
"For every name form used in the GeneralName type, there shall be a name
registration system that ensures that any name used unambiguously
identifies one entity to both certificate issuer and certificate users."

	I realize that some will still argue that X.509 does not
explicitly state that same name = same CA even if it does imply that it
is the case.  However, if you are going to suggest that X.509 should be
interpreted based on the assumption that different keys means different
CAs, the question I would ask is where in X.509 (or RFC 3280) is there
anything that implies this is the case?

	[Stefan] I don't think anyone is suggesting this interpretation
of X.509. The issue was raised and resolved. There only remains a
suggestion that this should be more directly stated in the standards
(not only indirectly understood from the quotes above).

	Some have argued that X.509 has a security vulnerability unless
the assumption is made that different keys means different CAs.
However, these arguments always start with the assumption that one is
operating in a PKI in which there are multiple, independent CAs, all of
which are considered to be valid CAs in the infrastructure and all of
which have the same name.  However, in a valid PKI, two different CAs
will not have the same name.  So, these people are simply noting that if
one operates a PKI in a manner that is contrary to the rules of X.509
(allowing two different CAs to share the same name), the PKI will not
provide the security assurances promised by X.509.  But, I don't see how
one can argue that this indicates a flaw in X.509.

	[Stefan] This is not correct. The argument was based on the
wrong assumption that it was allowed to issue a CRL covering
certificates issued under just 1 CA key, without having IDP present in
the CRL. It was clarified however that this is not supported practice.

	Santosh has proposed a restricted path validation algorithm for
validating CRL signing keys (ensuring that the certification path for
the CRL signing keys is similar to the certification path for the
certificate being validated) that mitigates that damage that would
result from a PKI in which two CAs share the same name (i.e., it
provides an extra layer of protection). His proposal mitigates the
problem as well as if one required certificates and CRLs to be signed
with the same key.  The main reason I agree with Santosh's proposal,
however, is that I don't see any good reason not to impose the
restriction he proposes, while imposing the restriction makes path
validation more efficient since there are fewer possibilities that need
to be considered.

	[Stefan] I'm OK with this restrictions which also solves other
security issues discussed in ITU (Circular trust)

	Dave
	
	Stefan Santesson wrote:

	Denis,

		    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

	 
	I agree that the definition is not consistent with the standard
text in
	general. Other sections definitely suggest that the CA can be
the CRL
	issuer also without delegation.
	 
	From 4.2.1.14  CRL Distribution Points:
	 
	   If the certificate issuer is not the CRL
	   issuer, then the cRLIssuer field MUST be present and contain
the Name
	   of the CRL issuer.  If the certificate issuer is also the CRL
issuer,
	   then the cRLIssuer field MUST be omitted and the
distributionPoint
	   field MUST be present.