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
"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
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
"but ISTM that you've stopped slightly short of actually proposing it in this
list thread. "
Or not!
From: dev-security-policy on
behalf of Rob Stradling via dev-security-policy
Sent: 02 March 2020 21:30
To: Nick Lamb ; mozilla-dev-security-policy
;
"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 ?
ISTM that any CA could stand up a standalone "revokeCert" API that only accepts
proofs signed by the
On Mon, Mar 02, 2020 at 07:48:23PM +, Corey Bonnell wrote:
> I do think there's value in developing some standard mechanism to request
> revocation/demonstrate possession of the private key.
Interestingly, there (more-or-less) is one these days, as part of ACME. It
requires the usual amount
On Mon, Mar 02, 2020 at 07:35:06PM +, Nick Lamb wrote:
> On Mon, 2 Mar 2020 13:48:55 +1100
> Matt Palmer via dev-security-policy
> 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
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
On Mon, 2 Mar 2020 13:48:55 +1100
Matt Palmer via dev-security-policy
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
Thanks. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1619359 to
track this
On Mon, Mar 2, 2020 at 2:59 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Between 26 Feb 2020 00:48:11 UTC and 26 Feb 2020 21:10:18 UTC, I sent three
> Certificate
On Mon, Mar 2, 2020 at 2:07 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > However, I get the feeling that you don’t put much stock into incident
> > reports and browsers dim view of shenanigans. That might be worth
> expanding
> > upon, if you believe
11 matches
Mail list logo
