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?