Hi Dave, Hodie Kal. Feb. MMVIII est, Dave Thompson scripsit: > > 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.
Yes. I can't find where, but I think even the Root certificate has this AKI extension. And in the SET specifications (part 2), it is stated: "A CA may have more than one certificate, either for functionally different purposes, or as key updating occurs. This extension is used to identify which CA certificate shall be used to verify the certificate’s signature." Of course, one need to find the good issuer certificate to be able to check the signature. But different private keys associated to different certificates with the same subject name form the same CA. My point here was a reply to Patrick, saying that re-keying isn't done in a production world. When we operated an SET platform, we (Certplus, by then) managed one national brand, one geopolitical brand (Carte Bleue, which is VISA in France), and several banks (8) under MCI and VISA, delivering certificates for merchants, cardholders, and payment gateways. Every single year, a key ceremony was done to renew all these certificates, and generate the corresponding private keys. With role separation (CRLSign, CertSign, Encryption, MessageSigning), IIRC, that represented up to 80 certificates + private keys. And it was designed to be done that way. Even the Root. > 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. Yes. For example, a PCA (Payment Gateway CA) has a certsigning certificate valid for 2 years, with an associated private key valid for 1 year. It can deliver payment gateway certificates valid for up to 1 year, and be able to revoke these certificates anytime during their whole life. Here's an extract of the X.509 standard: "The certificate validity period is the time interval during which the CA warrants that it will maintain information about the status of the certificate, i.e. publish revocation data." Imagine now the PCA1 certificate (the CA is "PCA", and the generation is "1"). Its certificates are valid from 01/01/2000 to 01/01/2002, its private keys are valid from 01/01/2000 to 01/01/2001. It delivers a PG certificate on 12/31/2000, valid to 12/31/2001. This PCA1 can't revoke this PG certificate after 01/01/2001, because it won't be able to sign the CRL. But the PCA in itself (that includes all generations of this CA) has to maintain the status of this PG certificate. So PCA2 (whose certificates validity dates range from 01/01/2001 to 01/01/2003, and private keys from 01/01/2001 to 01/01/2002) can revoke it, since it's the same CA (CA=name). The solution presented by Santosh on the 2004 thread mentioned by Patrick doesn't work when privateKeyUsagePeriod extensions are used. > 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. "hashedRootKey" :) A pretty clever mechanism, in my opinion. The hash of the public key of the next generation Root was included as an extension. -- Erwann ABALEA <[EMAIL PROTECTED]> ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
