Hi Patrick,
Hodie pr. Kal. Feb. MMVIII est, Patrick Patterson scripsit:
> 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.
OK. Let's call it "rekey" if you want, that's not a problem. We're a PKI
operator, and we don't "renew" CAs, we only "rekey" them, then.
Such differenciation is found nowhere in the X.509 standard, or the
RFC3280 document (or its successor, still in draft).
> 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.
And even now, for a big customer we have in common (I won't give its
name here), such practice ("renew" of a CA certificate without
changing the private key) is strictly forbidden by its certification
policy.
The fact that it requires a full key ceremony is of no influence here,
as you also need to perform the key ceremony in the same conditions if
you "renew" a CA certificate.
> then your patch is applicable, but needs too be
> examined in light of the other issues around certificate rekey...
Sure, that's why this patch is only "proposed", not "imposed".
> 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's not possible. If it has the same name, then it's the same exact
CA. Period.
We're dealing here with CA certificates, with off-band verification to
perform trust, etc. So CA impersonification is not a problem here.
> 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.
In what I wrote, which word wasn't clear? That's what we do, we
generate a new CA certificate "at a time that is the same as the
validity period for currently issued certs before the current CA end
of lifes", and it "starts issuing certs then". Here, we just happen to
generate a new private key for this CA.
The problem here is between this exact moment and the end-of-life of
the previous CA cert, some end-user certificates exist, are still
valid, and must be checked against a CRL signed by a different key
(but the same CA).
> > 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.
No. Neither the RFC3280 (which is only an X.509 profile, and by no way
a standard), neither the X.509 impose you to place a cRLIssuer field
in the CRLDP extension, or even the CRLDP extension. Moreover, the
cRLIssuer field is of type GeneralNames, and its use is to allow a CA
to revoke a certificate issued by another CA. This field can't give
the validation system informations about which key to use to verify a
signature, that doesn't follow the principles of X.509 (a CA is a
name, and a CA can have several key pairs).
There's no "denial of service attack" here, in absence of any
cRLIssuer in the CRLDP, the validation system needs to fetch all the
CA certificates whose name matches the issuername of the considered
CRL, find the "good one" (i.e. check the optional key usage, validity
periods, etc), and check the signature. All the fetched certificates
have the same subject name in common, so are part of the same CA, and
even *constitute* the CA.
OpenSSL needs to be further enhanced to handle CRLDP and cRLIssuer
extension/field, but that's not what I proposed to handle here.
Right now, OpenSSL can't even check a CRL when the CA has 2 private
keys: one to sign certificates, and one to sign CRLs.
Regards,
--
Erwann ABALEA <[EMAIL PROTECTED]>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
