> -----Original Message-----
> From: Jakob Bohm
> 
> On 31-07-2013 11:02, Eisenacher, Patrick wrote:
> >> -----Original Message-----
> >> From: Jakob Bohm
> >>
> >> On 30-07-2013 20:53, Walter H. wrote:
> >>> On 30.07.2013 19:51, Eisenacher, Patrick wrote:
> > Jakob, I don't understand your reasoning here.
> >
> > You can't trust a signature of a compromised key. So if the root-ca's 
> > private
> key gets compromised, you can't trust any of its issued crls and certificates
> anymore.
> This is where your and OpenSSL's logic fails:
> 
> If you receive a signed message from a CA saying it cannot be trusted, you
> have 3 ways to react:
> 
> A) Just believe it and revoke the CA.
> 
> B) Assume it cannot have been legitimately generated and must thus have
>    been created by means of a compromised key, thus concluding that the CA
>    can no longer be trusted.
> 
> C) Ignore it and proceed as if you have not seen it, which is very, very
>    stupid.
> 
> Because A and B have the same effect and require the same code, they are
> equally good.
> 
> C is just plain crazy.
> >   As such, pre-generating a crl for the case the root-ca doesn't have access
> to its private key anymore doesn't seem to make sense. The root-ca's only
> choice here is communicating this fact out of band to its customers, so they
> can remove the compromised root-ca certificate from their truststores,
> which is exactly what is happening today. The browser vendors even put it
> on an internal blacklist, so re-adding it to the truststore won't have any
> effect. I can't see where openssl is broken in this regard.
> All the recent out of band root revocations have involved revocation
> against the will of a no longer trustworthy CA.  So the CA was not
> communicating "remove our root", and the trust store distributors had to
> act out of band and take countermeasures in case the bad CA persisted in
> socially engineering people to add them back in local trust stores.
> 
> My complaint is about situations where CA officials willingly revoke one
> of their roots.

As I said before, there's no pki-inherent mechanism to revoke a self signed 
certificate other than to remove it from your truststore. This is the inverse 
step to giving the certificate trust by adding it to the truststore earlier.

The root-ca needs to communicate this fact out of band to its customers, 
whether it wants to willingly withdraw the certificate or whether it was hacked 
and is forced to withdraw it doesn't matter here. This communication can be via 
phone call/snail mail/website announcement/signed mail by a still trusted 
certificate, i.e. belonging to a different pki/unsigned mail/whatever is stated 
in the ca's cps. Alternatively, the media can jump in and spread the news. In 
any case, such a situation always involves action on your side to adjust your 
trust settings, as there is no pki-automatism that can help you.


Patrick Eisenacher

Reply via email to