Question re: Change in Revocations Methods

I wasn't referring to the manual aspect particularly though. I was referring to revocation from key-compromise reports in general. Other than to be annoying and waste resources, there's really not much motivation for intentional submission of false reports of key-compromise by bad actors (for keys they actually possess). On the other hand, I do believe there is great misconception (or maybe call it laziness of understanding) out there about what comprises a key-compromise, which results in unintentional submission of false reports of key-compromise by misinformed actors. Hence why I created and frequently reference this:

The current "burden of proof" does not prevent submission of false reports from either of those two classes of keyholder, but it does prevent submission of true reports from likely the most vulnerable class of keyholder (those who have lost possession of their keys). It's a tradeoff that halts the other class of keyholder (or should I say non-keyholder) who intentionally submits false reports of key-compromise (for keys they don't actually possess).

5 Likes