<p>Bonsoir,</p>
<p>Le 8 déc. 2011 22:08, "Daniel Kahn Gillmor" <<a href="mailto:dkg@fifthhorseman.net">dkg@fifthhorseman.net</a>> a écrit :<br>
> On Thu, 8 Dec 2011 21:26:45 +0100, Erwann Abalea <<a href="mailto:eabalea@gmail.com">eabalea@gmail.com</a>> wrote:<br>
> > Strange. Asking with OpenSSL shows a path up to VeriSign (a 2048 bits key).<br>
> > Using Firefox or Safari shows a path up to DigiCert (a 2048 bits key). I'm<br>
> > in France.<br>
><br>
> Try looking at the top DigiCert certificate in the chain in firefox or<br>
> safari -- is it self-signed, or is it issued by Entrust.net?</p>
<p>Self-signed. Browser vendors don't accept intermediate certificate inclusions, and show the whole validation path (up to the root -self-signed-).</p>
<p>> Certificate chain<br>
>  0 s:/C=US/ST=California/L=Palo Alto/O=Facebook, Inc./CN=<a href="http://www.facebook.com">www.facebook.com</a><br>
>   i:/C=US/O=DigiCert Inc/OU=<a href="http://www.digicert.com/CN=DigiCert">www.digicert.com/CN=DigiCert</a> High Assurance CA-3<br>
>  1 s:/C=US/O=DigiCert Inc/OU=<a href="http://www.digicert.com/CN=DigiCert">www.digicert.com/CN=DigiCert</a> High Assurance CA-3<br>
>   i:/C=US/O=DigiCert Inc/OU=<a href="http://www.digicert.com/CN=DigiCert">www.digicert.com/CN=DigiCert</a> High Assurance EV Root CA<br>
>  2 s:/C=US/O=DigiCert Inc/OU=<a href="http://www.digicert.com/CN=DigiCert">www.digicert.com/CN=DigiCert</a> High Assurance EV Root CA<br>
>   i:/C=US/O=Entrust.net/OU=<a href="http://www.entrust.net/CPS">www.entrust.net/CPS</a> incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority</p>
<p>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.</p>

<p>A recent browser would simply have the DigiCert root included, and won't need the cross-signed one.</p>
<p>> > A root can't revoke itself. Trust has to come off-band, and is removed<br>
> > off-band.<br>
><br>
> This is news to me.  What are all these CRL Distribution point<br>
> extensions doing in CA certificates then?  How should an application<br>
> used by a relying party be notified if a Root CA is compromised?</p>
<p>The CRLDP is useless in a trust anchor (usually a self-signed root cert). But it's used for intermediate certificates.<br>
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?</p>
<p>> What should an application used by a relying party do if it fetches the<br>
> CRL listed at the distribution point and finds a valid CRL containing<br>
> the root certificate's serial number?</p>
<p>It should not. The validation algorithm is part of the standard, and explicitely excluded trust anchor verification (it doesn't mean anything).</p>
<p>> Is there some reference that you could point me to that suggests that<br>
> X.509's revocation infrastructure is insufficient for revoking root<br>
> certificates?  What sorts of threat does this limitation mitigate?</p>
<p>Apart from the freely downloadable X.509?</p>
<p>> I understand that establishing root trust does need to come out-of-band<br>
> at some point.  I don't understand why you shouldn't believe a trusted<br>
> party if it tells you that its key is no longer reliable.</p>
<p>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.<br>

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.</p>

<p>-- <br>
Erwann.</p>