As mentioned by Ryan earlier in this thread, CCADB-disclosed problem-reporting mechanisms don’t bind the CA to respond to the Certificate Problem Report per section 4.9 of the BRs. This “revoke-cert” API URL disclosure would fall into the same category – it might work for most cases, but there’s nothing currently mandating that CAs act on revocation requests sent to the “revoke-cert” endpoint unless CAs start adding this URL to section 1.5.2 of their CPS.
Per the BRs, CAs must already timely respond to Certificate Problem Reports sent to their problem-reporting address as disclosed in section 1.5.2 of their CPS. Standardization of a revocation request format that uses each CA’s existing problem-reporting mechanism gets us the best of both worlds: a common way of expressing the revocation request and the discoverability and well-defined mandatory response of the official problem-reporting mechanism as listed in the CPS. Thanks, Corey From: Rob Stradling <[email protected]> Sent: Monday, March 2, 2020 5:06 PM To: Corey Bonnell <[email protected]>; Nick Lamb <[email protected]>; mozilla-dev-security-policy <[email protected]> Cc: Matt Palmer <[email protected]> Subject: Re: Acceptable forms of evidence for key compromise "As an alternative, a standard “revocation request” format could be developed that leverages the relative discoverability of each CA’s problem-reporting mechanism." Alternatively, how about we add discoverability to my proposal by asking Kathleen to add a "revokeCert API URL" field to the CCADB? _____ From: Corey Bonnell Sent: Monday, March 02, 2020 21:38 To: Rob Stradling; Nick Lamb; mozilla-dev-security-policy Cc: Matt Palmer Subject: RE: Acceptable forms of evidence for key compromise 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 <[email protected] <mailto:[email protected]> > Sent: Monday, March 2, 2020 4:31 PM To: Nick Lamb <[email protected] <mailto:[email protected]> >; mozilla-dev-security-policy <[email protected] <mailto:[email protected]> >; Corey Bonnell <[email protected] <mailto:[email protected]> > Cc: Matt Palmer <[email protected] <mailto:[email protected]> > 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=r4Pd3pPseGq57uT68fGQpVlD7wldYo9_TwBh2fQ3sg&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=r4Pd3pPseGq57uT68fGQpVlD7wldYo9_T1oz0_Bn4Q&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 <[email protected] <mailto:[email protected]> > on behalf of Corey Bonnell via dev-security-policy <[email protected] <mailto:[email protected]> > Sent: 02 March 2020 19:48 To: Nick Lamb <[email protected] <mailto:[email protected]> >; mozilla-dev-security-policy <[email protected] <mailto:[email protected]> > Cc: Matt Palmer <[email protected] <mailto:[email protected]> > 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=r4Pd3pPseGq57uT68fGQpVlD7wldYo9_Tw800Khk4w&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 <[email protected] <mailto:[email protected]> > On Behalf Of Nick Lamb via dev-security-policy Sent: Monday, March 2, 2020 2:35 PM To: [email protected] <mailto:[email protected]> Cc: Matt Palmer <[email protected] <mailto:[email protected]> > Subject: Re: Acceptable forms of evidence for key compromise On Mon, 2 Mar 2020 13:48:55 +1100 Matt Palmer via dev-security-policy <[email protected] <mailto:[email protected]> > 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 [email protected] <mailto:[email protected]> https://scanmail.trustwave.com/?c=4062 <https://scanmail.trustwave.com/?c=4062&d=r4Pd3pPseGq57uT68fGQpVlD7wldYo9_Twxn1vNsuQ&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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
