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
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
