RE: CA Rekey and CRL Validation

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Joel S. Kazin
Sent: Sunday, September 12, 2004 6:54 PM
To: Santosh Chokhani; ietf-pkix@xxxxxxx
Subject: 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