> From: [EMAIL PROTECTED] On Behalf Of Erwann ABALEA > Sent: Thursday, 31 January, 2008 13:08
> Hodie pr. Kal. Feb. MMVIII est, Patrick Patterson scripsit: > > I disagree with this idea, in principle, and what you are suggesting is CA > > rekey, and not renewal. > > > > Renewal is when you issue a new certificate, but keep the same keys. In this > > case, the CRL validation in OpenSSL works fine, since the keys are the same, > > and the only difference in the cert is a new validity and serial number. > > In the case where a CA rekeys (new Private key) (which is hopefully not that > > often - since in any sort of production environment, this requires a full key > > ceremony, auditors, etc.) > > It has been done it this way with SET for years, every single CA had > its private keys changed every year, and the corresponding > certificates also. Even the root. And yes, it required a full key > ceremony. IIRC SET used AuthorityKeyIdentifier extension in both (nonroot) certs and CRLs to identify the signer's verifying cert by Issuer+SN which is required unique. This works even during overlap while the CA-signer has multiple certs valid, or (as also noted) different (keypairs and) certs for certsign versus crlsign. I don't recall if AKI is present in their root certs, but it isn't needed, since a rootcert is signed by itself not any other (earlier or later) keypair for the root, and (of course) is trusted based on other information: the initially used root from out-of-band, and normal subsequent roots from a forward-chaining hash in another extension whose name I forget. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
