Re: OCSP and self signed

[Walter H.]

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; 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;

the only cert that can't be checked by OCSP is the root cert itself;



Greetings,
Walter

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; 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; you would do a good job that your CA cert signs only certs, that will expire before the CA cert itself will expire ...

smime.p7s
Description: S/MIME Cryptographic Signature