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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of David Engberg Sent: Friday, September 10, 2004 11:23 PM To: Luciano (Pessoal) Cc: ietf-pkix@xxxxxxx Subject: Re: CA Rekey and CRL Validation 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. 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 > certificate. The Windows operating system does not support CRLs signed > by an entity other than the CA that signed the issued certificate. > ...." ... > 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?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature