[SSL Observatory] Number of CAs

[Erwann Abalea]

Bonsoir,

Le 8 déc. 2011 22:08, "Daniel Kahn Gillmor" <dkg at fifthhorseman.net> a
écrit :
> On Thu, 8 Dec 2011 21:26:45 +0100, Erwann Abalea <eabalea at gmail.com>
wrote:
> > Strange. Asking with OpenSSL shows a path up to VeriSign (a 2048 bits
key).
> > Using Firefox or Safari shows a path up to DigiCert (a 2048 bits key).
I'm
> > in France.
>
> Try looking at the top DigiCert certificate in the chain in firefox or
> safari -- is it self-signed, or is it issued by Entrust.net?

Self-signed. Browser vendors don't accept intermediate certificate
inclusions, and show the whole validation path (up to the root
-self-signed-).

> Certificate chain
>  0 s:/C=US/ST=California/L=Palo Alto/O=Facebook, Inc./CN=www.facebook.com
>   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance
CA-3
>  1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance
CA-3
>   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance
EV Root CA
>  2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance
EV Root CA
>   i:/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits
liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server
Certification Authority

This is what is sent by the server. Maybe DigiCert was cross-signed by
Entrust to be able to be widely accepted while their own root cert is being
deployed? Entrust is an old entity, like Verisign, widely adopted, and they
use this fact to increase their business.

A recent browser would simply have the DigiCert root included, and won't
need the cross-signed one.

> > A root can't revoke itself. Trust has to come off-band, and is removed
> > off-band.
>
> This is news to me.  What are all these CRL Distribution point
> extensions doing in CA certificates then?  How should an application
> used by a relying party be notified if a Root CA is compromised?

The CRLDP is useless in a trust anchor (usually a self-signed root cert).
But it's used for intermediate certificates.
How is an application notified when a Root CA can be trusted? It's not.
Same for the compromission. If the root is compromised, how can you trust
the CRL?

> What should an application used by a relying party do if it fetches the
> CRL listed at the distribution point and finds a valid CRL containing
> the root certificate's serial number?

It should not. The validation algorithm is part of the standard, and
explicitely excluded trust anchor verification (it doesn't mean anything).

> Is there some reference that you could point me to that suggests that
> X.509's revocation infrastructure is insufficient for revoking root
> certificates?  What sorts of threat does this limitation mitigate?

Apart from the freely downloadable X.509?

> I understand that establishing root trust does need to come out-of-band
> at some point.  I don't understand why you shouldn't believe a trusted
> party if it tells you that its key is no longer reliable.

Some people disagree with this. But that's both standardized and logical.
Trust is not brought by the simple existence of the certificate. Whence, it
cannot be removed by something signed with the corresponding key.
An acceptable revocation reason might be "superseded", for example. But
"keyCompromise" is definitely not a good revocation reason. If the key is
really compromised, then everything signed by this key cannot be trusted.
Even the CRL.

-- 
Erwann.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/observatory/attachments/20111208/d137d98b/attachment.html>