Hi Erwann: On Thursday 31 January 2008 11:23:57 Erwann ABALEA wrote: > Hello, > > OpenSSL doesn't cleanly verify revocation status when a CA is renewed > (with a key change). Attached is a proposed patch to handle this case. > This patch has been done against the current CVS version (I mirror it > every night). > > For a description of the problem, please consider the following > situation: > * a CA (name it "CN=My Trusted CA" for example) is created, delivers > certificates, revokes some, and periodically generates CRLs > * this CA will expire in 1 year, so for service continuity (end-users > certificates have a 1-year validity period), it has to be renewed > * a new keypair is generated, a new certificate for this CA is > produced (we *MUST* keep the same name to make it be the same CA) > * this new CA certificate is deployed across the end-users base, and > now this new generation CA does the job: certificate generation, > revocation, CRL signing, etc), and the end-user certificates > previously revoked by the old generation CA will be present in the > CRL produced by this new generation CA > > So the only CRL to have is the new one (the old generation CA doesn't > sign anything anymore).
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.) then your patch is applicable, but needs too be examined in light of the other issues around certificate rekey... One has to be very carefull when dealing with another CA that has the same name but different keys, or else it would be possible for an attacker to impersonate a CA. That is why, most of the time, CA keys are long life - I normally see 20 years as usual lifetimes. In my experience key roll-over is usually managed by some form of overlap - where the new Issuance CA is brought up at a time that is the same as the validity period for currently issued certs before the current CA end of lifes, and starts issuing certs then, so that when the old CA finally goes out of validity, there are no "valid" certs left around to issue CRLs for. > OpenSSL can't verify old end-user certificates against the CRL, > because it checks the verification of the CRL against the public key > of the certificate that signed the end-user certificate. That's not > conformant to the X.509 standard. I definitely disagree with the last statement - according to RFC3280 (which is the relevant "X.509 standard" in this case, I believe) if you want to validate a CRL against a key other than that used to sign the certificate, you are supposed to use the cRLIssuer field of the cRLDistributionPoint in the certificate. Allowing any other form of validation of a CRL signature leaves you wide open to a denial of service attack. Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
