I've created https://github.com/mozilla/pkipolicy/issues/205 to consider adding a requirement to a future version of Mozilla policy for CAs to either support a standardized mechanism for proving key compromise, or to publish acceptable mechanism(s) in their CPS.
- Wayne On Mon, Mar 2, 2020 at 2:38 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Using ACME as the revocation reporting mechanism moves the issue from > using a bespoke proof-of-possession/revocation request protocol to a known > address (i.e., the problem-reporting address disclosed in each CA’s > CPS/CCADB) to an issue of using a known proof-of-possession/revocation > protocol to a largely non-discoverable address (i.e., the “revoke-cert” > endpoint of each CA’s ACME server). > > > > There is no central registry of ACME directory URLs, so still significant > work would be required to make ACME’s “revoke-cert” endpoint useful across > CAs. > > > > As an alternative, a standard “revocation request” format could be > developed that leverages the relative discoverability of each CA’s > problem-reporting mechanism. > > > > Thanks, > > Corey > > > > From: Rob Stradling <r...@sectigo.com> > Sent: Monday, March 2, 2020 4:31 PM > To: Nick Lamb <n...@tlrmx.org>; mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org>; Corey Bonnell < > cbonn...@securetrust.com> > Cc: Matt Palmer <mpal...@hezmatt.org> > Subject: Re: Acceptable forms of evidence for key compromise > > > > "I do think there's value in developing some standard mechanism to request > revocation/demonstrate possession of the private key." > > > > Such as https://tools.ietf.org/html/rfc8555#section-7.6 < > https://scanmail.trustwave.com/?c=4062&d=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK4Mm7tnSoQ&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc8555%23section-7%2e6> > ? > > > > ISTM that any CA could stand up a standalone "revokeCert" API that only > accepts proofs signed by the private key associated with the certificate, > without that CA having to implement the rest of RFC8555. Would this count > as a "standard mechanism" (given that it's a portion of a Standards Track > RFC)? If so, why don't we simply say that this is the "standard mechanism"? > > > > @Matt: I read your tweet ( > https://twitter.com/tobermatt/status/1232779464783695873 < > https://scanmail.trustwave.com/?c=4062&d=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK9l05N2C8g&s=5&u=https%3a%2f%2ftwitter%2ecom%2ftobermatt%2fstatus%2f1232779464783695873> > ) as proposing this idea, but ISTM that you've stopped slightly short of > actually proposing it in this list thread. 😉 > > > > @Sleevi: JWS certainly isn't my favourite format, but ISTM that the WebPKI > is kinda stuck with it now (see RFC8555). > > > > _____ > > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org > <mailto:dev-security-policy-boun...@lists.mozilla.org> > on behalf of > Corey Bonnell via dev-security-policy < > dev-security-policy@lists.mozilla.org <mailto: > dev-security-policy@lists.mozilla.org> > > Sent: 02 March 2020 19:48 > To: Nick Lamb <n...@tlrmx.org <mailto:n...@tlrmx.org> >; > mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org > <mailto:mozilla-dev-security-pol...@lists.mozilla.org> > > Cc: Matt Palmer <mpal...@hezmatt.org <mailto:mpal...@hezmatt.org> > > Subject: RE: Acceptable forms of evidence for key compromise > > > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > > 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/ < > https://scanmail.trustwave.com/?c=4062&d=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK4xz54WB8A&s=5&u=https%3a%2f%2fmailarchive%2eietf%2eorg%2farch%2fmsg%2fspasm%2fqeVHLeG6-Q%5f47QKNdyOOxsAT3Zk%2f> > . > 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 > <mailto: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 <mailto: > dev-security-policy@lists.mozilla.org> > Cc: Matt Palmer <mpal...@hezmatt.org <mailto: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 <mailto: > 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 <mailto: > dev-security-policy@lists.mozilla.org> > https://scanmail.trustwave.com/?c=4062 < > https://scanmail.trustwave.com/?c=4062&d=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK48g4d6Jqg&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy> > &d=-d_d3pcpfBniFU3M4wE7RXWpZKF7oGE841cFGIoHqA&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
