Proposed patch to check a CRL when a CA is renewed

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposed patch to check a CRL when a CA is renewed

Erwann ABALEA
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).
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.

--
Erwann ABALEA <[hidden email]>

openssl099-crl-renewedca.diff.gz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposed patch to check a CRL when a CA is renewed

Patrick Patterson-3
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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Re: Proposed patch to check a CRL when a CA is renewed

Erwann ABALEA
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 <[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Re: Proposed patch to check a CRL when a CA is renewed

Patrick Patterson-3
Hi Erwann;

On Thursday 31 January 2008 13:07:32 Erwann ABALEA wrote:

> > 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).
>

No, since this is a policy decision, the relevant document is RFC3647, which
makes a clear distinction between renewal and rekey.

<snip>

> > 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.
>

Please see this thread:

http://www.imc.org/ietf-pkix/old-archive-04/msg01204.html

Essentially, my take on what Santosh is saying is that CRLs need to be signed
by both CAs during the transition, because either a CA is "active" (and can
be used to validate the signature on the certificate itself) or it isn't. If
it is "active" it should sign it's own CRLs (and he doesn't preclude someone
else signing a CRL as well for that certificate, but if you do do this, then
the algorithm that he proposes in the thread should be followed, which
Stephan had a problem with, since there is a possible disambiguation problem
that could be exploited by a malicious attacker.).

The relevant quote is as follows: "Each of the two keys
should be used to sign the full CRL for the scope of all certificates issued
by that CA under all keys.  Furthermore, the same revoked certificate list
(empty or not) should be signed with all active keys.  Active keys are
defined as those CA private keys whose companion public keys can still be
used to verify signatures on the certificates"

So you can't just stop using a particular CA's keys... until it either expires
or is revoked, it should keep issuing CRL's for the keys it has issued. And
if it keeps issuing CRL's, the situation for which you have created the patch
should never happen :).

This is a rather murky subject, and the merits of the two approaches are
probably best discussed on the PKIX list, rather than here, as the approach
has little to do with the technical implementation of what you propose :)

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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Re: Proposed patch to check a CRL when a CA is renewed

Erwann ABALEA
Hi Patrick,

Hodie pr. Kal. Feb. MMVIII est, Patrick Patterson scripsit:

> Hi Erwann;
>
> On Thursday 31 January 2008 13:07:32 Erwann ABALEA wrote:
> > > 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).
>
> No, since this is a policy decision, the relevant document is RFC3647, which
> makes a clear distinction between renewal and rekey.

Ok. Again, an RFC, of type Informational. So my argument still stands,
the standards (and I include RFC3280 here even if it's not a standard,
but a common practice) don't differentiate the "rekey" vs "renew" of a
CA. And this has nothing to do with CRL validation.

> > > 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.
>
> Please see this thread:
>
> http://www.imc.org/ietf-pkix/old-archive-04/msg01204.html

I've read the whole thread, thanks.

> Essentially, my take on what Santosh is saying is that CRLs need to be signed
> by both CAs during the transition, because either a CA is "active" (and can
> be used to validate the signature on the certificate itself) or it isn't. If
> it is "active" it should sign it's own CRLs (and he doesn't preclude someone
> else signing a CRL as well for that certificate, but if you do do this, then
> the algorithm that he proposes in the thread should be followed, which
> Stephan had a problem with, since there is a possible disambiguation problem
> that could be exploited by a malicious attacker.).
>
> The relevant quote is as follows: "Each of the two keys
> should be used to sign the full CRL for the scope of all certificates issued
> by that CA under all keys.  Furthermore, the same revoked certificate list
> (empty or not) should be signed with all active keys.  Active keys are
> defined as those CA private keys whose companion public keys can still be
> used to verify signatures on the certificates"

What Santosh proposes here is biased, he wants to propose a solution
to allow even non-comformant relying parties to be able to handle this
specific case (re-key), with the MSCAPI example in head.

But on the same thread, he clearly describes what should be done in
the absence of IDP extensions, and the fact that a new CA key can sign
the whole CRL for the whole population (without requiring the old CA
key to do the same), etc.

I can only redirect you to annex B of the X.509 standard, which is
normative.

Anyway, right now, the solution proposed by Santosh doesn't work with
OpenSSL. OpenSSL refuses to load 2 CRLs with the same issuername in
the same store. Make your tests. And that's "normal", from my point of
view, if we don't consider the CRLDP+reason extension.
My proposed patch handles this case also (again, it doesn't check the
reason flag of the optional CRLDP extension).

> So you can't just stop using a particular CA's keys... until it either expires
> or is revoked, it should keep issuing CRL's for the keys it has issued. And
> if it keeps issuing CRL's, the situation for which you have created the patch
> should never happen :).

That point of view should obviously be changed after reading the rest
of Santosh's posts, and the X.509 standard.

> This is a rather murky subject, and the merits of the two approaches are
> probably best discussed on the PKIX list, rather than here, as the approach
> has little to do with the technical implementation of what you propose :)

I agree CRL validation *can* be really "chiant" (sorry, my english
vocabulary doesn't allow me to express those things). But without
cRLIssuer, or IDP, or any fancy extensions, it can be handled quite
easily.


Regards,

--
Erwann ABALEA <[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [openssl-dev] Re: Proposed patch to check a CRL when a CA isrenewed

Dave Thompson-4
In reply to this post by Erwann ABALEA
> From: [hidden email] 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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Re: Proposed patch to check a CRL when a CA isrenewed

Erwann ABALEA
Hi Dave,

Hodie Kal. Feb. MMVIII est, Dave Thompson scripsit:

> > From: [hidden email] 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 <[hidden email]>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]