[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CA Rekey and CRL Validation


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.



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.

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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Julien Pierre
Sent: Saturday, September 11, 2004 10:29 PM
To: Santosh Chokhani
Cc: ietf-pkix@xxxxxxx
Subject: Re: CA Rekey and CRL Validation


Santosh,

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



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    joel.kazin@xxxxxxxxxxxxxx
www.atosorigin.com