Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

[Ben Wilson]

This email begins discussion of a potential change to section 6 of the
Mozilla Root Store Policy
<https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation>.


The method by which a person may provide a CA with proof of private key
compromise has been an issue discussed on the mdsp list
<https://groups.google.com/g/mozilla.dev.security.policy/c/DeztURyCHPo/m/1IZnDsMuAQAJ>
this past year.

According to section 4.9.1.1 of the CA/Browser Forum's Baseline Requirements
<https://cabforum.org/baseline-requirements-documents/>, key compromise is
one reason for certificate revocation within a 24-hour period, and section
4.9.3 of the Baseline Requirements requires that CAs provide "clear
instructions for reporting suspected Private Key Compromise ..." and that
they "publicly disclose the instructions through a readily accessible
online means and in section 1.5.2 of their CPS." However, in many of the
CPSes reviewed by Mozilla, the only information appearing is a contact
person's street address, email address, and sometimes a telephone number.
Seldom is this information provided in the context of revocation for key
compromise, and in many situations, email is an inadequate method of
communicating key compromises, especially at scale. Some CAs have portals
(e.g. DigiCert <https://problemreport.digicert.com/key-compromise/report>
and Sectigo <https://secure.sectigo.com/products/RevocationPortal>) in
addition to an email address to submit revocation requests. There is also
an open-source ACME server which is designed for the sole purpose of
receiving revocations: https://github.com/tobermorytech/acmevoke.

Github Issue #205 <https://github.com/mozilla/pkipolicy/issues/205> notes
that the best place for disclosure of such revocation methods would be in
section 4.9.12 of a CA's CPS. Section 4.9.12 of the RFC 3647 outline
<https://tools.ietf.org/html/rfc3647#section-6> is titled "Special
requirements re key compromise". Not only will this requirement make it
easier for the Mozilla community to report key compromises, but it will
also help streamline key-compromise-based revocations, thereby reducing the
number of Bugzilla incidents filed for delayed revocation.

Draft language in
https://github.com/BenWilson-Mozilla/pkipolicy/commit/719b834689949e869a0bd94f7bacb8dde0ccc9e4
proposes to add a last sentence to section 6 of the MRSP reading "Section
4.9.12 of a CA's CP/CPS MUST clearly specify the methods that parties may
use to demonstrate private key compromise."

We recognize that there is some overlap with the BR 4.9.3 requirement that
certain instructions be provided in section 1.5.2 of the CPS, but we
believe that the overlap can be worked through during this discussion and,
if not, a related discussion within the CA/Browser Forum.

We look forward to your comments and suggestions on this issue.

Sincerely yours,
Ben Wilson
Mozilla Root Store Program

[Dimitris Zacharopoulos]

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

I believe this information should be the "minimum" accepted methods of
proving that a Private Key is compromised. We should allow CAs to accept
other methods without the need to first update their CP/CPS. Do people
think that the currently proposed language would forbid a CA from
accepting methods that are not explicitly documented in the CP/CPS?

I also think that "parties" is a bit ambiguous, so I would suggest
modifying that to follow the language of the BRs section 4.9.2
"Subscribers, Relying Parties, Application Software Suppliers, and other
third parties". Here is my proposed change:

"Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods (at a
minimum) that Subscribers, Relying Parties, Application Software
Suppliers, and other third parties may use to demonstrate private key
compromise."

Thank you,
Dimitris.

[Ben Wilson]

On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:

>
> I believe this information should be the "minimum" accepted methods of
> proving that a Private Key is compromised. We should allow CAs to accept
> other methods without the need to first update their CP/CPS. Do people
> think that the currently proposed language would forbid a CA from
> accepting methods that are not explicitly documented in the CP/CPS?
>
> I also think that "parties" is a bit ambiguous, so I would suggest
> modifying that to follow the language of the BRs section 4.9.2
> "Subscribers, Relying Parties, Application Software Suppliers, and other
> third parties". Here is my proposed change:
>
> "Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods (at a
> minimum) that Subscribers, Relying Parties, Application Software
> Suppliers, and other third parties may use to demonstrate private key
> compromise."
>

> Dimitris,
Instead, what about something like, "Section 4.9.12 of a CA's CP/CPS MUST
clearly specify its accepted methods that Subscribers, Relying Parties,

Application Software Suppliers, and other third parties may use to

demonstrate private key compromise. A CA MAY allow additional, alternative
methods that do not appear in section 4.9.12 of its CP/CPS." ?
Ben

[Dimitris Zacharopoulos]

That works better. Thank you.

Dimitris.

[Ryan Sleevi]

On Thu, Nov 12, 2020 at 1:39 PM Ben Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos <ji...@it.auth.gr>

> wrote:
>
> >
> > I believe this information should be the "minimum" accepted methods of
> > proving that a Private Key is compromised. We should allow CAs to accept
> > other methods without the need to first update their CP/CPS. Do people
> > think that the currently proposed language would forbid a CA from
> > accepting methods that are not explicitly documented in the CP/CPS?
> >
> > I also think that "parties" is a bit ambiguous, so I would suggest
> > modifying that to follow the language of the BRs section 4.9.2
> > "Subscribers, Relying Parties, Application Software Suppliers, and other
> > third parties". Here is my proposed change:
> >
> > "Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods (at a
> > minimum) that Subscribers, Relying Parties, Application Software
> > Suppliers, and other third parties may use to demonstrate private key
> > compromise."
> >
> > Dimitris,
> Instead, what about something like, "Section 4.9.12 of a CA's CP/CPS MUST
> clearly specify its accepted methods that Subscribers, Relying Parties,
> Application Software Suppliers, and other third parties may use to
> demonstrate private key compromise. A CA MAY allow additional, alternative
> methods that do not appear in section 4.9.12 of its CP/CPS." ?
>

I understand and appreciate Dimitris' concern, but I think your original
language works better for Mozilla users in practice, and sadly, moves us
back in a direction that the trend has been to (carefully) move away from.

I would say the first goal is transparency, and I think that both proposals
try to accomplish that baseline level of providing some transparency. Where
I think it's different is that the concern Dimitris raised about
"minimums", and the proposed language here, is that it discourages
transparency. "We accept X or Y", and a secret document suggesting "We also
accept Z", makes it difficult to evaluate a CA on principle.

The second goal is auditability: whether or not the CP/CPS represents a
binding commitment to the community. This is why they exist, and they're
supposed to help relying parties not only understand how the CA operates,
but how it is audited. If a CA has a secret document Foo that discloses
secret method Z, is the failure to actually support secret method Z worth
noting within the audit? I would argue yes, but this approach would
(effectively) argue no.

I think your original language was better suited for this, and is
consistent with the view that the CP/CPS is both the primary document that
becomes part of the auditable controls, and is the primary document for
reviewing how well a CA aligns with Mozilla's practices, needs, and users.

Yes, this does mean they would need to update their CP/CPS as they
introduce new methods, but this seems a net-positive for everyone. Getting
CAs more attuned into updating their CP/CPS, to provide adequate
disclosure, seems like a net-win, even though I'm sure some CAs have
designed processes and contracts that make this difficult. However, the
industry of the past 10 years has shown the importance of being able to
update the CP/CPS, and clearly document it, so I think we should
increasingly be skeptical about statements about the challenges.

[Nick Lamb]

On Thu, 12 Nov 2020 15:51:55 -0500
Ryan Sleevi via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> I would say the first goal is transparency, and I think that both
> proposals try to accomplish that baseline level of providing some
> transparency. Where I think it's different is that the concern
> Dimitris raised about "minimums", and the proposed language here, is
> that it discourages transparency. "We accept X or Y", and a secret
> document suggesting "We also accept Z", makes it difficult to
> evaluate a CA on principle.

[...]

> Yes, this does mean they would need to update their CP/CPS as they
> introduce new methods, but this seems a net-positive for everyone.

I think the concern about defining these other than as minimums is
scenarios in which it's clear to us that key compromise has taken place
but your preferred policy forbids a CA from acting on that knowledge on
the grounds that doing so isn't "transparent" enough for your liking
because their policy documents did not spell out the method which
happened to be used.

The goal of this policy change is to avoid the situation where a
researcher has one or more compromised keys and, rather than being able
to quickly and securely set in motion the process of revoking relevant
certificates and forbidding more being issued they end up in a game of
telephone (perhaps literally) with a CA because its policies are
unclear or unworkable.

You seem to anticipate a quite different environment in which "secret
documents" are used to justify revocations which you presumably see as
potentially illegitimate. I haven't seen any evidence of anything like
that happening, or of anybody seeking to make it happen - which surely
makes a Mozilla policy change to try to prevent it premature.


Nick.

[Dimitris Zacharopoulos]

> I would say the first goal is transparency, and I think that both proposals
> try to accomplish that baseline level of providing some transparency. Where
> I think it's different is that the concern Dimitris raised about
> "minimums", and the proposed language here, is that it discourages
> transparency. "We accept X or Y", and a secret document suggesting "We also
> accept Z", makes it difficult to evaluate a CA on principle.

There is transparency that the CA has evaluated some reporting
mechanisms and these will be documented in the CPS. However, on an issue
like compromised key reporting, there is no single recipe that covers
all possible and secure ways for a third-part to report a key
compromise. This has already been demonstrated in the various
discussions on this Forum. In such time-sensitive issues, where
certificates must be revoked within 24 hours, CAs should have the
liberty to accept a key compromise being reported by a method that might
be considered acceptable but which the CA's engineers didn't think about
when drafting the CPS. We can't expect a CA to update a CPS within 24
hours to allow additional reporting methods before accepting them.

For CAs that want to do the right thing with this flexibility, the
original language Ben proposed seems to be problematic, which is why I
highlighted it in the discussion. The updated language keeps all the
"good" things from the original language, and allows the CA to accept a
reporting method that they may have not considered. Obviously, the
logical thing is that once this new method is accepted, the CPS should
be updated to include that additional method but that might take place
later, after the report was accepted and certificates revoked.

I can't think of a bad scenario with this added language.

>
> The second goal is auditability: whether or not the CP/CPS represents a
> binding commitment to the community. This is why they exist, and they're
> supposed to help relying parties not only understand how the CA operates,
> but how it is audited. If a CA has a secret document Foo that discloses
> secret method Z, is the failure to actually support secret method Z worth
> noting within the audit? I would argue yes, but this approach would
> (effectively) argue no.

This makes no sense to me. We're not discussing secrets here. Say a
third party reports a key compromise by sending a signed plaintext
message, and the CA has only indicated as accepting a CSR with a
specific string in the CN field. The updated proposal would allow the CA
to evaluate this "undocumented" (in the CPS) reporting method, check for
its credibility/accuracy and proceed with accepting it or not.

The original proposal seems to forbid this and forces the CA instructing
the reporter to create a CSR with a specific string because that's the
only thing allowed in the CPS.

I hope this makes it clearer.

[Ryan Sleevi]

On Thu, Nov 12, 2020 at 10:51 PM Nick Lamb via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Thu, 12 Nov 2020 15:51:55 -0500
> Ryan Sleevi via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>

> > I would say the first goal is transparency, and I think that both
> > proposals try to accomplish that baseline level of providing some
> > transparency. Where I think it's different is that the concern
> > Dimitris raised about "minimums", and the proposed language here, is
> > that it discourages transparency. "We accept X or Y", and a secret
> > document suggesting "We also accept Z", makes it difficult to
> > evaluate a CA on principle.
>

> [...]
>
> > Yes, this does mean they would need to update their CP/CPS as they
> > introduce new methods, but this seems a net-positive for everyone.
>
> I think the concern about defining these other than as minimums is
> scenarios in which it's clear to us that key compromise has taken place
> but your preferred policy forbids a CA from acting on that knowledge on
> the grounds that doing so isn't "transparent" enough for your liking
> because their policy documents did not spell out the method which
> happened to be used.
>

I'm afraid this misunderstands things.

I want it to be explicit whether or not a CA is making a restrictive set or
not. That is, it should be clear if a CA is saying "We will only accept
these specific methods" or if the CA is saying "We will accept these
methods, plus any method at our discretion".

It's very easy for a CA to be transparent about the latter, and is no
different than the so-called "any other method" that was 3.2.2.4.10 in the
BRs.

The problem with the updated language from Ben is that it makes it
indistinguishable whether or not the CP/CPS disclosed method is a complete
set (i.e. that the CA will reject a reported compromise because it fails to
meet their preferred method) or not. The fact that there can be "secret"
documents which could say "We'll accept anything at our discretion" or that
it could be empty is a problem.

You seem to be taking it as if the CA has to provide exhaustive technical
details for each method. That's not the case. They need to disclose the
minimum (which might be "we accept anything at our discretion if e-mailed
to us"), but with the original language, they would functionally need to
disclose whether or not they will *reject* something not on that list, and
the proposed revision removes that.

>
> You seem to anticipate a quite different environment in which "secret
> documents" are used to justify revocations which you presumably see as
> potentially illegitimate. I haven't seen any evidence of anything like
> that happening, or of anybody seeking to make it happen - which surely
> makes a Mozilla policy change to try to prevent it premature.

I encourage you to make use of PACER/RECAP then.

[Ryan Sleevi]

On Fri, Nov 13, 2020 at 2:55 AM Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:

> There is transparency that the CA has evaluated some reporting
> mechanisms and these will be documented in the CPS. However, on an issue
> like compromised key reporting, there is no single recipe that covers
> all possible and secure ways for a third-part to report a key
> compromise.

Sure, and the original proposed language doesn't restrict this.

The CA can still disclose "Email us, and we'll work it out with you", and
that's still better than the status quo today, and doesn't require the
CP/CPS update you speculate about.

> For CAs that want to do the right thing with this flexibility, the
> original language Ben proposed seems to be problematic, which is why I
> highlighted it in the discussion.

As above

> The updated language keeps all the
> "good" things from the original language, and allows the CA to accept a
> reporting method that they may have not considered. Obviously, the
> logical thing is that once this new method is accepted, the CPS should
> be updated to include that additional method but that might take place
> later, after the report was accepted and certificates revoked.
>
> I can't think of a bad scenario with this added language.
>

I addressed this in my reply to Nick, but for your benefit, the "bad" thing
here is a CA that lists, in their CP/CPS, "We will only accept using our
convoluted API that requires you to submit on the lunar equinox", and then
states "Well, that's just the minimum, we have this doc over here saying
we'll also consider X, Y, Z".

The modified language fully allows that. The original language would see
methods X, Y, Z also added to the CP/CPS.

> This makes no sense to me. We're not discussing secrets here. Say a
> third party reports a key compromise by sending a signed plaintext
> message, and the CA has only indicated as accepting a CSR with a
> specific string in the CN field. The updated proposal would allow the CA
> to evaluate this "undocumented" (in the CPS) reporting method, check for
> its credibility/accuracy and proceed with accepting it or not.
>

The original proposal also allows this, by saying exactly what you stated
here, but within the CP/CPS.
The modified proposal, however, keeps secret whether or not the CA has a
policy to unconditionally reject such messages.

You seem to be thinking the original proposal prevents any discretion; it
doesn't. I'm trying to argue that such discretion should be explicitly
documented, rather than kept secret by the CA, or allowing the CA to give
conflicting answers to different relying parties on whether or not they'll
accept such messages.

[Dimitris Zacharopoulos]

On 2020-11-13 7:17 μ.μ., Ryan Sleevi wrote:
>
>
> On Fri, Nov 13, 2020 at 2:55 AM Dimitris Zacharopoulos
> <ji...@it.auth.gr <mailto:ji...@it.auth.gr>> wrote:
>
> There is transparency that the CA has evaluated some reporting
> mechanisms and these will be documented in the CPS. However, on an
> issue
> like compromised key reporting, there is no single recipe that covers
> all possible and secure ways for a third-part to report a key
> compromise.
>
>
> Sure, and the original proposed language doesn't restrict this.
>
> The CA can still disclose "Email us, and we'll work it out with you",
> and that's still better than the status quo today, and doesn't require
> the CP/CPS update you speculate about.

I understand the proposal to describe a different thing. Your proposal
to accept an email, is a different requirement, which is "how to
communicate". I think the policy change proposal is to describe the
details about what is expected from third-parties to submit in order to
report a key compromise. Whether via email, web form or other means, I
think this policy update covers *what* is expected to be submitted (e.g.
via CSR, signed plain text, the actual private key).

> For CAs that want to do the right thing with this flexibility, the
> original language Ben proposed seems to be problematic, which is
> why I
> highlighted it in the discussion.
>
>
> As above
>
> The updated language keeps all the
> "good" things from the original language, and allows the CA to
> accept a
> reporting method that they may have not considered. Obviously, the
> logical thing is that once this new method is accepted, the CPS
> should
> be updated to include that additional method but that might take
> place
> later, after the report was accepted and certificates revoked.
>
> I can't think of a bad scenario with this added language.
>
>
> I addressed this in my reply to Nick, but for your benefit, the "bad"
> thing here is a CA that lists, in their CP/CPS, "We will only accept
> using our convoluted API that requires you to submit on the lunar
> equinox", and then states "Well, that's just the minimum, we have this
> doc over here saying we'll also consider X, Y, Z".
>
> The modified language fully allows that. The original language would
> see methods X, Y, Z also added to the CP/CPS.

I think one of us has misunderstood the policy update proposal. I
believe that what you describe is already covered by the existing policy
which states that the CA must disclose *how* they accept requests (via
email, API, web form, etc), disclosed in CPS section 1.5.2.

> This makes no sense to me. We're not discussing secrets here. Say a
> third party reports a key compromise by sending a signed plaintext
> message, and the CA has only indicated as accepting a CSR with a
> specific string in the CN field. The updated proposal would allow
> the CA
> to evaluate this "undocumented" (in the CPS) reporting method,
> check for
> its credibility/accuracy and proceed with accepting it or not.
>
>
> The original proposal also allows this, by saying exactly what you
> stated here, but within the CP/CPS.
> The modified proposal, however, keeps secret whether or not the CA has
> a policy to unconditionally reject such messages.
>
> You seem to be thinking the original proposal prevents any discretion;
> it doesn't. I'm trying to argue that such discretion should be
> explicitly documented, rather than kept secret by the CA, or allowing
> the CA to give conflicting answers to different relying parties on
> whether or not they'll accept such messages.

If people consider that the original language is unambiguous and will
prevent an auditor to interpret this as "you have stated specific
technical method(s) for a third-party to demonstrate a key compromise,
therefore these are the only methods you must accept otherwise you are
violating your CP/CPS", then I'm fine.


Dimitris.

[Nick Lamb]

On Fri, 13 Nov 2020 12:11:57 -0500

Ryan Sleevi via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> I want it to be explicit whether or not a CA is making a restrictive
> set or not. That is, it should be clear if a CA is saying "We will
> only accept these specific methods" or if the CA is saying "We will
> accept these methods, plus any method at our discretion".

I see this as essentially redundant. Any major CA which does not choose
"We will accept ... any method at our discretion" under your formulation
stands to be humiliated repeatedly until they revise their policies to
say so as I explained previously.

I guess the existence of resulting let's call it "Sleevi boilerplate" is
harmless, but it seems foolish for Mozilla to demand people write
boilerplate that doesn't achieve anything.

> I encourage you to make use of PACER/RECAP then.

I examined 7 pages of RECAP results for "Key Compromise". Most of them
meant this phrase in the sense of "important settlement of differences"
but some were cryptography related.

Here is what I found:

There were verbatim copies of RFCs 2459 and 3281 submitted as evidence
to a patent case that ends up involving Acer, Microsoft and others.

Another case submitted as evidence the ISRG CPS. It's a Lanham Act case
roughly along lines Let's Encrypt followers will be familiar with, the
plaintiff wants a certificate revoked, Let's Encrypt says they just
issue certificates for DNS names, have the court take the DNS name away
if that's the issue. Not relevant here.

And finally there's an EFF Amicus briefing which says basically key
compromise is bad, which everybody here already knew.



I found no evidence that there are in fact such "secret documents" and
no evidence there's a problem here that would or could be fixed by your
preferred language for this Mozilla policy.

If you have a _much_ more specific claim than just "Somebody has
mentioned it in court at some point" then please make it.


Nick.

[Ryan Sleevi]

Right, I can see by my failing to explicitly state you were
misunderstanding my position in both parts of your previous mail, you may
have believed you correctly understood it, and not picked up on all of my
reply.

To be very clear: "secret" document is not what you described, as a way for
a CA to hide nefariousness. In the context of this issue, I'm talking about
"secret" as in not part of the public commitments that can be examined via
the CP/CPS, and that are visibility, transparently part of the audit. These
are the "internal" documents that may or may not be audited (depending on
the audit scheme and the auditor's interpretation; ETSI is less transparent
here, but I'm sure they'll insist it's somehow the same). Think your
training manuals, your internal policies for incident management, your
policies on escalation or interpretations of the BRs (such as jurisdiction
requirements), etc. They are things that are conceptually and logically
part of a CA, and part of how a CA operates, but they aren't part of the
externally documented set. Or, they might not be explicitly linked to some
audit criterion that requires examining then; for example, change control
management would be, but policies around lunch and break times are unlikely
to be.

My point is to bring them "into the CP/CPS". As I mentioned in my previous
e-mail, although I can understand you might be confused because I did not
clearly state I disagreed with you, the point is to make it explicit
whether or not a CA is stating that they will *reject* anything they don't
like. If a CA says "I accept X, Y, Z", and you send them "A", and they say
"Sorry, we said we don't accept A, you decided to trust us anyway, boo hoo
for you", they're not entirely wrong. That's exactly what audits and
CP/CPSes are designed to make explicit. If the CA says "We accept X, Y, Z,
and any other method", then if someone sends them "A", there's a
presumption here of acceptance. If the CA decides to reject it then, they
bear the burden and presumption of explaining their discretion, especially
if it turns out to be a valid issue. Here, the presumption is on the CA to
demonstrate why their judgement and discretion is trustworthy, knowing that
if they rejected A without good cause, they will be viewed negatively.
Equally, we can decide whether the new policy should ACTUALLY be "We accept
X, Y, Z, A, and any other method" - making it clear the new minimum set.

However, while you think it redundant, it actually provides a number of
important details for CP/CPS reviews. For example, were a CA to omit "any
method", it easily raises a red flag to ask a follow-up. We see these sorts
of omissions all the time in CP/CPS reviews, particularly around domain
validation methods (3.2.2.4). So we'll ask during the review, and the CA
will say, "well, we go into more detail in this other document. Our
auditors looked at it, and agreed it met the requirements, but we didn't
put it in our CP/CPS". Now, the problem with accepting that answer is that
you don't know whether or not they actually did go into that detail in the
other document - we don't have it, and would have to ask for it. You can
see this playing out in Incident Reports today, where we'll ask a CA to
attach the old and new document (such as a training document, an
architectural layout, a testing matrix), where we try to understand what's
changing. However, we also don't know whether or not the auditor looked at
that document as well; the CA's version of the audit report would show
this, but the one we see does not.

The benefit here is that by getting it into the CP/CPS, it clearly becomes
part of the audit. It also becomes part of the CA's public commitments, and
then we can see if they're changing operational behavior midstream. Either
they updated their CP/CPS, and we see that they did in fact go through a
change, or they changed behavior and didn't update their CP/CPS, which will
get flagged in the audit. Both ways, we, the community, end up learning
that something changed, and can review that change to make sure that change
is aligned with what we want.

Yes, you're absolutely correct that I want to make sure a CA says "any
method at our discretion", but it's not about humiliation, nor is it
redundant. It serves a valuable purpose for reducing the risk of arbitrary,
undesirable rejections, while effectively improving transparency and
auditability.

On Fri, Nov 13, 2020 at 8:12 PM Nick Lamb <n...@tlrmx.org> wrote:

> On Fri, 13 Nov 2020 12:11:57 -0500
> Ryan Sleevi via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
> > I want it to be explicit whether or not a CA is making a restrictive
> > set or not. That is, it should be clear if a CA is saying "We will
> > only accept these specific methods" or if the CA is saying "We will
> > accept these methods, plus any method at our discretion".
>
> I see this as essentially redundant. Any major CA which does not choose
> "We will accept ... any method at our discretion" under your formulation
> stands to be humiliated repeatedly until they revise their policies to
> say so as I explained previously.
>
> I guess the existence of resulting let's call it "Sleevi boilerplate" is
> harmless, but it seems foolish for Mozilla to demand people write
> boilerplate that doesn't achieve anything.
>
> > I encourage you to make use of PACER/RECAP then.
>
> I examined 7 pages of RECAP results for "Key Compromise". Most of them
> meant this phrase in the sense of "important settlement of differences"
> but some were cryptography related.

While your original premise that I was arguing for "secret" documents as a
means to force potentially illegitimate revocations, which my previous mail
went into detail about how that was flawed, I can see by replying here, you
thought I was agreeing.

But equally, I made the mistake for referring to PACER/RECAP without
clarifying more. My reply was to address that yes, there is the existence
of "potentially illegitimate revocations", but that it's not tied to
"secret" documents (which you misunderstood). And my mistake in not
clarifying was that the cases weren't addressed to the CA, but related to a
CA subscriber. You can read more about this at
https://www.techdirt.com/articles/20180506/13013839781/more-copyright-holders-move-up-stack-more-they-put-everyone-risk.shtml
Here, this is about revocations that harm security, more than help, and you
can read from that post more about why that's undesirable at
https://medium.com/@mattholt/will-certificate-authorities-become-targets-for-dmca-takedowns-7d111275897a

Hope that helps clarify for you.

[Ryan Sleevi]

On Fri, Nov 13, 2020 at 6:11 PM Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:

>
>
> On 2020-11-13 7:17 μ.μ., Ryan Sleevi wrote:
>
>
>
> On Fri, Nov 13, 2020 at 2:55 AM Dimitris Zacharopoulos <ji...@it.auth.gr>

> wrote:
>
>> There is transparency that the CA has evaluated some reporting
>> mechanisms and these will be documented in the CPS. However, on an issue
>> like compromised key reporting, there is no single recipe that covers
>> all possible and secure ways for a third-part to report a key
>> compromise.
>
>
> Sure, and the original proposed language doesn't restrict this.
>
> The CA can still disclose "Email us, and we'll work it out with you", and
> that's still better than the status quo today, and doesn't require the
> CP/CPS update you speculate about.
>
>
> I understand the proposal to describe a different thing. Your proposal to
> accept an email, is a different requirement, which is "how to communicate".
> I think the policy change proposal is to describe the details about what is
> expected from third-parties to submit in order to report a key compromise.
> Whether via email, web form or other means, I think this policy update
> covers *what* is expected to be submitted (e.g. via CSR, signed plain text,
> the actual private key).
>

Right, and that is what I meant as well. My point was the "we'll work it
out with you" being about explicitly stating an *open-ended what*, while
discouraging CAs, by making it detectable during CP/CPS reviews, of
intentionally choosing to *reject* any what they don't like. If a CA
doesn't state an open-ended what, it could mean that their plan is to do
exactly that, which would be bad, or it could just mean they forgot, which
is easily fixed, but also a warning sign.

>
> I addressed this in my reply to Nick, but for your benefit, the "bad"
> thing here is a CA that lists, in their CP/CPS, "We will only accept using
> our convoluted API that requires you to submit on the lunar equinox", and
> then states "Well, that's just the minimum, we have this doc over here
> saying we'll also consider X, Y, Z".
>
> The modified language fully allows that. The original language would see
> methods X, Y, Z also added to the CP/CPS.
>
>
> I think one of us has misunderstood the policy update proposal. I believe
> that what you describe is already covered by the existing policy which
> states that the CA must disclose *how* they accept requests (via email,
> API, web form, etc), disclosed in CPS section 1.5.2.
>

No, I think like above, I may have chosen an unclear example, but I think
we understand it the same. "Convoluted API ... at the lunar equinox" was
trying to cover both the how it's delivered and the method of proving it,
but I can totally see now that it might be perceived as just the how it's
delivered, which wasn't the intent.

I'm talking about the "what method of demonstrating proof is accepted".
That covers both the how it's delivered and how it's demonstrated, and as I
went into further with Nick, my goal is to make sure "X, Y, Z" are listed
in the CPS, and not some side-doc that may or may not be audited and may or
may not be disclosed. The problem with the "minimum" approach is that it
doesn't adequately make clear that the "listed in a side doc" is one of the
several problems to be solved, with the goal being to bring it into the
CP/CPS. Having just the minimum required would still encourage CAs that go
above and beyond the minimum to put it off in a side doc, when the goal is
to get it into the CP/CPS, for reasons I expanded on to Nick.

I think you took it as discouraging a CA to go "above and beyond the bare
minimum", which I agree with you, that would be bad to discourage. But I
want CAs to be clear when they do go above and beyond the minimum, and to
be clear that they also recognize it's important to do so, since the
minimum is just that: the minimum. The minimum isn't meant to be "This is
how you should operate daily", but the "You should be better than this
regularly, but you absolutely cannot regress this threshold", and having
CAs explicitly state that they expect to constantly be improving (by
accepting other methods), helps show they understand that, as I think
you're arguing for here.

> This makes no sense to me. We're not discussing secrets here. Say a
>> third party reports a key compromise by sending a signed plaintext
>> message, and the CA has only indicated as accepting a CSR with a
>> specific string in the CN field. The updated proposal would allow the CA
>> to evaluate this "undocumented" (in the CPS) reporting method, check for
>> its credibility/accuracy and proceed with accepting it or not.
>>
>
> The original proposal also allows this, by saying exactly what you stated
> here, but within the CP/CPS.
> The modified proposal, however, keeps secret whether or not the CA has a
> policy to unconditionally reject such messages.
>
> You seem to be thinking the original proposal prevents any discretion; it
> doesn't. I'm trying to argue that such discretion should be explicitly
> documented, rather than kept secret by the CA, or allowing the CA to give
> conflicting answers to different relying parties on whether or not they'll
> accept such messages.
>
>
> If people consider that the original language is unambiguous and will
> prevent an auditor to interpret this as "you have stated specific technical
> method(s) for a third-party to demonstrate a key compromise, therefore
> these are the only methods you must accept otherwise you are violating your
> CP/CPS", then I'm fine.
>

Yes, I agree with you, we want to prevent that scenario.

I believe it's possible to do, with the original language, but this
requires the CA to proactively take steps to address that in their CP/CPS.
That is, I think it'd be reasonable for an auditor to conclude that, if a
CA stated "We do X, Y, Z" in our CP/CPS, then doing "A, B, or C" without it
being listed in their CP/CPS first would be an issue. I believe that is the
concern you're raising, if I understood you correctly.

The way to address that, and what I think is a good goal, is to get it to
be "We do X, Y, Z, and any other method", ideally, when CAs make the update
in response to the new policy. As situations come up on a case by case
basis, the CA can deal with the issue without any update required first. If
any CA updates their CP/CPS without also adding "and any other method" in
response to the new policy, we can then clarify whether they're
intentionally stating they'll reject anything, or whether it was an
oversight, and like you, they want extra flexibility because they want to
go "above and beyond" as needed.

However, I also want to make sure that any formally accepted method of
proof is documented in the CP/CPS. So if the CA formalizes A and B as
routine operations, they will update their CP/CPS to state "We do X, Y, Z,
A, B, and any other method". This makes it clear which are the guaranteed
methods they promise to accept, as well as that exceptions are recognized
as necessary, and they will be accepted and dealt with.

I'm not trying to require every CA do A and B, but my worry with Ben's
modified language is that a CA will decide to accept A and B as a general
rule, but not ever add that to their CP/CPS, since the policy would
explicitly allow/encourage this scenario. While this is more likely
accidental than a sign of nefarious intent, it happens enough for me to be
wary about something being seen as encouraging it. By having *one* place
for a CA to document *everything* they do or plan to do, specifically their
CP/CPS, it makes it easier to review the CA and what they claim to do.
Additionally, it makes it easier to recognize when a CA is going above and
beyond, by highlighting when one CA only does X, Y, Z, while another does
X, Y, Z, A, and B. CAs should totally be looking at eachother's CP/CPSes
and trying to learn about good ideas, whether things like validation or, in
this case, compromise handling. We already see this with incident reports
being valuable information sharing for the industry, like Entrust's recent
report about customer's attaching private keys to CSRs, and CP/CPSes should
equally be a source of good practices for the industry.

Thus, this helps up evaluable which CAs are being industry leaders and
doing good things, and which are just trying to skate by with the minimum.
>From those leaders, we can learn about good new methods, like A and B, and
we can look to require them for all CAs. So it's wins all around, but we
only get their by making sure it's in the CP/CPS.

And yes, I do acknowledge there's a risk that if CA Foo does X, Y, Z, A and
B, while CA Bar does X, Y, Z only, then Foo might be tempted to *stop*
doing A and B to cut costs. But I think we still have enough CAs that are
truly motivated by being pro-security, rather than trying to cut costs,
that even if some CAs are tempted to be lazy and as cheap as possible,
there will be positive model CAs next to them, and the comparison
would highlight who is a "good" CA and who is a "bad" CA.

[Nick Lamb]

On Fri, 13 Nov 2020 21:06:30 -0500

Ryan Sleevi via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> Right, I can see by my failing to explicitly state you were
> misunderstanding my position in both parts of your previous mail, you
> may have believed you correctly understood it, and not picked up on
> all of my reply.

To the extent your preferred policy is actually even about issue #205
(see later) it's not really addressing the actual problem we have,
whereas the original proposed language does that.

> Yes, you're absolutely correct that I want to make sure a CA says "any
> method at our discretion", but it's not about humiliation, nor is it
> redundant. It serves a valuable purpose for reducing the risk of
> arbitrary, undesirable rejections, while effectively improving
> transparency and auditability.

This boilerplate does not actually achieve any of those things, and
you've offered no evidence that it could do so. If anything it
encourages CAs *not* to actually offer what we wanted: a clearly
documented but secure way to submit acceptable proof of key compromise.
Why not? It will be easier to write only "Any method at our discretion"
to fulfil this requirement and nothing more, boilerplate which
apparently makes you happy but doesn't help the ecosystem.

> But equally, I made the mistake for referring to PACER/RECAP without
> clarifying more. My reply was to address that yes, there is the
> existence of "potentially illegitimate revocations", but that it's
> not tied to "secret" documents (which you misunderstood). And my
> mistake in not clarifying was that the cases weren't addressed to the
> CA, but related to a CA subscriber. You can read more about this at
> https://www.techdirt.com/articles/20180506/13013839781/more-copyright-holders-move-up-stack-more-they-put-everyone-risk.shtml

> Here, this is about revocations that harm security, more than help,
> and you can read from that post more about why that's undesirable at
> https://medium.com/@mattholt/will-certificate-authorities-become-targets-for-dmca-takedowns-7d111275897a

We're in the discussion about issue #205 which is about proving _key
compromise_

If you believe Mozilla should write policies requiring CAs to resist
certain types of legal action this ought to be a separate issue. I
might even have positive things to say about that issue, and perhaps
some CA participants do too.

I was not able to discover what revocation reason was actually used in
the incident referenced, do you have copies of the signed OCSP response
or CRLs related to the Sci Hub revocations or similar incidents?

Otherwise I have to assume Key Compromise was not given as the reason
for these revocations and so this has nothing whatsoever to do with
issue #205 and you've hijacked an unrelated discussion.

Nick.

[Ryan Sleevi]

On Sat, Nov 14, 2020 at 4:42 PM Nick Lamb <n...@tlrmx.org> wrote:

> To the extent your preferred policy is actually even about issue #205
> (see later) it's not really addressing the actual problem we have,
> whereas the original proposed language does that.
>

I don't entirely appreciate being told that I don't know what I'm talking
about, which is how this reply comes across, but as I've stated several
times, the _original_ language is sufficient here, it's the modified
language that's problematic.

> > Yes, you're absolutely correct that I want to make sure a CA says "any
> > method at our discretion", but it's not about humiliation, nor is it
> > redundant. It serves a valuable purpose for reducing the risk of
> > arbitrary, undesirable rejections, while effectively improving
> > transparency and auditability.
>
> This boilerplate does not actually achieve any of those things, and
> you've offered no evidence that it could do so.

Perhaps you and I see evidence as different things. Could you help share
your knowledge of the audit reports and the auditing profession, to help
explain what evidence would be helpful here.

I think this reply is trying to capture that either you don't understand
how it's relevant, or you disagree, but I think it's more useful if you
explain why or how you believe it doesn't achieve these things. I've tried
to do you the same courtesy, by demonstrating how it does, but I can't tell
by such a dismissive reply if you're disagreeing (and if so, why), or if
you simply don't understand and would like to learn more.

> If anything it encourages CAs *not* to actually offer what we wanted: a
> clearly
> documented but secure way to submit acceptable proof of key compromise.
>

Again, this isn't the case, and I very much demonstrated why it wasn't in
my previous message with respect to CP/CPS reviews. You have to do more
than just saying "No", otherwise that just comes across as petulance.

> Why not? It will be easier to write only "Any method at our discretion"
> to fulfil this requirement and nothing more, boilerplate which
> apparently makes you happy but doesn't help the ecosystem.
>

The problem with this statement is that it directly contradicts what I
wrote in the message you're replying to. You're making a strawman here, and
I already demonstrated to you precisely why, and how, it allows us to go
from nothing to X, Y, Z and then further on to A, B. You're description of
what "makes me happy" is literally the opposite of what I said, which is
why I'm concerned that you may not understand my previous message, or how
this works. I'm happy to help clarify further, but I think you need to
elaborate more here so we can clear up the confusion. I'm sure it's equally
unfulfilling to hear me keep telling you you're wrong, so if you're finding
you're unsure of what I meant, I'm happy to answer questions, rather than
have to respond to incorrect statements.

Again, so that it's (hopefully) clear for you, my expression is to support
the original language, and that the modified language introduces weaknesses
that the original language doesn't.

> > But equally, I made the mistake for referring to PACER/RECAP without
> > clarifying more. My reply was to address that yes, there is the
> > existence of "potentially illegitimate revocations", but that it's
> > not tied to "secret" documents (which you misunderstood). And my
> > mistake in not clarifying was that the cases weren't addressed to the
> > CA, but related to a CA subscriber. You can read more about this at
> >
> https://www.techdirt.com/articles/20180506/13013839781/more-copyright-holders-move-up-stack-more-they-put-everyone-risk.shtml
>
> > Here, this is about revocations that harm security, more than help,
> > and you can read from that post more about why that's undesirable at
> >
> https://medium.com/@mattholt/will-certificate-authorities-become-targets-for-dmca-takedowns-7d111275897a
>
> We're in the discussion about issue #205 which is about proving _key
> compromise_

*sigh* So you've move the goal post in your reply, and when I make a good
faith engagement, you try to chide me about moving goalposts. You
introduced the notion of "potentially illegitimate revocations" as a
misunderstanding of what I said. In my reply, I clarified to you that they
are a thing, which you were dismissive of, and also clarified that you were
misunderstanding my point. You were further confused by the reply, and how
you want to chide me for clarifying for you why what you said was wrong.
Yes, you're absolutely correct that you introduced something offtopic, and
by replying to you, I let the conversation continue to be offtopic.

So, perhaps now that we've had this conversation, and you've learned about
potentially illegitimate revocations are a thing, but that they were not
the thing I was worrying about and that you'd misunderstood, perhaps we can
move back to the substantive discussion?

[Peter Bowen]

On Sat, Nov 14, 2020 at 2:05 PM Ryan Sleevi via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
>
> So, perhaps now that we've had this conversation, and you've learned about
> potentially illegitimate revocations are a thing, but that they were not
> the thing I was worrying about and that you'd misunderstood, perhaps we can
> move back to the substantive discussion?

Going back to earlier posts, it seems like CAs could include a
statement in their CPS separate from key compromise that they may
revoke a certificate at any time for any reason or no reason at their
sole discretion. That would allow the CA to choose to accept proofs
of key compromise that are not listed in the CPS based on their
internal risk methodologies, correct? It does still have the "secret
document" issue, but moves it away from key compromise and makes it
clear and transparent to subscribers and relying parties. This means
the CA could revoke the subscriber certificate because they have an
internal procedure that they roll a bunch of D16 and revoke any
certificate with a serial number that matches the result. Or the CA
could revoke the certificate because they got a claim that the key in
the certificate is compromised but it came in a form not explicitly
called out, so they had to use their own judgement on whether to
revoke.

Thanks,
Peter

[Ryan Sleevi]

The reply was to me, but it sounds like your proposal was to address
Dimitris' concerns, not mine. Is that correct?

As I mentioned when trying to clarify my reply to Nick, the reason I think
the originally proposed language works, in a way that the modified proposal
does not, is that what you describe conflates the "we decide to revoke"
(the D16, in your example) with the "You gave us some details and we should
have revoked on that basis". That's a valuable property to have, by making
sure it's unambiguous whether they're explicitly limiting the methods of
key compromise, or not.

The goal is, and has been, the same, to make sure that CAs are not setting
an onerous burden on the community to report key compromise, while also
providing guidance to the community on how the CA will reasonably take
action on reports of key compromise, including those that aren't "perfect"
matches to one of the methods.

If I understand Dimitris' concern correctly, it was about ensuring CAs had
flexibility for discretion, and your language supports that discretion.
However, as you note, it still has the issue with non public documents, in
the best case, or it leaves it ambiguous whether the CA is affirmatively
stating they will *reject* any report of key compromise that doesn't
exactly follow their methodology.

I believe Ben's original language (
https://github.com/BenWilson-Mozilla/pkipolicy/commit/719b834689949e869a0bd94f7bacb8dde0ccc9e4
) supports that, by both expecting CAs to define some set of explicit
methods (which was, I believe, Nick's original concern, if I've
understood), while also allowing them to state that they won't reject
reports outright, by disclosing they'll accept additional methods (which is
my concern). This disclosure also addresses Dimitris' concern, because it
allows the CA to accept other methods as needed, but sets the expectation
that the CP/CPS is the canonical place to document the methods you do
accept.

[Matt Palmer]

On Sat, Nov 14, 2020 at 09:42:48PM +0000, Nick Lamb via dev-security-policy wrote:
> This boilerplate does not actually achieve any of those things, and

> you've offered no evidence that it could do so. If anything it

> encourages CAs *not* to actually offer what we wanted: a clearly
> documented but secure way to submit acceptable proof of key compromise.

> Why not? It will be easier to write only "Any method at our discretion"
> to fulfil this requirement and nothing more, boilerplate which
> apparently makes you happy but doesn't help the ecosystem.

Whilst it wouldn't make me *happy* to see such boilerplate, it would at
least serve to make it clear which CAs were just painting by numbers, as
opposed to those which understand their own operations and are willing to
meaningfully document them. It would also serve as a suitable jumping-off
point for a discussion amongst trust stores (well, Mozilla at least) when a
key compromise revocation request is rejected by a CA as to how good, bad,
or otherwise a CA's discretion is.

- Matt

[Nick Lamb]

On Sat, 14 Nov 2020 17:05:26 -0500
Ryan Sleevi <ry...@sleevi.com> wrote:

> I don't entirely appreciate being told that I don't know what I'm
> talking about, which is how this reply comes across, but as I've
> stated several times, the _original_ language is sufficient here,
> it's the modified language that's problematic.

That part of my statement was erroneous - of the actual texts I've seen
proposed so far I prefer this amended proposal from Ben:

"Section 4.9.12 of a CA's CP/CPS MUST clearly specify its accepted
methods that Subscribers, Relying Parties, Application Software
Suppliers, and other third parties may use to demonstrate private key
compromise. A CA MAY allow additional, alternative methods that do not
appear in section 4.9.12 of its CP/CPS."

I can't tell from here whether you know what you're talking about, only
whether I know what you're talking about, and I confess after some
effort I don't believe I was getting any closer.

Still, I believe this language can be further improved to achieve the
goals of #205. How about:

"Section 4.9.12 of a CA's CP/CPS MUST clearly specify one or more

accepted methods that Subscribers, Relying Parties, Application Software
Suppliers, and other third parties may use to demonstrate private key
compromise. A CA MAY allow additional, alternative methods that do not
appear in section 4.9.12 of its CP/CPS."

This makes clear that the CA must have at least one of these "clearly
specified" accepted methods which ought to actually help Matt get some
traction.

Nick.

[Dimitris Zacharopoulos]

On 2020-11-14 5:01 π.μ., Ryan Sleevi wrote:
> I believe it's possible to do, with the original language, but this
> requires the CA to proactively take steps to address that in their
> CP/CPS. That is, I think it'd be reasonable for an auditor to conclude
> that, if a CA stated "We do X, Y, Z" in our CP/CPS, then doing "A, B,
> or C" without it being listed in their CP/CPS first would be an issue.
> I believe that is the concern you're raising, if I understood you
> correctly.

Exactly, and the first proposed language by Ben, doesn't seem to allow
the CA to include language to support "and any other method". This is
not like the Domain or IP Address Validation methods where "any other
method" was considered a bad thing. This is a case where we should
welcome additional acceptable methods for third-parties to demonstrate
their control of compromised keys.

>
> The way to address that, and what I think is a good goal, is to get it
> to be "We do X, Y, Z, and any other method", ideally, when CAs make
> the update in response to the new policy. As situations come up on a
> case by case basis, the CA can deal with the issue without any update
> required first. If any CA updates their CP/CPS without also adding
> "and any other method" in response to the new policy, we can then
> clarify whether they're intentionally stating they'll reject anything,
> or whether it was an oversight, and like you, they want extra
> flexibility because they want to go "above and beyond" as needed.
>
> However, I also want to make sure that any formally accepted method of
> proof is documented in the CP/CPS. So if the CA formalizes A and B as
> routine operations, they will update their CP/CPS to state "We do X,
> Y, Z, A, B, and any other method". This makes it clear which are the
> guaranteed methods they promise to accept, as well as that exceptions
> are recognized as necessary, and they will be accepted and dealt with.

I think we're in agreement here, and I already stated that in a previous
reply.

"For CAs that want to do the right thing with this flexibility, the
original language Ben proposed seems to be problematic, which is why I

highlighted it in the discussion. The updated language keeps all the

"good" things from the original language, and allows the CA to accept a
reporting method that they may have not considered. Obviously, the
logical thing is that once this new method is accepted, the CPS should
be updated to include that additional method but that might take place
later, after the report was accepted and certificates revoked."

We could make the language even stricter so that if a CA accepts new
methods to demonstrate key compromise not mentioned in their CPS, they
should include the details of these new methods in an upcoming CPS
update (although I consider this redundant because this is IMO the
normal way of doing things). Since CAs are required to perform this
update task at least once a year, this information will eventually end
up in their CPS.

I will reply to Peter's post separately why I think invoking that
particular revocation reason is IMO not such a good idea.


Dimitris.

[Dimitris Zacharopoulos]

On 2020-11-15 1:04 π.μ., Peter Bowen via dev-security-policy wrote:
> On Sat, Nov 14, 2020 at 2:05 PM Ryan Sleevi via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>> So, perhaps now that we've had this conversation, and you've learned about
>> potentially illegitimate revocations are a thing, but that they were not
>> the thing I was worrying about and that you'd misunderstood, perhaps we can
>> move back to the substantive discussion?
> Going back to earlier posts, it seems like CAs could include a
> statement in their CPS separate from key compromise that they may
> revoke a certificate at any time for any reason or no reason at their
> sole discretion. That would allow the CA to choose to accept proofs
> of key compromise that are not listed in the CPS based on their
> internal risk methodologies, correct? It does still have the "secret
> document" issue, but moves it away from key compromise and makes it
> clear and transparent to subscribers and relying parties. This means
> the CA could revoke the subscriber certificate because they have an
> internal procedure that they roll a bunch of D16 and revoke any
> certificate with a serial number that matches the result. Or the CA
> could revoke the certificate because they got a claim that the key in
> the certificate is compromised but it came in a form not explicitly
> called out, so they had to use their own judgement on whether to
> revoke.
>

> Thanks,
> Peter

Thanks for chiming-in Peter,

I have always considered this revocation reason as the absolutely "last
resort" for CAs when it comes to revocation of Certificates. Especially
for the revocation of end-entity Certificates for which there is a
Subscriber Agreement attached, if the CA cannot properly justify the
revocation based on other documented reasons that Subscribers can
understand and be prepared for, it seems like a process failure and a
possible reason for Subscribers to move against the CA. Much like the
invocation of 9.16.3 should be avoided as much as possible, I believe
the same applies for relying on such very wide unbound CPS statements.

Dimitris.

[Ryan Sleevi]

I can tell we're not making any progress here, as this doesn't really
address the concerns I've highlighted twice. This would be a regression
from the proposed language, and would be a further regression from the
original language here.

[Ryan Sleevi]

On Sun, Nov 15, 2020 at 6:02 AM Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:

>
>

Isn't this the "different problem" that Nick was raising concerns about?

That is, your reply here, talking about revocation for reasons outside of
the Subscriber Agreement, sounds even further afield than Issue 205. Am I
missing something on how it connects here?

[Matt Palmer]

On Sun, Nov 15, 2020 at 04:52:38AM +0000, Nick Lamb via dev-security-policy wrote:
> This makes clear that the CA must have at least one of these "clearly
> specified" accepted methods which ought to actually help Matt get some
> traction.

I doubt it. So far, every CA that's decided to come up with their own
method of proving key compromise has produced something entirely proprietary
to themselves. I have no reason to believe that, absent method stipulation
from a trust store, that we won't end up with different,
mutually-incompatible, unworkable methods for demonstrating key compromise
equal to (or, just as likely, exceeding) the number of participating CA
organisations.

Of course, the current way in which key compromise evidence is fracturing
into teeny-tiny incompatible shards is, for my purposes, a significant
*regression* from the current state of the art. Currently, I can e-mail a
(link to a) generic but obviously-not-for-a-certificate CSR containing and
signed by the compromised key, and it gets revoked. No CA has yet to come
back to me and say "we can't accept this as evidence of key compromise".

This format allows the pre-generation of compromise attestations, so that I
don't need to keep a couple of million (ayup, there's a lot of keys out
there) private keys online-accessible 24x7 to generate a real-time
compromise attestation in whatever hare-brained scheme the affected CA has
come up with -- not to mention the entertainment value of writing code to
generate the compromise attestations for each of those schemes.

In an attempt to keep the madness under some sort of control, I've tried to
codify my thoughts around best practices in a pre-draft RFC
(https://github.com/pwnedkeys/key-compromise-attestation-rfc) but so far it
doesn't look like anyone's interested in it, and every time I think "oh, I
should probably just go and submit it as an Experiment through the IETF
individual stream and see what happens" the datatracker's not accepting
submissions.

- Matt

[Nick Lamb]

On Mon, 16 Nov 2020 10:13:16 +1100
Matt Palmer via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:
> I doubt it. So far, every CA that's decided to come up with their own
> method of proving key compromise has produced something entirely
> proprietary to themselves.

At least two CAs (and from what I can tell likely more) offer ACME APIs
and thus ACME key compromise revocation (RFC 8555 section 7.6)

The server MUST also consider a revocation request valid if it is
signed with the private key corresponding to the public key in the
certificate.

I appreciate that this is less convenient to your preferred method of
working, but it doesn't seem proprietary to agree on a standard way to
do something and my impression was that you could talk to ACME now?

> I have no reason to believe that, absent
> method stipulation from a trust store, that we won't end up with
> different, mutually-incompatible, unworkable methods for
> demonstrating key compromise equal to (or, just as likely, exceeding)
> the number of participating CA organisations.

OK, so in your opinion the way forward on #205 is for Mozilla policy to
mandate acceptance of specific methods rather than allowing the CA to
pick? Or at least, to require them to pick from a small set?

> Of course, the current way in which key compromise evidence is
> fracturing into teeny-tiny incompatible shards is, for my purposes, a
> significant *regression* from the current state of the art.
> Currently, I can e-mail a (link to a) generic but
> obviously-not-for-a-certificate CSR containing and signed by the
> compromised key, and it gets revoked. No CA has yet to come back to
> me and say "we can't accept this as evidence of key compromise".

But your earlier postings on this subject suggest that this is far from
the whole story on what happens, not least because you sometimes weren't
immediately able to figure out where to email that CSR to anyway or the
responses, though not "we can't accept this" were... far from ideal.

> This format allows the pre-generation of compromise attestations, so
> that I don't need to keep a couple of million (ayup, there's a lot of
> keys out there) private keys online-accessible 24x7 to generate a
> real-time compromise attestation in whatever hare-brained scheme the
> affected CA has come up with -- not to mention the entertainment
> value of writing code to generate the compromise attestations for
> each of those schemes.

Experience with other elements of CA operations suggests that CAs don't
like writing the other side of the code either, and so tend to coalesce
on a smaller number of implementations especially when there's no
opportunity to differentiate their product.

> In an attempt to keep the madness under some sort of control, I've
> tried to codify my thoughts around best practices in a pre-draft RFC
> (https://github.com/pwnedkeys/key-compromise-attestation-rfc) but so
> far it doesn't look like anyone's interested in it, and every time I
> think "oh, I should probably just go and submit it as an Experiment
> through the IETF individual stream and see what happens" the
> datatracker's not accepting submissions.

Well, it is IETF 109 now so yes, this isn't the right moment for new
drafts. My guess is that the closest match in terms of existing working
groups is probably either LAMPS - but that is only really chartered to
fix existing stuff, not explore new territory; or ACME - but ACME
already solved the key compromise revocation problem as far as they're
concerned. So, yes, individual submission is likely the way to go if
you want this published.

If expressions of interest are worth anything I can offer to read an
Internet Draft and provide feedback but you might not like my feedback.

For example the current text says:

"Given a valid signature, the subjectPKInfo in the CSR MUST be compared
against the subjectPublicKey info of the key(s) which are to be checked
for compromise."

But formats I've seen for keys (as opposed to certificates) do not
contain a "subjectPublicKey info" and so I guess what you actually want
to do here is compare the entire key. Explaining how to do that exactly
while being neutral about how that key might be stored will be
difficult, you might have to just pick a format.

Also is RFC 7169 really the best available poison extension for this
purpose? You understand it was intentionally published on April 1st
right?

Nick.

[Dimitris Zacharopoulos]

On 15/11/2020 9:44 μ.μ., Ryan Sleevi wrote:
>
> Thanks for chiming-in Peter,
>
> I have always considered this revocation reason as the absolutely
> "last
> resort" for CAs when it comes to revocation of Certificates.
> Especially
> for the revocation of end-entity Certificates for which there is a
> Subscriber Agreement attached, if the CA cannot properly justify the
> revocation based on other documented reasons that Subscribers can
> understand and be prepared for, it seems like a process failure and a
> possible reason for Subscribers to move against the CA. Much like the
> invocation of 9.16.3 should be avoided as much as possible, I believe
> the same applies for relying on such very wide unbound CPS statements.
>
>
> Isn't this the "different problem" that Nick was raising concerns about?
>
> That is, your reply here, talking about revocation for reasons outside
> of the Subscriber Agreement, sounds even further afield than Issue
> 205. Am I missing something on how it connects here?

If a CA already has a statement in its CP/CPS that the CA can revoke a
certificate at any time and with no justification, this is probably
already included in the Subscriber Agreement. I just wanted to highlight
that this is a very weak revocation reason that CAs should avoid as much
as possible. In any case, the fact that a CA can revoke for any reason
is not related to the #205 issue which is to document how a third-party
can prove that a key is compromised. The revocation reasons related to
key compromise can fully cover the justification for why a certificate
must be revoked.

We're trying to ensure that the Mozilla Policy language doesn't create a
situation where a CA is being presented with evidence that a key is
compromised, and this evidence is not inline with the documented
procedure of the CA's 4.9.12 (at that time), thus the proposal to add
broader language so a CA can accept other methods of demonstrating a key
compromise.

I think Nick supports the updated language from Ben, and I also support
Nick's updated version presented in
https://groups.google.com/g/mozilla.dev.security.policy/c/QQmhYW6kxSw/m/CKaRcl27AgAJ.

Just a reminder, I'm also happy with the original language (that you
support) in the MRSP, as long as it is clearly allowed for CAs to ADD
the broader language in 4.9.12 of their CPS to avoid "audit
misunderstandings" :)

Dimitris.

[Matt Palmer]

On Mon, Nov 16, 2020 at 02:17:37AM +0000, Nick Lamb wrote:
> On Mon, 16 Nov 2020 10:13:16 +1100
> Matt Palmer via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
> > I doubt it. So far, every CA that's decided to come up with their own
> > method of proving key compromise has produced something entirely
> > proprietary to themselves.
>
> At least two CAs (and from what I can tell likely more) offer ACME APIs

ACME isn't a CA's "own" method of proving key compromise, hence is not
covered by the above sentence.

> I appreciate that this is less convenient to your preferred method of
> working, but it doesn't seem proprietary to agree on a standard way to
> do something and my impression was that you could talk to ACME now?

Well, it's "less convenient" in the sense that I'd have to figure out how to
securely provide online access to several million private keys, which I
continue to believe is going to end up being a Really Really Bad Idea,
especially when there's such a simple alternate solution (just storing
appropriately-formed CSRs online). In any event, on the current evidence,
CAs are *not* universally going with "just use ACME", so it's something of a
moot point.

> > I have no reason to believe that, absent
> > method stipulation from a trust store, that we won't end up with
> > different, mutually-incompatible, unworkable methods for
> > demonstrating key compromise equal to (or, just as likely, exceeding)
> > the number of participating CA organisations.
>
> OK, so in your opinion the way forward on #205 is for Mozilla policy to
> mandate acceptance of specific methods rather than allowing the CA to
> pick? Or at least, to require them to pick from a small set?

Yes. The BRs' "any other method" of domain control validation provides a
useful historical analog for why I believe this is going to end in tears for
everyone.

> > Of course, the current way in which key compromise evidence is
> > fracturing into teeny-tiny incompatible shards is, for my purposes, a
> > significant *regression* from the current state of the art.
> > Currently, I can e-mail a (link to a) generic but
> > obviously-not-for-a-certificate CSR containing and signed by the
> > compromised key, and it gets revoked. No CA has yet to come back to
> > me and say "we can't accept this as evidence of key compromise".
>
> But your earlier postings on this subject suggest that this is far from
> the whole story on what happens, not least because you sometimes weren't
> immediately able to figure out where to email that CSR to anyway or the
> responses, though not "we can't accept this" were... far from ideal.

Yes, but those issues are not related to providing the evidence of
compromise, and hence not relevant to this discussion.

> If expressions of interest are worth anything I can offer to read an
> Internet Draft and provide feedback but you might not like my feedback.

Bring it on. Preferably with suggestions for alternate language.

> For example the current text says:
>
> "Given a valid signature, the subjectPKInfo in the CSR MUST be compared
> against the subjectPublicKey info of the key(s) which are to be checked
> for compromise."
>
> But formats I've seen for keys (as opposed to certificates) do not
> contain a "subjectPublicKey info" and so I guess what you actually want
> to do here is compare the entire key. Explaining how to do that exactly
> while being neutral about how that key might be stored will be
> difficult, you might have to just pick a format.

An SPKI can be constructed from any other form of the key material, and
(modulo the rather annoying compressed-vs-uncompressed issue with EC keys)
produces the Right Result in every situation I'm aware of (otherwise DER's
got some splainin' to do).

> Also is RFC 7169 really the best available poison extension for this
> purpose? You understand it was intentionally published on April 1st
> right?

Yes, I am aware of the date of publication of that RFC. What I'm not aware
of is anything that says that RFCs published on April 1st are banned from
being referenced elsewhere. It's a document that appears to suit the
purpose to which it is being used, hence I used it. It seems somewhat
wasteful of everyone's time to produce essentially the same document but
with a different publication date.

I'm also aware of the need for standards-track RFCs to not use Informational
or Experimental RFCs as normative references; in the exceedingly unlikely
event that my proposal were to end up on that track, 7169 would need to be
re-issued as a standards-track document as well, but that bridge can be
burned if we come to it.

- Matt