On Mon, Nov 16, 2020 at 02:17:37AM +0000, Nick Lamb wrote: > 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
ACME isn't a CA's "own" method of proving key compromise, hence is not covered by the above sentence. > 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? Well, it's "less convenient" in the sense that I'd have to figure out how to securely provide online access to several million private keys, which I continue to believe is going to end up being a Really Really Bad Idea, especially when there's such a simple alternate solution (just storing appropriately-formed CSRs online). In any event, on the current evidence, CAs are *not* universally going with "just use ACME", so it's something of a moot point. > > 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? Yes. The BRs' "any other method" of domain control validation provides a useful historical analog for why I believe this is going to end in tears for everyone. > > 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. Yes, but those issues are not related to providing the evidence of compromise, and hence not relevant to this discussion. > 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. Bring it on. Preferably with suggestions for alternate language. > 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. An SPKI can be constructed from any other form of the key material, and (modulo the rather annoying compressed-vs-uncompressed issue with EC keys) produces the Right Result in every situation I'm aware of (otherwise DER's got some splainin' to do). > Also is RFC 7169 really the best available poison extension for this > purpose? You understand it was intentionally published on April 1st > right? Yes, I am aware of the date of publication of that RFC. What I'm not aware of is anything that says that RFCs published on April 1st are banned from being referenced elsewhere. It's a document that appears to suit the purpose to which it is being used, hence I used it. It seems somewhat wasteful of everyone's time to produce essentially the same document but with a different publication date. I'm also aware of the need for standards-track RFCs to not use Informational or Experimental RFCs as normative references; in the exceedingly unlikely event that my proposal were to end up on that track, 7169 would need to be re-issued as a standards-track document as well, but that bridge can be burned if we come to it. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
