On 31-07-2013 16:01, Walter H. wrote:
Eisenacher, Patrick wrote:
-----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.
not really; a CA that has to revoke one of their root cert. - these
are always self signed - uses a cert that comes from another root
cert., or this root cert itself to sign the CRL where it revokes the
compromised root cert;
As revoking the root indirectly revokes the child certs, and there
is a security requirement that no out-of-hierarchy revocations are
valid, it should not matter if the revocation is done by the root
or one of its children.
doing so has a total different quality: the CA can't remove their
compromised root cert from the trusted cert store of your system, but
with the CRL they can tell your system, not to trust any cert that was
signed by the compromised root cert;
Yes, and because they cannot know what certificates are falsely
issued by the compromised key, a root-compromise CRL must list
the root cert itself and need not list any other cert.
for signing a CRL there is no restriction about the content; but for
OCSP there exists a restriction: the cert used for signing the OCSP
responders must have been signed by the same CA cert as the certs itself;
Any correct implementation enforces a similar rule for CRLs, or
cross-revocation mayhem may ensue.
there exists a very strange situation when the CA cert has expired,
because there is no CA cert available that can sign the OCSP responder
certificate;
If any CA in the chain is expired, revoked, or otherwise untrusted,
there is no trust to check and no need for the OCSP responder to
remain active (beyond a short transition for clients with bad clocks).
the only cert that can't be checked by OCSP is the root cert itself;
This is where I disagree, can you point me to an actual reason why
not, which is not refuted by my logical ABC argument above.
you would do a good job that your CA cert signs only certs, that will
expire before the CA cert itself will expire ...
Validity beyond the issuer is null and void due to clients checking
all the expiry dates. Furthermore clients are allowed to reject
certificates with non-nested validity even during the period where
the validity overlaps. So on this point we agree.
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
