Bonjour,
Le 24/09/2012 21:03, Jakob Bohm a écrit :
Does that work with any other serious X.509 validation toolkit?
It should.
When trying to build a valid certification path, all possibilities have
to be tested until one of them succeeds. If a CA gives a good signature,
but fails for whatever reason (a non respected constraint, a revoked
state, or an expired certificate), then the considered certificate chain
is invalid, and the next has to be tested.
To make this work (assuming the old root CA cert has not yet expired),
the validation code will need to actually verify the End Entity
certificate against both public keys, which effectively reduces the
algorithm security by allowing twice as many bit strings to be
accepted as valid.
An EE can be valid under different certificate chains, without reducing
the security of anything. Think about cross-certifications.
As for trust anchor update scenarios, I know of 3 different scenarios
that should be accepted by any good X.509 validation algorithm:
1. Changing expiry or other attributes while keeping the key.
Here the CA issues a new self-signed certificate with updated
attributes but unchanged key.
This needs a manual update of the trust store, as you're introducing a
new certificate object not linked to anything.
Following X509 rules, you can also change the key. Following RFC5280
ones, you can't (in fact, you can, but it won't be the root of the same
PKI).
2. Changing the CA key when the old key has *not* been compromised.
Here the CA generates a new key and issues two certificates for it:
A. A self-signed new root with a serial number or other variation
in one of the subject name components.
This is a change in the name of the CA, whence it's a completely
different CA.
B. A certificate for the new key and the same subject and (optional)
SubjectKeyIdentifier as A, but issued by the old root certificate
identity and key.
That's a self-issued certificate, it's OK until the old CA certificate
is not expired. Well described in X.509.
Manual update of the trust anchor is still necessary if you want the
validation to pass the expiration date of the old CA cert.
3. Setting up the CA to have keys for more than one algorithm (such
as RSA 1024 with SHA1 and RSA 4096 with SHA256). In this case, the
certificate validation could SHOULD (but might not) match issued end
entity certificates to the trust anchor by also comparing
signatureAlgorithm in the issued certificate against
subjectPublicKeyInfo.algorithm in the candidate issuer cert from the
store.
The issued certificate will have "sha1withRSA" or "sha256withRSA" in its
signatureAlgorithm, not "sha1withRSA1024" or "sha256withRSA4096".
A "SHA256" certificate (or however you call it) can still produce
"sha1withRSA" signatures. The other way is also possible, of course.
--
Erwann ABALEA
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
