Subject: RE: CA Rekey and CRL Validation

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 13 Sep 2004 23:53:22 +0100

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)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 13 september 2004 16:37
> To: [email-masked]
> Subject: RE: CA Rekey and CRL Validation
> 
> 
> Denis:
> 
> In terms of Security Problem:
> 
> Let us say certificates 1-100 were issued by the CA using key1 and
CRL1
> contains their status with no IDP.
> 
> Let us say certificates 101-200 ere issued by the CA using key2 and
CRL2
> contains their status with no IDP.
> 
> Now when a relying party validates CRL1 or CRL2, it can build a path
to
> the
> CRL and think that it has a full CRL for the CA, but it does not.
More
> specifically, let us, it want to check the status of certificate 10.
It
> gets a CRL which happens to be CRL2.  It can build a path to CRL2
> signature
> key and validate it and will always get good status since CRL2 will
never
> contain certificate 10.
> 
> The way to solve the problem is as follows:
> 
> Put CRL DP = FIRST CRL in certificates 1-100
> Put CRL DP = SECOND CRL in certificates 101-200
> 
> Populate the IDP of CRL1 with DP = FIRST CRL
> Populate the IDP of CRL1 with DP = SECOND CRL
> 
> For further details on CRL processing, see Annex B of X.509, which is
> normative.
> 
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Monday, September 13, 2004 10:18 AM
> To: Santosh Chokhani
> Cc: [email-masked]
> Subject: Re: CA Rekey and CRL Validation
> 
> 
> Santosh,
> 
> I have some difficulties to understand what you believe is insecure
(since
> the two CRLs do not cover the same set of certificates); and then how
IDP
> would solve the issue. How would you use IDP (copied below ?) :
> 
>     issuingDistributionPoint ::= SEQUENCE {
>          distributionPoint          [0] DistributionPointName
OPTIONAL,
>          onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
>          onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
>          onlySomeReasons            [3] ReasonFlags OPTIONAL,
>          indirectCRL                [4] BOOLEAN DEFAULT FALSE,
>          onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
> 
> Denis
> 
> > Stefan,
> >
> > What is insecure is the following:
> >
> > 1 Rekey and no name changes; and
> > 2 Issuance of different CRLs covering the different sets of
> > certificates under the same Issuer DN without asserting IDP.
> >
> > What I have proposed here are some of the ways to close that
security
> > hole.
> >
> > -----Original Message-----
> > From: Stefan Santesson [mailto:[email-masked]]
> > Sent: Monday, September 13, 2004 9:05 AM
> > To: Santosh Chokhani; [email-masked]
> > Subject: RE: CA Rekey and CRL Validation
> >
> >
> > Santosh,
> >
> > This is not necessarily true.
> > The decision to do a name change or not is more dependent on the
> > combination of CA software, its configuration and cryptographic
> > library for clients.
> >
> > MS-CAPI is well capable of many usage scenarios where the CA is
> > re-keyed under the same name. E.g. MS-CAPI is does enforce IDP, CDP
> > match.
> >
> > /Stefan
> >
> >
> >>-----Original Message-----
> >>From: [email-masked]
> >
> > [mailto:[email-masked]]
> >
> >>On Behalf Of Santosh Chokhani
> >>Sent: den 11 september 2004 14:43
> >>To: [email-masked]
> >>Subject: RE: CA Rekey and CRL Validation
> >>
> >>
> >>If your relying parties plan to use MS CAPI, when you re-key a CA,
> >
> > change
> >
> >>its name.
> >>
> >>If you plan to use other toolkits, make sure that they build the
path
> >
> > to
> >
> >>CRL
> >>and match DNs one for one and in sequence (of the certification path
> >
> > to
> >
> >>the
> >>certificate and certification path to the CRL signer) ignoring
> >
> > self-issued
> >
> >>certificates, but including the DN of the two trust anchors for the
> >
> > two
> >
> >>paths.
> >>
> >>-----Original Message-----
> >>From: [email-masked]
> >
> > [mailto:[email-masked]]
> >
> >>On
> >>Behalf Of Luciano (Pessoal)
> >>Sent: Friday, September 10, 2004 4:30 PM
> >>To: [email-masked]
> >>Subject: CA Rekey and CRL Validation
> >>
> >>
> >>
> >>Hi All,
> >>
> >>	I have found the following sentence in a Microsoft's paper
> >>(Troubleshooting Certificate Status and Revocation) and I suppose
that
> >
> > it
> >
> >>is
> >>about the use of cRLIssuer on CRLs and certificates.
> >>
> >>"... Important: The Windows operating system family can only verify
a
> >
> > CRL
> >
> >>that was signed by the same private key used to sign the issued
> >>certificate. The Windows operating system does not support CRLs
signed
> >>by an entity other than the CA that signed the issued certificate.
> >>...."
> >>
> >>    My doubt is: What would happen  in the case of a CA Rekey?
> >>
> >>    I know by the item "5.1.1.3" from RFC 3280 that a CRL can be
> >
> > signed by
> >
> >>a
> >>different key used to sign certificates.
> >>
> >>    But, I'm not sure how does this topic fit in the case of CA
Rekey
> >>where a CRL is signed with the newer key and the certificates being
> >>verified
> >
> > was
> >
> >>signed with the older.
> >>
> >>    In the item "5.1.1.3" we have the text ".....Applications that
> >
> > perform
> >
> >>CRL checking MUST support certification path validation when
> >
> > certificates
> >
> >>and CRLs are digitally signed with the same CA private key.  These
> >>applications SHOULD support certification path validation when
> >>certificates and CRLs are digitally signed with different CA private
> >>keys."
> >>
> >>    I think Microsoft is ok considering the validation of
certificates
> >
> > and
> >
> >>CRLS signed with different CA private keys is an OPTIONAL feature
> >
> > (because
> >
> >>of SHOULD). Once, I ask you: What about CA Rekey?
> >>
> >>
> >>    Thanks in advance,
> >>
> >>    Luciano Coelho
> >>
> >>PS: I'm not concerned about this possible "limitation" on
Microsoft's
> >
> > CRL
> >
> >>validation process. I'm interested about how a CA REKEY can
interfere
> > with
> >>CRL check/validation.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 13 Sep 2004 23:36:00 -0400

Stefan:

The standard is very clear in this area.  A CA is defined by the name.
There is no requirement for a CA to use the same key to sign certificates
and CRL.  That is why we have a separate cRLSign bit.

Take a closer look at discussion of self-issued certificates and tell me
that a CA is not defined by name.

Also, read Annex B of X.509, which is normative.

Feel like those Watergate days when folks kept on asking where the smoking
gun is and we say the room is full of smoke.  It is written all over X.509
and 3280 that a CA is defined by name and can use different keys to sign
certificates and CRLs.

I would give you this much.  If I were to write the standard today, I would
use what MS uses or something similar (in order to provide strong and simple
crypto binding between the certificate signer and CRL signer).  But, to do
that today, we have to deal with the following:

1.  Backward compatibility issues; and
2.  Other vendors; and
3.  Change the standards

Without all those, we atheists say that the Earth Remains Round.  Feel free
to excommunicate us and declare the Earth flat.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Monday, September 13, 2004 6:53 PM
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.

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:

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.

Stefan Santesson

CRL1
CRL2
to
More
It
> signature key and validate it and will always get good status since 
> CRL2 will
never
(since
IDP
OPTIONAL,
security
path
that
a
signed
Rekey
certificates
Microsoft's
interfere