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

Reply via email to