RE: Acceptable forms of evidence for key compromise

[Corey Bonnell via dev-security-policy]

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  
Sent: Monday, March 2, 2020 5:06 PM
To: Corey Bonnell ; Nick Lamb ; 
mozilla-dev-security-policy 
Cc: Matt Palmer 
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 mailto:r...@sectigo.com> > 
Sent: Monday, March 2, 2020 4:31 PM
To: Nick Lamb mailto:n...@tlrmx.org> >; 
mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >; Corey Bonnell 
mailto:cbonn...@securetrust.com> >
Cc: Matt Palmer mailto: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 

  ?

 

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 

 ) 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 mailto:dev-security-policy-boun...@lists.mozilla.org> > on behalf of Corey 
Bonnell via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> >
Sent: 02 March 2020 19:48
To: Nick Lamb mailto:n...@tlrmx.org> >; 
mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Cc: Matt Palmer 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/ 

Re: Acceptable forms of evidence for key compromise

[Rob Stradling via dev-security-policy]

"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 
Sent: Monday, March 2, 2020 4:31 PM
To: Nick Lamb ; mozilla-dev-security-policy 
; Corey Bonnell 

Cc: Matt Palmer 
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
 ?



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)
 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 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 on behalf of Corey Bonnell via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
Sent: 02 March 2020 19:48
To: Nick Lamb mailto:n...@tlrmx.org>>; 
mozilla-dev-security-policy 
mailto:mozilla-dev-security-pol...@lists.mozilla.org>>
Cc: Matt Palmer 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/.
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 
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
Cc: Matt Palmer mailto:mpal...@hezmatt.org>>
Subject: Re: Acceptable forms of evidence for key compromise

On Mon, 2 Mar 2020 13:48:55 +11

RE: Acceptable forms of evidence for key compromise

[Corey Bonnell via dev-security-policy]

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  
Sent: Monday, March 2, 2020 4:31 PM
To: Nick Lamb ; mozilla-dev-security-policy 
; Corey Bonnell 

Cc: Matt Palmer 
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 

  ?

 

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 

 ) 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 mailto:dev-security-policy-boun...@lists.mozilla.org> > on behalf of Corey 
Bonnell via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> >
Sent: 02 March 2020 19:48
To: Nick Lamb mailto:n...@tlrmx.org> >; 
mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Cc: Matt Palmer 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/ 

 .
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 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 
 
Cc: Matt Palmer 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
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 (per

Re: Acceptable forms of evidence for key compromise

[Rob Stradling via dev-security-policy]

"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 
; Corey Bonnell 

Cc: Matt Palmer 
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.


"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 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) 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  on 
behalf of Corey Bonnell via dev-security-policy 

Sent: 02 March 2020 19:48
To: Nick Lamb ; mozilla-dev-security-policy 

Cc: Matt Palmer 
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/.
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  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 
Subject: Re: Acceptable forms of evidence for key compromise

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

Re: Acceptable forms of evidence for key compromise

[Rob Stradling via 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 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) 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  on 
behalf of Corey Bonnell via dev-security-policy 

Sent: 02 March 2020 19:48
To: Nick Lamb ; mozilla-dev-security-policy 

Cc: Matt Palmer 
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/.
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  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 
Subject: Re: Acceptable forms of evidence for key compromise

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 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Acceptable forms of evidence for key compromise

[Matt Palmer via dev-security-policy]

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 of faffing around that's required to do anything
non-trivial with a JWS, but it does get the job done.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Acceptable forms of evidence for key compromise

[Matt Palmer via dev-security-policy]

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 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 think it would be useful if Mozilla were to require that CPS have details
of acceptable methods of demonstrating key compromise.  There's even a
section which it would fit into nicely: 4.9.12, "Special Requirements for
Key Compromise".  It wouldn't solve the primary problem that I have --
having to special case every CA's pet method for requiring evidence -- but
it would, at least, close the "oh no wait we need *this* evidence" loophole,
and give reporting parties something to go off when reporting key
compromises.

Requiring that a CA's standards of evidence didn't require the use of one
specific tool (`openssl dgst` I'm looking at *you*) would be icing on the
cake.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Acceptable forms of evidence for key compromise

[Corey Bonnell via dev-security-policy]

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  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 
Subject: Re: Acceptable forms of evidence for key compromise

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

Re: Acceptable forms of evidence for key compromise

[Nick Lamb via dev-security-policy]

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 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://lists.mozilla.org/listinfo/dev-security-policy

Re: Sectigo: Failure to process revocation request within 24 hours

[Ryan Sleevi via dev-security-policy]

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 Problem Reports to sslab...@sectigo.com, reporting that
> certificates issued by then were using keys which have been compromised due
> to being publicly disclosed.  As of the time of writing, I have not
> received
> a preliminary report of Sectigo's findings, as I believe is required by
> section 4.9.5 of the Baseline Requirements.
>
> In each case, I received an auto-acknowledgement e-mail containing a case
> number, which indicates that Sectigo did, in fact, receive my problem
> report.
>
> Due to a mistake on my part, the evidence I provided to Sectigo was not
> sufficient to verify that the key was in fact compromised, so I am not
> claiming that Sectigo has fallen foul of BR s4.9.1.1.  However, as BR
> s4.9.5
> require a report to be provided within 24 hours, I still believe Sectigo
> has an operational deficiency which requires investigation.
>
> The times of the e-mails I sent, the Sectigo case number I received in
> response, and the further responses I have received from Sectigo, if any,
> are detailed below.  All times are taken from the `Date` header of the
> relevant e-mail, adjusted to UTC if required.
>
> Case #00572387
>   https://crt.sh/?id=2455920199
>   Sent: 26 Feb 2020 00:48:11 +
>   Auto-ack: 26 Feb 2020 00:48:24 +
>
>   At 27 Feb 2020 19:15:10 +, I received an e-mail purporting to be from
>   Sectigo Security, quoting my initial report, and saying "we will look
> into
>   this right away".  Note that even this response, which I do not consider
>   qualifies as a "preliminary report", was sent over 24 hours after the
>   initial problem report.
>
>   No further response has been received since then.
>
>
> Case #00572465
>   https://crt.sh/?id=2413850414
>   Sent: 26 Feb 2020 05:07:34 +
>   Auto-ack: 26 Feb 2020 05:07:45 +
>
>   No further response has been received since the auto-acknowledgement.
>
>
> Case #00573105
>   https://crt.sh/?id=683622319
>   Sent: Wed, 26 Feb 2020 21:10:18 +
>   Auto-ack: Wed, 26 Feb 2020 21:10:32 +
>
>   No further response has been received since the auto-acknowledgement.
>
> - Matt
>
> ___
> 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

Re: Acceptable forms of evidence for key compromise

[Ryan Sleevi via dev-security-policy]

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 the incident reporting process is not adequately
> > protecting users or balancing tradeoffs.
>
> No, it's not that.  I like the incident report system, and Mozilla does a
> reasonable job of enforcing what rules there already are.  It's just that
> CAs
> often argue that they didn't *know* that doing a bad thing was bad because
> the rules didn't *say* that it was a bad thing, and when I started
> operating
> in this area I found something that I thought was potentially a loophole,
> and I wanted to discuss it before standing up and shouting "HOUSTON WE HAVE
> AN INCIDENT!" -- because *that* is the sort of thing that devalues the
> incident reporting system.
>

I agree, there's a disconcerting trend reappearing of CAs using ignorance
as a justification, especially when they've been amply and exhaustively
discussed here. You should feel free if/as you see that, in incident
reports and Bugzilla, to call it out with references to earlier discussions.

Starting this thread, for example, is extremely useful, so thanks for doing
that :)


> > I ask this because I accidentally sent a couple of compromise
> notifications
> > > with an incorrect URL.  While one notification got what appeared to be
> a
> > > human saying "we'll look into it" (which itself was sent more than 24
> hours
> > > after I received the corresponding auto-ack), others have been greeted
> with
> > > complete radio silence (other than the auto-ack).  This seems...
> > > sub-optimal.
> >
> > Did you use the CPS documented problem reporting mechanism?
>
> I've been using the "Report a problem" data from crt.sh, which is
> populated,
> I believe, from CCADB.  I just checked the CPS of the two CAs at issue, and
> in both cases the initial reports were sent to the correct e-mail address.
>

Yeah. Unfortunately, the CCADB information is not "binding" on CAs yet;
that is, while it's self-reported, it doesn't become an auditable violation
if a CA fails to respond promptly. This does create an unfortunate and
understandable gap in accountability, and so double checking with the
CP/CPS is definitely the right path before declaring an incident.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy