[gruez]

>The author goes on to explain that revocation of the affected certificates is insufficient, because they could be used to effectively reverse their own revocation at any point in the future. Instead, it must be proven that all copies of the keys have been destroyed. That’s quite an undertaking.

How would this be verified? Presumably the keys are stored on HSMs, but you can I'm not sure how you can prove that you didn't make a backup of the key.

[TrueDuality]

It is largely impossible to fully prove. CAs are supposed to keep detailed records of any issuing keys and what was called for was specifically "witnessed Key Destruction Reports" which involves third party independent confirmation of destruction of documented keys.

In the event that a key with a Key Destruction Report shows up again, the responsible party for that key will have shown unacceptable negligence and will potentially be subject to the exclusion of their keys as a valid certificate signer.

A lot of these companies core businesses rely on remaining in a position to sign certificates so it is in their best interest to protect that privilege by following the documentation requirements, and properly destroy their keys. It's effectively a pretty good stick.

[floatingatoll]

It’s impossible to prevent a truly dedicated malicious actor from doing so, but enforcement through both policy and independent auditors — and quality of response to security incidents — provide several layers of defenses against this scenario. (As with all things, a perfect defense is ultimately impossible, but they put in a lot of effort to get a lot of nines of certainty.)

[michaelt]

In principle, you would hope a CA would be able to precisely account for the number of backup copies of their private key.

In practice, of course, that doesn't mean every one of them will have done. There's 293 of them, after all.

[jchrisa]

The point is that you can't verify it. Sometimes HN humor is too dry for its own good.