On Mon, 16 Nov 2020 10:13:16 +1100 Matt Palmer via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > 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.
At least two CAs (and from what I can tell likely more) offer ACME APIs and thus ACME key compromise revocation (RFC 8555 section 7.6) The server MUST also consider a revocation request valid if it is signed with the private key corresponding to the public key in the certificate. I appreciate that this is less convenient to your preferred method of working, but it doesn't seem proprietary to agree on a standard way to do something and my impression was that you could talk to ACME now? > 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. OK, so in your opinion the way forward on #205 is for Mozilla policy to mandate acceptance of specific methods rather than allowing the CA to pick? Or at least, to require them to pick from a small set? > 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". But your earlier postings on this subject suggest that this is far from the whole story on what happens, not least because you sometimes weren't immediately able to figure out where to email that CSR to anyway or the responses, though not "we can't accept this" were... far from ideal. > 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. Experience with other elements of CA operations suggests that CAs don't like writing the other side of the code either, and so tend to coalesce on a smaller number of implementations especially when there's no opportunity to differentiate their product. > 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. Well, it is IETF 109 now so yes, this isn't the right moment for new drafts. My guess is that the closest match in terms of existing working groups is probably either LAMPS - but that is only really chartered to fix existing stuff, not explore new territory; or ACME - but ACME already solved the key compromise revocation problem as far as they're concerned. So, yes, individual submission is likely the way to go if you want this published. If expressions of interest are worth anything I can offer to read an Internet Draft and provide feedback but you might not like my feedback. For example the current text says: "Given a valid signature, the subjectPKInfo in the CSR MUST be compared against the subjectPublicKey info of the key(s) which are to be checked for compromise." But formats I've seen for keys (as opposed to certificates) do not contain a "subjectPublicKey info" and so I guess what you actually want to do here is compare the entire key. Explaining how to do that exactly while being neutral about how that key might be stored will be difficult, you might have to just pick a format. Also is RFC 7169 really the best available poison extension for this purpose? You understand it was intentionally published on April 1st right? Nick. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
