Subject: RE: CA Rekey and CRL Validation

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 14 Sep 2004 12:09:29 +0100

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

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Manger, James H
> Sent: den 14 september 2004 06:36
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 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: "Santosh Chokhani" <[email-masked]>
Date: Tue, 14 Sep 2004 08:36:24 -0400

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.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, September 14, 2004 7:09 AM
To: Manger, James H; [email-masked]
Subject: RE: CA Rekey and CRL Validation

James,

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

crumbles
has
5, 10
(which
get
ambiguity
way
key-match
Issuer
CRL(new)
certificates
required