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:
In Boolean logic, we have the following possibilities:
- Root is trusted, so the revocation is valid, so the root is not
trusted. This is a contradiction so cannot hold.
- Root is not trusted, by elimination this must be true.
You have to communicate this fact out-of-band.
I never understood why some root-cas put a crldp extension into their
own certs.
this has sense in any cert except the root (self-signed) cert.
It makes sense for any non-broken client implementation.
Ideally, such roots keep an off-line copy of a pre-signed self-
revocation CRL, similar to the procedure used by experienced PGP
users (those who actually read the PGP 2.x manual). In case of
combined key compromise and loss, the off-line CRL is published,
thereby revoking the entire hierarchy.
The worst case disaster scenario is a large scale armed attack on the
center that keeps the private key. The attackers now have exclusive
control of the private key. But a far away trusted person can still
retrieve the self-destruction CRL and publish it through every means
imaginable, such as S/MIME e-mails (PEM style), sending it to software
update organisations (Microsoft, Mozilla, Apple, Google...) and for
all but one country, getting IANA/Internic assistance to force repoint
the DNS names of the CRL server to another server that serves up this
CRL and a message about the compromise.
The less worst case disaster scenario is an ordinary key compromise,
where the CA still has the private key and can sign a more precisely
dated revocation CRL and put the OCSP server in "all is revoked" mode.
Unfortunately, OpenSSL is broken and will apparently ignore all such
emergency messages.
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.
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
