On 9/25/2012 11:11 AM, Erwann Abalea wrote:
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.
Read carefully, I said that if the only way to pick the right candidate
is to
validate the signature against 2 same-algorithm public keys, then the
security of the signature validation is reduced by up to log2(keycount)
bits.
Anything that can be filtered out without signature checking (such as
different algorithms, different key identifies, different key lengths etc.)
does not cause that problem. And is OK security wise, but may not
be implemented by all (otherwise compliant) X.509 implementations.
> 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.
Cross-certifications involve different distinguished names for signature
chain building, these can all be verified by building the trusted chain
before validating the signatures.
> 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).
Yes, but the trick is that it provides a transitional period (between
issuing
the new self-signed CA cert and expiry or other limits of the old cert
attributes kicking in) during which the issued certificates are fully valid
against either cert, thus allowing time to update multiple trust stores
across a network (small or world-wide).
> 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.
Yes, but it will still have a sufficiently close name to retain any
reputation
based human trust.
> 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.
Actually, this is a cross-certificate from the old CA to the new CA.
as you said, well described in the literature.
Some of the discussions on this thread seems to indicate that when both the
A and B certificate are available, OpenSSL sometimes may fail to stop when
it hits the new (A) CA in the trust store because it does not
distinguish between
its trust store and its collection of cached/preloaded intermediary
certificates
(unlike Windows, which has seperate stores for those two categories).
> 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".
I deliberately did not give the OID names for the combinations, just
descriptions,
that is why I wrote it as multiple space separated words.
A "SHA256" certificate (or however you call it) can still produce
"sha1withRSA" signatures. The other way is also possible, of course.
Yes, but it cannot be validated by an X.509 implementation which does not
support SHA256 because of a silly policy to never add "new" algorithms in
updates to older versions, even if thousands of library clients cannot be
easily updated to a new library version (this bad policy is in both the
OpenSSL project and Microsoft Windows).
I am constantly forced to maintain and use SHA-1 certificates and signatures
because of old clients that are too hard to upgrade because vendor policies
insist that end users cannot get SHA-256 support unless they upgrade to
new (unwanted) versions of everything else. Think of the regular posts on
this list from people asking if they can upgrade Apache to OpenSSL 1.0.1
without recompiling their existing Apache httpd binaries. Then think of all
the users who refuse to switch from Windows XP to Windows Vista/7/8
because they like the old OS better, and who then suffer from Microsoft
not adding SHA-256 to the crypto algorithms in the XP core. And then throw
in the knock on effect on anyone trying to communicate with everybody,
including those hapless victims of SHA-256 refusal.
P.S.
I am on the list, no need to cc me
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
