Subject: RE: CA Rekey and CRL Validation

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

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

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 14 september 2004 14:36
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> 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,
> 
> 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 14:58:11 -0400

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", 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.

/Stefan

CRL
> different key (i.e., different from the one used to sign the 
> certificate being validated).
> 
in
> which has the consequences you mention.
> 
solve
key.
without
> certificates issued by the CA.
> 
ought
it
to
on
place).
use
the
certificate
of
the
it