> You need cutoff date and some kind of public trail log to prevent backdating new certificates. You might be able to do it without a public log by using an RF

> You need cutoff date and some kind of public trail log to prevent backdating new certificates. You might be able to do it without a public log by using an RFC 3161 (TSP) secure timestamp facility like the unfortunately named https://www.freetsa.org/ https://www.freetsa.org/. Basically, we want to trust identity attestations ("I am Bill Clinton and this is my face") made by a compromised CA between the time the CA certificate was created and an estimate (hopefully a conservative one) of the date of compromise. We want to distrust any certificates signed outside this time range. This way, in the event of a CA compromise, we don't have to revoke everyone's certificate after a CA compromise. I think we can implement this security model by having the CA ask the TSP server to countersign each certificate that the CA issues. The TSP would sign a hash of the whole CSR, including both identity ("I am Bill Clinton") and biometric (bill-clinton.jpg) information. Anyone can use the TSP's attestation to provide that the TSP server witnessed this combination of inputs at a specific time. Sure, if you've compromised the CA, you can issue a certificate saying "I am Bill Clinton", but to do so, you need to either use a genuine, up-to-date TSP attestation, giving away the game, or you need to use an old TSP attestation, forcing you to use exactly the original inputs to the TSP. Using the exact inputs wouldn't help you: you want to issue a certificate saying "I am Bill Clinton" with attacker.jpg as the face, not bill-clinton.jpg. The latter won't help you do anything: you don't look like Bill Clinton and you don't have his private key. An attacker would have to compromise both the CA and the TSP server to pull off a passport forgery. And you can make this process even harder by requiring multiple independent TSP servers to countersign certificates.