Le 25/09/2012 18:45, Jakob Bohm a écrit :
On 9/25/2012 6:12 PM, Erwann Abalea wrote:
Le 25/09/2012 14:16, Jakob Bohm a écrit :
> On 9/25/2012 11:11 AM, Erwann Abalea wrote:
[...]
Any signature algorithm works by dividing the universe of N bit strings
into those that are validsignatures for the object and those that are
not. For most algorithms the valid subset is exactly one of the 2**N
bit strings, for some ECC variants it is two of them, for DSA it is
2**(N/2) of them. [...]
I'll have to re-read this in a quiet environment, with my HAC kept
close. Thanks.
[...]
So there's one more possibility: the CA changes its key, keeps its name
(so it's the same CA), and issues 2 certificates. First one is a
self-signed one with its brand new key. Second one is a self-issued one,
signed by the previous key.
Both this case and the previous one are used by several countries for
CSCA certificates (for passports).
So you say they have an intermediary certificate where
Issuer DN==Subject DN,
but the Issuer keyis not the key in the cert itself. Very weird, unless
there are appropriate key identifiers in thecertificates.
That's right. And that's precisely a self-issued certificate, considered
differently on the validation algorithm. For example, such a certificate
doesn't count for the pathLen constraints.
{subject,authority}KeyIdentifier extensions are not mandatory.
Consider a root CA with a self-signed certificate, with only
digitalSignature set in its keyUsage extension. This CA can then
self-issue another certificate with the cRLSign bit set. That's
different from a CA with 2 self-signed certificates, each one for one
usage. The former is valid for RFC5280 while the latter isn't, both are
valid for X.509.
[hours later]
Another scenario has been used in real world: have the root certificate
contain the hash of the public key of the next root (etc), the subject
name doesn't change. That was used for SET (shortly, I admit), as all CA
certificates were renewed every year. Some kind of forward chaining.
> 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).
What I understand from the OP seems to be different from this paragraph.
I grabed the old 1996-2004 VeriSign C3 root certificate, and its renewed
version 1996-2028 (same key, same name). That's your scenario 1.
The Thawte CA certificate doesn't have any authorityKeyIdentifier
extension, and OpenSSL correctly tests each possible certificate,
filtered by their subject name, until the validation is OK.
I assume the Thawte certificate you mention is not the same as the
VeriSign certificate (they havebeen the same company for a long time
now).
The OP talked about www.google.com, I connected and got a 1024bits
intermediate Thawte certificate from 2004, signed by VeriSign C3.
--
Erwann ABALEA
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
