Subject: RE: CA Rekey and CRL Validation

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

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 09:33:40 -0400

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.

/Stefan

change
to
to
self-issued
two
it
CRL
> certificate. The Windows operating system does not support CRLs signed 
> by an entity other
signed by
> where a CRL is signed with the newer key and the certificates being 
> verified
was
perform
certificates
> certificates and CRLs are digitally signed with different CA private 
> keys."
> 
and
(because
CRL
with

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 13 Sep 2004 16:17:38 +0200

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

---

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

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,

Denis

> 2 Issuance of different CRLs covering the different sets of
> certificates under the same Issuer DN without asserting IDP.
> 
> 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
> 
> 
>>by an entity other than the CA that signed the issued certificate. 
>>...."
>>