Comment by amluto

CT logs are supposed to be useful. They serve at least two major purposes: visibility and auditing. Assuming that a CA is remotely well behaved, a site owner can trust that, if a certificate has been issued, then it's in the CT log. An auditor can read a complete record of certificates issued by a CA and attempt to determine whether they all follow the rules. And a CA that issues certificates without logging them is quite likely to get caught. Some browsers won't even accept certificates that aren't logged. And anyone who sees a signed certificate that isn't in the log holds evidence that the CA is misbehaving.

Once the private key has been leaked, this is basically all pointless.

Can a site owner trust that a certificate in their name has been logged? Of course not! An attacker could be signing it on the fly.

Can an auditor read the complete record? The complete record is kind of meaningless if the private key is leaked. But the auditor already knows that the private key is leaked!

Will the CA get caught if they issue a cert that isn't in the log? Yes! In fact, all newly signed certs won't be in the log.

Will browsers that check for log inclusion be protected? Yes, because newly signed certs won't be in the log.

Will anyone who sees a signed cert that isn't in the log hold evidence of misbehavior? Yes!

One might argue that the actual change to the CT system that should be made is a way for a CT operator to insert a statement into the append-only log that they believe a signing key to be compromised and that they will therefore no longer accept certificates signed by that key.