Acceptable forms of evidence for key compromise

[Matt Palmer]

The BRs, in s4.9.1.1, say:

> The CA SHALL revoke a Certificate within 24 hours if one or more of the
> following occurs:
>
> [...]
> 3. The CA obtains evidence that the Subscriber's Private Key
> corresponding to the Public Key in the Certificate suffered a Key
> Compromise

I've come to have some concerns about this clause of the BRs, in that it
seems very much up to the CA to decide what constitutes valid "evidence" of
key compromise, and there doesn't appear to be anything (other than possible
mdsp censure, after the fact) preventing a CA using "your evidence is
insufficient" as a way of delaying revocation, potentially indefinitely.

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? If it is a reasonable response, what properties are necessary to
differentiate valid evidence from invalid? Is it appropriate for a CA to be
able to unilaterally decide what constitutes valid evidence, and should they
be able to change that decision at any time?

Relatedly, if a CA were to receive a key compromise notification which truly
*doesn't* have sufficient evidence of compromise, but which at least has
some degree of legitimacy (rather than "I haxxed teh keys to your CA, better
pay me dogecoin!!!11!one!"), is there (or should there be) any onus on the
CA to respond to that notification within a certain timeframe?

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.

I'd appreciate commentary and feedback on this area of the BRs and its
ramifications, to help me to decide whether to report these situations as
failures to revoke, or perhaps modify my procedures for reporting
publicly-trusted certificates whose keys have been published.

Thanks,
- Matt

[1] "JSON Web Signature", as specified in the standards-track RFC7515. It
is used in a variety of places, including, but not limited to, the Automatic
Certificate Management Environment (ACME, RFC8555) -- although I wasn't
consciously aware of that at the time I chose to generate key compromise
attestations in that format.

[Ryan Sleevi]

On Sun, Mar 1, 2020 at 9:49 PM Matt Palmer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> The BRs, in s4.9.1.1, say:
>
> > The CA SHALL revoke a Certificate within 24 hours if one or more of the
> > following occurs:
> >
> > [...]
> > 3. The CA obtains evidence that the Subscriber's Private Key
> > corresponding to the Public Key in the Certificate suffered a Key
> > Compromise
>
> I've come to have some concerns about this clause of the BRs, in that it
> seems very much up to the CA to decide what constitutes valid "evidence" of
> key compromise, and there doesn't appear to be anything (other than
> possible
> mdsp censure, after the fact) preventing a CA using "your evidence is
> insufficient" as a way of delaying revocation, potentially indefinitely.

That’s not quite correct. They also have to convince their auditor,
although whether or not you see that as a barrier depends.

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.

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

Honestly? Yes. And not just because JWS is trash (although it is; yes, I
have feelings), but broadly because the semantics of any given signature
format impact how reliable a proof of compromise is. The problem with using
JWS, PDF, or even something more bespoke, like Matt-Sig, is the general
risk of cross-protocol attacks, in which the same message might have
multiple interpretations depending on how it is processed.

PDF is perhaps a real-world example of this, in which appended data might
cause display mutations of the signed data. Another might PE signing, which
allows for the inclusion of unsigned data with a signed executable that can
be difficult for processing to distinguish.

There’s no reason to expect a CA to be prepared to support Arbitrary Format
Foo. While my distaste for the JOSE suite of boondoggles is deeply
entrenched, I do think there’s benefit in using common PDUs that CA tooling
already deals with. As discussed in the past, the CSR approach is not
without merit.

If it is a reasonable response, what properties are necessary to
> differentiate valid evidence from invalid? Is it appropriate for a CA to
> be
> able to unilaterally decide what constitutes valid evidence, and should
> they
> be able to change that decision at any time?

I appreciate the pursuit of a general rule here, which your questions seem
geared towards. The downside of over-prescriptivist approaches is that they
end up disadvantaging the reporter; the “minimum consistent bar” ends up
becoming a problematic barrier to overcome.

The short and simple answer is if you feel the CA has responded poorly,
sharing those details is the next step towards remedying it, and, if
possible, improving policy languages.

Relatedly, if a CA were to receive a key compromise notification which truly
> *doesn't* have sufficient evidence of compromise, but which at least has
> some degree of legitimacy (rather than "I haxxed teh keys to your CA,
> better
> pay me dogecoin!!!11!one!"), is there (or should there be) any onus on the
> CA to respond to that notification within a certain timeframe?

CAs are required to make a preliminary incident report available within 24
hours, including the “sod off your report is garbage”, as covered in 4.9.5.

The language is flexible in how CAs receive and process Problem Reports, in
part to allow CAs to adequately deal and the “the gubmint is spying on me
and my ex is working with mossad” nonsense reports that unfortunately most
security reporting mechanisms receive. At the same time, if there is belief
that there’s something unreasonable being imposed (such as requiring
Problem Reports be submitted only on a blood moon in the third half of the
Month of the Rabbit), well, then you’re exercising the right path here by
asking “What the heck?”

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?

[Matt Palmer]

On Sun, Mar 01, 2020 at 11:14:12PM -0500, Ryan Sleevi wrote:
> On Sun, Mar 1, 2020 at 9:49 PM Matt Palmer via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> > The BRs, in s4.9.1.1, say:
> >
> > > The CA SHALL revoke a Certificate within 24 hours if one or more of the
> > > following occurs:
> > >
> > > [...]
> > > 3. The CA obtains evidence that the Subscriber's Private Key
> > > corresponding to the Public Key in the Certificate suffered a Key
> > > Compromise
> >
> > I've come to have some concerns about this clause of the BRs, in that it
> > seems very much up to the CA to decide what constitutes valid "evidence" of
> > key compromise, and there doesn't appear to be anything (other than
> > possible
> > mdsp censure, after the fact) preventing a CA using "your evidence is
> > insufficient" as a way of delaying revocation, potentially indefinitely.
>
> That’s not quite correct. They also have to convince their auditor,
> although whether or not you see that as a barrier depends.

No, I don't see auditors as a barrier to anything.

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

> > 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?
>
> Honestly? Yes.

Fair enough. Your honesty is appreciated.

> There’s no reason to expect a CA to be prepared to support Arbitrary Format
> Foo. While my distaste for the JOSE suite of boondoggles is deeply
> entrenched, I do think there’s benefit in using common PDUs that CA tooling
> already deals with. As discussed in the past, the CSR approach is not
> without merit.

I found the argument that it was risky to use anything that could possibly
be mistaken for a "real" web PKI artifact, to be quite compelling. That is
why I kept away from using a CSR, self-signed cert ("poisoned" or
otherwise), or anything of that nature.

At any rate, it is at least easy enough to test whether CAs are able to
handle a CSR any better than a JWS. There's plenty of fish still in the
barrel; I'll pull a few keys out of cold storage, generate CSRs from them,
and see if CAs are able to process those any easier.

> > Relatedly, if a CA were to receive a key compromise notification which
> > truly *doesn't* have sufficient evidence of compromise, but which at
> > least has some degree of legitimacy (rather than "I haxxed teh keys to
> > your CA, better pay me dogecoin!!!11!one!"), is there (or should there
> > be) any onus on the CA to respond to that notification within a certain
> > timeframe?
>
> CAs are required to make a preliminary incident report available within 24
> hours, including the “sod off your report is garbage”, as covered in 4.9.5.

Aha, I'd forgotten about that bit. That's pretty cut and dried.

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

- Matt

[Ryan Sleevi]

On Mon, Mar 2, 2020 at 2:07 AM Matt Palmer via dev-security-policy <
dev-secur...@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.

[Nick Lamb]

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

Matt Palmer via dev-security-policy
<dev-secur...@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.

[Corey Bonnell]

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

_______________________________________________
dev-security-policy mailing list
dev-secur...@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

[Matt Palmer]

On Mon, Mar 02, 2020 at 07:35:06PM +0000, Nick Lamb wrote:
> On Mon, 2 Mar 2020 13:48:55 +1100
> Matt Palmer via dev-security-policy
> <dev-secur...@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 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

[Matt Palmer]

On Mon, Mar 02, 2020 at 07:48:23PM +0000, 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

[Rob Stradling]

"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 <dev-security-...@lists.mozilla.org> on behalf of Corey Bonnell via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: 02 March 2020 19:48
To: Nick Lamb <n...@tlrmx.org>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Cc: Matt Palmer <mpa...@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 <dev-security-...@lists.mozilla.org> On
Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, March 2, 2020 2:35 PM
To: dev-secur...@lists.mozilla.org
Cc: Matt Palmer <mpa...@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-secur...@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 ?

[Rob Stradling]

"but ISTM that you've stopped slightly short of actually proposing it in this list thread. 😉"

Or not! 😄

________________________________
From: dev-security-policy <dev-security-...@lists.mozilla.org> on behalf of Rob Stradling via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: 02 March 2020 21:30
To: Nick Lamb <n...@tlrmx.org>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>; Corey Bonnell <CBon...@securetrust.com>

Cc: Matt Palmer <mpa...@hezmatt.org>
Subject: Re: Acceptable forms of evidence for key compromise

https://lists.mozilla.org/listinfo/dev-security-policy

[Corey Bonnell]

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-s...@lists.mozilla.org>; Corey Bonnell <CBon...@securetrust.com>
Cc: Matt Palmer <mpa...@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-...@lists.mozilla.org <mailto:dev-security-...@lists.mozilla.org> > on behalf of Corey Bonnell via dev-security-policy <dev-secur...@lists.mozilla.org <mailto:dev-secur...@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-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org> >
Cc: Matt Palmer <mpa...@hezmatt.org <mailto:mpa...@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-...@lists.mozilla.org <mailto:dev-security-...@lists.mozilla.org> > On
Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, March 2, 2020 2:35 PM
To: dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
Cc: Matt Palmer <mpa...@hezmatt.org <mailto:mpa...@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-secur...@lists.mozilla.org <mailto:dev-secur...@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-secur...@lists.mozilla.org <mailto:dev-secur...@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

[Rob Stradling]

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

________________________________

https://scanmail.trustwave.com/?c=4062&d=-d_d3pcpfBniFU3M4wE7RXWpZKF7oGE841cFGIoHqA&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy<https://scanmail.trustwave.com/?c=4062&d=lfvd3rlkzXccymkP6MZsFT-gOI-ZJlGuK48g4d6Jqg&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy>

[Corey Bonnell]

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 <r...@sectigo.com>
Sent: Monday, March 2, 2020 5:06 PM
To: Corey Bonnell <CBon...@securetrust.com>; Nick Lamb <n...@tlrmx.org>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Cc: Matt Palmer <mpa...@hezmatt.org>
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 <r...@sectigo.com <mailto:r...@sectigo.com> >
Sent: Monday, March 2, 2020 4:31 PM
To: Nick Lamb <n...@tlrmx.org <mailto:n...@tlrmx.org> >; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org> >; Corey Bonnell <CBon...@securetrust.com <mailto:CBon...@securetrust.com> >
Cc: Matt Palmer <mpa...@hezmatt.org <mailto:mpa...@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=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 <dev-security-...@lists.mozilla.org <mailto:dev-security-...@lists.mozilla.org> > on behalf of Corey Bonnell via dev-security-policy <dev-secur...@lists.mozilla.org <mailto:dev-secur...@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-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org> >
Cc: Matt Palmer <mpa...@hezmatt.org <mailto:mpa...@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=r4Pd3pPseGq57uT68fGQpVlD7wldYo9_Tw800Khk4w&s=5&u=https%3a%2f%2fmailarchive%2eietf%2eorg%2farch%2fmsg%2fspasm%2fqeVHLeG6-Q%5f47QKNdyOOxsAT3Zk%2f> .

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

[Wayne Thayer]

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

> 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-...@lists.mozilla.org
> <mailto:dev-security-...@lists.mozilla.org> > on behalf of
> Corey Bonnell via dev-security-policy <
> dev-secur...@lists.mozilla.org <mailto:
> dev-secur...@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-s...@lists.mozilla.org
> <mailto:mozilla-dev-s...@lists.mozilla.org> >
> Cc: Matt Palmer <mpa...@hezmatt.org <mailto:mpa...@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>

> 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-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Tim Hollebeek]

I agree with Corey on this. I was disappointed that the LAMPS discussion two
years ago was not as helpful as it could have been.

For what it's worth, while we generally try to accept any reasonable proof of
key
compromise, we have seen quite a large variety of things sent to us. This
includes
people actually sending us private keys in various forms, which is completely
unnecessary and something we'd like to avoid.

When we are unable to verify a proof, we provide explicit instructions on how
to
create a proof in a standardized form that's easy to very. I believe it
currently involves signing something with openssl, so it should be easy to
carry
out for anyone who is involved in these sorts of discussions and has access to
the private key.

Standardized procedures (plural, I don't think a one size fits all solution
would
necessarily be good) would be very helpful for everyone, including mitigating
the risk that
some less sophisticated CAs accept proofs that are not valid, introducing a
potential
denial of service attack. The whole purpose of having minimum security
requirements
is to make sure important things like this are handled correctly, using
procedures
that have received appropriate scrutiny from individuals who understand the
security implications.

I also think it's potentially useful to discuss standardizing lists of known
compromised
keys, and how to check them before issuance. The problem of revoking them
could be avoided entirely if they were never issued in the first place.

BTW the same is currently true for proving domain control for the purposes of
revocation ... existing practice for CAs is currently all over the map, and
we've
discussed it before without reaching a resolution. It would be useful if
there
were actual requirements for that, too.

-Tim

> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On Behalf Of Corey Bonnell via dev-security-policy
> Sent: Monday, March 2, 2020 2:48 PM
> To: Nick Lamb <n...@tlrmx.org>; Mozilla <mozilla-dev-security-
> pol...@lists.mozilla.org>
> Cc: Matt Palmer <mpa...@hezmatt.org>
> Subject: RE: Acceptable forms of evidence for key compromise
>

> 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 <dev-security-...@lists.mozilla.org>
> On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: Monday, March 2, 2020 2:35 PM
> To: dev-secur...@lists.mozilla.org
> Cc: Matt Palmer <mpa...@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-secur...@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-secur...@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

[Matt Palmer]

On Tue, Mar 17, 2020 at 03:51:13PM +0000, Tim Hollebeek wrote:
> For what it's worth, while we generally try to accept any reasonable proof
> of key compromise, we have seen quite a large variety of things sent to
> us. This includes people actually sending us private keys in various
> forms, which is completely unnecessary and something we'd like to avoid.

You probably want to tell the people handling rev...@digicert.com to stop
asking for them, then. I stopped counting after the first four instances I
found in my archive of revocation-related communications of Digicert
representatives asking for a copy of the private key.

> When we are unable to verify a proof, we provide explicit instructions on
> how to create a proof in a standardized form that's easy to very. I
> believe it currently involves signing something with openssl, so it should
> be easy to carry out for anyone who is involved in these sorts of
> discussions and has access to the private key.

There's "access", and then there's "immediate and easy access". I very
deliberately don't keep the 1.3M keys I've collected just lying around to be
poked at with openssl at a moment's notice. Dragging a key out of cold
storage is deliberately not an easy operation.

(Incidentally, that also makes ACME's revocation-by-private-key operation
difficult when a cert is issued using a previously compromised key, but
that's a separate discussion I need to have with the ACME WG).

> I also think it's potentially useful to discuss standardizing lists of
> known compromised keys, and how to check them before issuance. The
> problem of revoking them could be avoided entirely if they were never
> issued in the first place.

I don't have conclusive data (yet), but the impression I'm getting so far
is that most keys are, in fact, compromised after the certificate has been
issued, because people put the key+cert into a public GitHub repo or other
public online location (like pastebin), for use in their app. I'm yet to
find the time to do an analysis of "certificates whose notBefore is later
than when they were discovered by the keyfinder". Once that happens, I'll
be able to give a better indication of how much value there is in strict
pre-issuance checks for key compromise.

- Matt