I forgot to tell that I did these tests with version 1.0.0e.
Le 17/10/2011 14:14, Erwann Abalea a écrit :
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)
Given CA1g1 and CRLg1 in the "CApath", I can validate U2 and U3, and
U1 is correctly declared revoked.
I now renew CA1, with a rekey. I now have a second generation of the
same CA (same name), lets call it CA1g2.
CA1g2 issues U4, U5, U6.
Given a "CApath" containing CA1g1, CA1g2, and CRLg1, I can still
validate U2 and U3, and check that U1 is revoked. However, I cannot
check U4 to U6, OpenSSL complains that it cannot find the CRL (I used
strace to check that it reads the CRL "xxx.r0", and tries to find
another one "xxx.r1").
If I generate a new CRL with CA1g2 (named CRLg2), and replace CRLg1
with CRLg2 in the "CApath", I cannot validate U1 to U3 (same result:
cannot find CRL), but I can validate U4 to U6.
It seems OpenSSL follows the RFC5280 rule added during the transition
from RFC3280 to RFC5280, which says "the trust anchor for the
certification path MUST be the same as the trust anchor used to
validate the target certificate" (6.3.3, f).
However, this constraint is only local to RFC5280, it didn't exist
before, and does not exist in X.509. Read paragraph 8.1.5 of the 2008
edition of X.509:
-----
If an authority uses the same key to sign certificates and CRLs, a
single self-issued certificate of category a) shall be
used. If an authority uses a different key to sign CRLs than that used
to sign certificates, the authority may choose to
issue two self-issued certificates of category a), one for each of the
keys. In this situation, certificate users would need
access to both self-issued certificates to establish separate trust
anchors for certificates and CRLs signed by that
authority.
-----
category a) is a self-signed certificate, issued "as a convenient way
of encoding the public key associated with the private key used to
sign the
certificate, so that it can be communicated to, and stored as trust
anchors by, its certificate using systems".
I looked at the test descriptions of the NIST's PKITS, the renewal of
the root is not taken into consideration, no help from them.
So, while the PKIX IETF point of view is now clearly: "you never renew
the whole hierarchy, you just create a new one in parallel, which can
eventually have the same name", it contradicts X.509 (a CA is a name).
Shouldn't OpenSSL give a way to follow X.509 rather that RFC5280? Have
I missed a specific option that does just that?
--
Erwann ABALEA
-----
DP> http://couic-couic.fr
le lien ne marche pas...
-+- W in: Guide du Neuneu d'Usenet - Je lui fais couic-couic -+-
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
