On Sun, Nov 15, 2020 at 04:52:38AM +0000, Nick Lamb via dev-security-policy wrote: > This makes clear that the CA must have at least one of these "clearly > specified" accepted methods which ought to actually help Matt get some > traction.
I doubt it. So far, every CA that's decided to come up with their own method of proving key compromise has produced something entirely proprietary to themselves. I have no reason to believe that, absent method stipulation from a trust store, that we won't end up with different, mutually-incompatible, unworkable methods for demonstrating key compromise equal to (or, just as likely, exceeding) the number of participating CA organisations. Of course, the current way in which key compromise evidence is fracturing into teeny-tiny incompatible shards is, for my purposes, a significant *regression* from the current state of the art. Currently, I can e-mail a (link to a) generic but obviously-not-for-a-certificate CSR containing and signed by the compromised key, and it gets revoked. No CA has yet to come back to me and say "we can't accept this as evidence of key compromise". This format allows the pre-generation of compromise attestations, so that I don't need to keep a couple of million (ayup, there's a lot of keys out there) private keys online-accessible 24x7 to generate a real-time compromise attestation in whatever hare-brained scheme the affected CA has come up with -- not to mention the entertainment value of writing code to generate the compromise attestations for each of those schemes. In an attempt to keep the madness under some sort of control, I've tried to codify my thoughts around best practices in a pre-draft RFC (https://github.com/pwnedkeys/key-compromise-attestation-rfc) but so far it doesn't look like anyone's interested in it, and every time I think "oh, I should probably just go and submit it as an Experiment through the IETF individual stream and see what happens" the datatracker's not accepting submissions. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
