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

From: "Simonato Carolina" <[email-masked]>
Date: Tue, 04 Sep 2001 17:42:07 +0200

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

---

From: "Karim Ladhani" <[email-masked]>
Date: Tue, 4 Sep 2001 18:15:39 -0500

Carolina,

Typically in a PKI the Root CA has multiple key pairs and their key usages
are split up (certificate signing,CRL signing,etc). So in the event that the
certificate signing key is compromised, it would still be able to sign the
CRL since it would use a different pair of keys to do so.

Karim Ladhani

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Simonato Carolina
Sent: Tuesday, September 04, 2001 10:42 AM
To: IETF-PKIX
Subject: Question: who signs a CRL if the CAcertificate, that signs it,
is immediately revoked?

Hello all!

regards
Carolina

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 05 Sep 2001 10:16:46 +0200

Carolina,

> 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