Le 17/10/2011 16:09, Jakob Bohm a écrit :
On 10/17/2011 3:47 PM, Erwann Abalea wrote:
Le 17/10/2011 14:34, Eisenacher, Patrick a écrit :
Hi Erwann,
-----Original Message-----
From: Erwann Abalea
Bonjour,
While testing Apache-trunk (which will become apache 2.3.15),
including
the patch to use OpenSSL CRL validation, I've come to
disagree with what
OpenSSL does.
My scheme is:
- CA1 is a root (trust anchor), which is now in its first
generation
(lets call it CA1g1)
- U1, U2, U3 are end-user certificates, issued by CA1
- U1 is revoked, and the CRL is published (lets call it CRLg1)
you can't revoke a root CA by the means of a CRL. This works only
out-of-band, i.e. you have to declare that the root CA in question
is revoked and spread the news to all your customers.
[OT note, please discuss in separate thread]
I have seen CAs that declare an additional CRL for potentially
revoking the
CA itself.
Yes, and that was supported by mod_ssl, even for non self-signed CAs,
before the switch to OpenSSL CRL mechanism. That's not standard, of course.
That CRL is initially empty, but might one day be replaced by
one that revokes the (self-)issued CA cert, thus invalidating itself. A
recipient of such a "suicide CRL" has two reasonable options: A) Accept
it and revoke its own trust in that CA. B) Declare a logic error thus
preventing use of that CA until the compromising entity issues a new
empty CRL.
I know that I can't revoke a root, and I didn't try to do that.
Maybe my phrasing wasn't clear enough?
The problem here is that you can't trust a CRL when its signature
key is compromised.
The X.509 2008 edition category b) concept that you cite is new to
me and according to my understanding of PKI this doesn't make sense,
because there is no trust relationship between any self signed keys,
so I can't trust that key 2 has any relationship to key 1, specially
not to issue its CRLs.
In fact, the same paragraph exists in the 2005 edition of X.509. This
paragraph was shorter in the 2000 edition.
The idea here is that a CA is a name, not a key. You have the same
principle for intermediate CAs, i.e. when you renew an intermediate
CA, the CRL produced by the new private key encloses all the
certificates: the ones generated before the renewal as long as the
ones generated after the renewal.
Just to clarify:
Does the "renewed" CA have the same public/private key but different
attributes/expiry or does it have different public/private key and
different
attributes/expiry? (I understand that they have the same distinguished
name).
As I said, I renewed and rekeyed it. So that's a new key pair, for the
same CA (same name), and of course different validity dates.
--
Erwann ABALEA
-----
apyrolacustre: pouvant attendre
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
