I agree with Corey on this. I was disappointed that the LAMPS discussion two years ago was not as helpful as it could have been.
For what it's worth, while we generally try to accept any reasonable proof of key compromise, we have seen quite a large variety of things sent to us. This includes people actually sending us private keys in various forms, which is completely unnecessary and something we'd like to avoid. When we are unable to verify a proof, we provide explicit instructions on how to create a proof in a standardized form that's easy to very. I believe it currently involves signing something with openssl, so it should be easy to carry out for anyone who is involved in these sorts of discussions and has access to the private key. Standardized procedures (plural, I don't think a one size fits all solution would necessarily be good) would be very helpful for everyone, including mitigating the risk that some less sophisticated CAs accept proofs that are not valid, introducing a potential denial of service attack. The whole purpose of having minimum security requirements is to make sure important things like this are handled correctly, using procedures that have received appropriate scrutiny from individuals who understand the security implications. I also think it's potentially useful to discuss standardizing lists of known compromised keys, and how to check them before issuance. The problem of revoking them could be avoided entirely if they were never issued in the first place. BTW the same is currently true for proving domain control for the purposes of revocation ... existing practice for CAs is currently all over the map, and we've discussed it before without reaching a resolution. It would be useful if there were actual requirements for that, too. -Tim > -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Corey Bonnell via dev-security-policy > Sent: Monday, March 2, 2020 2:48 PM > To: Nick Lamb <n...@tlrmx.org>; Mozilla <mozilla-dev-security- > pol...@lists.mozilla.org> > Cc: Matt Palmer <mpal...@hezmatt.org> > Subject: RE: Acceptable forms of evidence for key compromise > > There was quite a bit of discussion on the development of a standard > revocation request format on LAMPS WG mailing list two years ago in the > wake of the Trustico mass revocation: > https://mailarchive.ietf.org/arch/msg/spasm/qeVHLeG6- > Q_47QKNdyOOxsAT3Zk/. > Nothing was developed in terms of a concrete proposal specifying a > revocation request format/protocol, but the pros/cons of such were hashed > out pretty thoroughly. > > I do think there's value in developing some standard mechanism to request > revocation/demonstrate possession of the private key. The use of such a > mechanism would reduce the burden of work for those reporting key > compromises, as the reporter would not need to learn how to demonstrate > possession the private key 15 different ways to 15 different CAs. And CAs > would benefit from such a mechanism, as they wouldn't need to spend > support cycles working with the reporter to arrive at a suitable means to > demonstrate possession or have to learn some exoteric software tooling > that the reporter is using to prove possession. > > Thanks, > Corey > > -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > On > Behalf Of Nick Lamb via dev-security-policy > Sent: Monday, March 2, 2020 2:35 PM > To: dev-security-policy@lists.mozilla.org > Cc: Matt Palmer <mpal...@hezmatt.org> > Subject: Re: Acceptable forms of evidence for key compromise > > On Mon, 2 Mar 2020 13:48:55 +1100 > Matt Palmer via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > In my specific case, I've been providing a JWS[1] signed by the > > compromised private key, and CAs are telling me that they can't (or > > won't) work with a JWS, and thus no revocation is going to happen. > > Is this a reasonable response? > > I don't hate JWS, but I can see Ryan's point of view on this. Not every > "proof" is easy to definitively assess, and a CA doesn't want to get into > the > game of doing detailed forensics on (perhaps) random unfounded claims. > > Maybe it makes sense for Mozilla to provide in its policy (without limiting > what else might be accepted) an example method of demonstrating Key > Compromise > which it considers definitely sufficient ? > > I'd also be comfortable with such an example in the BRs, if people think > that's the right place to do this. > > > Nick. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://scanmail.trustwave.com/?c=4062&d=- > d_d3pcpfBniFU3M4wE7RXWpZKF7oGE841cFGIoHqA&s=5&u=https%3a%2f% > 2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
