Re: Question: who signs a CRL if the CAcertificate, that signs it, is immediately revoked?

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Carolina,

> Hello all!
> 
> Suppose a simple situation in which a certificate chain is constituted
> only by two certificates: a trusted (by some important authority) root
> certificate (self-signed) and an end-entity certificate, signed by that
> root certificate.

> The same root certificate also signs the certificate revocation list (a
> unique crl that contains all revoked certificates- for all reasons).

> The problem is: who signs the crl when the root certificate is
> immediately revoked, because of, for example, cacompromise?

If the key is the CA is compromised, then the attacker has the key and thus
may generate any CRL. The CA might still attempt to publish a CRL using the 
compromised key, but with no garantee that the CRL he has issued will ever
be seen (PKIX or X.509 does NOT assume that access to the repository where
the CRLs are placed is secured).

Nevetheless, all relying parties making use of the root key *shall* be
informed that the current root key is no longer valid. With your
assumptions, unless using some out-of-bands mechanism, it cannot be
guaranteed that they will always be informed (see later for a proposal). 

Once they know it, they should be able to obtain the new root key (which,
anyway has to be changed) using out-of-bands means, e.g. by publishing the
hash of the new self-signed certificate or by pushing or pulling the new
self-signed certificate.
 
I believe that this answers to your question without changing any parameter
from the situation you describe. However, by using a more realistic but 
different model, with an additional level in the hierarchy, then there is a
different answer. The model involves: a root level, a CA level, an end-user
level. 

If relying parties can directly trust both the root level and the CA key
that has issued their certificate, then there is another alternative: an
indirect CRL issued by that CA can be used to signal that the root CA has
been compromised. In this way the software can *always* receive a warning
that the root key has been compromised. 

Of course the attacker could say that the CA key is no longer valid (i.e.
revoked), by issued a (root) CRL but the warning is always obtained. After
getting such a warning, relying parties should be stop processing and
further inquiries should anyway be necessary to know what really happened
... to finally get the new root key and the possibly new CA key using some
out-of-bands mechanisms.

As a summary, using two trust points, instead of one, and indirect CRLs
is one way to solve the problem.

Denis


> Probably it is necessary to create a new couple of keys (and so a new
> root certificate) and sign the crl with the new  ca private key?

> Or is it possible to create a couple of  CA keys to sign only
> certificate revocation list and not to make provision for revoking this
> last  ca root certificate?
> 
> I would like to riceive suggestions about this topic.
> Thank you in advance.
> 
> regards
> Carolina