## page was renamed from RootCertificateLost
The worst case scenario for a CA is the compromise of the root key.  This page develops our strategy for what we will do when (rather than if) the private key behind the root-certificate is compromised.

== How do we find out? ==

Plausibly, we find it on the Filesharing networks, ...

1. How can we detect a publication of the private key as soon as possible?
 *Run regular searches for the Hashsum of the file
 *Implement a Network-Intrusion detection, and add a filter, that can detect the transmission of the private key on the wire

1. OCSP requests for certificates we haven't issued

== What steps do we take? ==

What will we do when the key compromise is discovered?

 * Inform all Browser/Software vendors, to immediately revoke the key
 * Revoke the root certificate in the CRL and via OCSP
 * Issue a press release
 * Inform all the users
 * Trace-back the leak
 * Generate a new key and certificate
 * Ship the new certificate to the vendors  

== Questions to consider ==

 * How does a relying party check whether a certificate has been issued by the key after it was compromised, or before?
 * Does the relying party have to turn on CRL checking or OCSP?  What happens if they have no control over these features?  Embedded software or embedded certs?
 * Does a revocation over a root work?  Which software correctly handles this?
 * Is there a way to prepare a revocation in advance?  A warm replacement root?  Or is this a likely source of insecurity in and of itself?
 * What should be done if it is only ''suspected'' that the key is compromised?
 * Who decides to initiate the root compromise procedure?
 * Should members re-sign all their certificates with the new root?
 * In the event of dispute resolution, does a user who has been tricked by a compromised key-signed cert have a better claim?  Worse claim?