Subject: CA Rekey and CRL Validation

From: "Luciano (Pessoal)" <[email-masked]>
Date: Fri, 10 Sep 2004 17:29:44 -0300

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: David Engberg <[email-masked]>
Date: Fri, 10 Sep 2004 23:22:55 -0400

I would bet that most certificate-enabled software will not properly 
discover or process a separate CRL-signing certificate.  Section 5.1.1.3 
specifically warns that this practice "imposes a burden on applications, 
and it might limit interoperability."

Interoperability is easiest if you treat a "rekey" as an issuance of a 
separate cross-trusted CA.  Continue to issue a CRL for the old certs 
using the old key until all old certs have expired.  Issue a separate 
CRL for new certs (with a new CRLdp) using the new key.  This generates 
two CRLs instead of one, but the total size is the basically the same.

This means, of course, that you have to keep the old key around for a 
little while until its old issued certs expire.

> by an entity other than the CA that signed the issued certificate. ...."
...

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 11 Sep 2004 08:42:55 -0400

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

    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: Sat, 11 Sep 2004 08:46:24 -0400

David Engberg:

I do not know if you meant it or not, but the CA name must change, else
the two sets of certificates and two CRLs must be issued using appropriate
CRL DP and IDP respectively.  Otherwise, you will break the security and
be not compliant with the standards.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Engberg
Sent: Friday, September 10, 2004 11:23 PM
To: Luciano (Pessoal)
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Luciano (Pessoal) wrote:
> "... Important: The Windows operating system family can only verify a
> CRL that was signed by the same private key used to sign the issued
...

---

From: David Engberg <[email-masked]>
Date: Sat, 11 Sep 2004 09:46:43 -0400

Right ... that's what I meant by "with a new CRLdp", but I should have 
spelled it out more explicitly.

One clarification from your other email:  if I use a different CRL DP in 
the new certs, I may keep the same CA subject name for the new CA 
certificate, correct?

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 11 Sep 2004 12:51:46 -0400

Dave:

You can keep the old CA name, if you do one of the following (there may be
other options also).

1.  Assert different CRL DP and put the matching IDP in the CRL of the two
sets of certificates; or

2.  Put all the certificates on the revoked list, but issue two CRLs, one
signed with the old key and the other one signed with the new key.  Both
CRLs will have the same and complete list of revoked certificates.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Engberg
Sent: Saturday, September 11, 2004 9:47 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh Chokhani wrote:
> David Engberg:
>
> I do not know if you meant it or not, but the CA name must change,
> else the two sets of certificates and two CRLs must be issued using
> appropriate CRL DP and IDP respectively.  Otherwise, you will break
> the security and be not compliant with the standards.
>
> discover or process a separate CRL-signing certificate.  Section
> 5.1.1.3 specifically warns that this practice "imposes a burden on
> applications, and it might limit interoperability."
>
> CRL for new certs (with a new CRLdp) using the new key.  This
> generates two CRLs instead of one, but the total size is the basically
> the same.
>

---

From: Julien Pierre <[email-masked]>
Date: Sat, 11 Sep 2004 19:29:27 -0700

Santosh,

>be not compliant with the standards.
What part of the standards would you exactly violate by using different 
keys for certs and CRLs ? I haven't seen anything that says this is 
disallowed.

It seems to me RFC3280 allows SubjectKeyId / AuthorityKeyID to be used 
with both certs and CRLs. Therefore the cert issuer does not have to be 
the CRL issuer. The issuer cert of the CRL can be a cert with the same 
subject as the issuer cert for the end entity certs, but with a 
different private key and key usage .
The NIST test suite checks that this is supported by the toolkit. 
Currently, Mozilla's NSS doesn't support this - the key is assumed to be 
the same -, but it is clearly a bug, which has been opened for a while 
and will eventually be fixed. If MS CAPI doesn't support this, then it 
is also broken in similar fashion.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 12 Sep 2004 07:54:39 -0400

Julien:

I have not said that you violate any standard if you do not use the same key
to sign the certificate and CRL.  It is MS CAPI that will not verify the
path.

Now, if you use different keys, you lose crypto binding.  Neither X.509 nor
3280 deal with how to close the security gap created by the lack of crypto
binding.  On two different occasions, I have carried out this discussion on
the PKIX.  The authors of 3280 seem to agree with my proposed solution of DN
matching in the two paths.

I have also drafted the text for X.509 (as US comment) to fix the problem.

Rest of your posting about SKID and AKID do not seem to be related to matter
at hand and are likely to be in error in terms of their intent and role in
certification and CRL path validation.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Pierre
Sent: Saturday, September 11, 2004 10:29 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: CA Rekey and CRL Validation

Santosh,

Santosh Chokhani wrote:

>the two sets of certificates and two CRLs must be issued using 
>appropriate CRL DP and IDP respectively.  Otherwise, you will break the 
>security and be not compliant with the standards.
>  
>

---

From: "Joel S. Kazin" <[email-masked]>
Date: Sun, 12 Sep 2004 18:54:02 -0400

Provided you have nested your certificate lifetimes properly, the 
last/longest lived certificate issued by the CA using the old signing key 
will reach its notAfter date before the signers key expires, you can have 
more than one CRLs being concurrently issued by the same CA.  Specifically, 
when re-keying, a Windows 2003 CAs that is not the root CA it will continue 
to issue CRLs and delta CRLs for the old key which has stopped signing 
certificates.  The new private key will sign certificates, CRLs, and delta 
CRLs.  Yes, the signers DN does not change only the signers certificate and 
keys. We have one client who has been pushing out two CRLs and two delta 
CRLs for over 7 months, alI signed by the same CA but with two different 
keys. They have at least 30,000 certificates outstanding.  By the way the 
Microsoft 2003 CA will not issue a certificate where the signers notAfter 
date is less than that of that of the certificate it signs. In other words 
if your CA's signing certificate expires in 6 months but you as for an 
end-entity certificate expiring in two years you get an end entity 
certificate that expires in 6 months.

>is also broken in similar fashion.

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 12 Sep 2004 20:34:05 -0400

And that is INSECURE unless both CRLs cover all the certificates issued by
the CA or the certificates and CRLs are properly qualified with CRL DP and
IDP respectively.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joel S. Kazin
Sent: Sunday, September 12, 2004 6:54 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: CA Rekey and CRL Validation

At 07:54 AM 9/12/2004 -0400, Santosh Chokhani wrote:

>Julien:
>
>I have not said that you violate any standard if you do not use the 
>same key to sign the certificate and CRL.  It is MS CAPI that will not 
>verify the path.
>
>Now, if you use different keys, you lose crypto binding.  Neither X.509 
>nor 3280 deal with how to close the security gap created by the lack of 
>crypto binding.  On two different occasions, I have carried out this 
>discussion on the PKIX.  The authors of 3280 seem to agree with my 
>proposed solution of DN matching in the two paths.
>
>Rest of your posting about SKID and AKID do not seem to be related to 
>matter at hand and are likely to be in error in terms of their intent 
>and role in certification and CRL path validation.
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Julien Pierre
>different private key and key usage . The NIST test suite checks that 
>this is supported by the toolkit. Currently, Mozilla's NSS doesn't 
>support this - the key is assumed to be the same -, but it is clearly a 
>bug, which has been opened for a while and will eventually be fixed. If 
>MS CAPI doesn't support this, then it is also broken in similar 
>fashion.