3 ms·

> how do you revoke a certificate which was used to issue millions of ID cards/passports once it leaks? Does everybody suddenly not have a "valid" ID proof? Yo

> how do you revoke a certificate which was used to issue millions of ID cards/passports once it leaks? Does everybody suddenly not have a "valid" ID proof? You need cutoff date and some kind of public trail log to prevent backdating new certificates. This can be done via short-lived secondary certs derived from a root one, logged publicly

trilbyglens 2y ago
Sounds a lot like a blockchain
- gruez 2y ago
  It really isn't, aside from using public key cryptography. There isn't even a concept of a "block" (ie. a linked list where each node is cryptographically linked to a prior node).
- out_of_protocol 2y ago
  Blockchain can be the store of public data (dump public keys of intermediate certs into blockchain), but it's not necessary, public trail log is enough to call on backdated cert issuing
Muromec 2y ago
That's pretty much how it works now, except they are not logged publicly.
quotemstr 2y ago
> 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.

trilbyglens 2y ago

Sounds a lot like a blockchain

gruez 2y ago
It really isn't, aside from using public key cryptography. There isn't even a concept of a "block" (ie. a linked list where each node is cryptographically linked to a prior node).
out_of_protocol 2y ago
Blockchain can be the store of public data (dump public keys of intermediate certs into blockchain), but it's not necessary, public trail log is enough to call on backdated cert issuing

Muromec 2y ago

That's pretty much how it works now, except they are not logged publicly.

quotemstr 2y ago

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