MRSP 6 and CPS 4.9.12 proof of key compromise compliance date

[Ben Wilson]

All,

This past April we published Mozilla’s Root Store Policy v. 2.7.1 (MRSP) with an effective date of May 1, 2021, knowing that there were new items for which CAs would need time to implement, and we sent out a CA survey to help us determine reasonable implementation timeframes for new requirements in the MRSP.  Specifically, in Item 7 of the CA Survey we asked CAs about the status of their compliance with a new provision in MRSP § 6 that states, “Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods that parties may use to demonstrate private key compromise.” One option we gave in the survey responses was a checkbox with the response “By the date specified below, we plan to publish a new version of our CPS that contains the methods that parties may use to demonstrate private key compromise.” CA Responses are located here: https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00140,Q00150,Q00148.

There were a range of responses, many CAs indicating that they could publish a new CPS by the end of May. However, we have not yet made announced a date by which we will expect all CAs to have updated their CPSes to meet this new requirement. This has lead to some confusion, e.g. Bug 1713976 was filed yesterday for Amazon’s CPS not having updated section 4.9.12 of its CPS, even though Amazon committed to do so by the end of June. Concern was raised in the bug that other dates proposed by CAs might be too far away.  At the suggestion of Ryan Sleevi, I’m opening discussion here on this issue.  Mainly, I’m requesting feedback on a date by which all CAs should be expected to have updated section 4.9.12 in their CPSes with methods that parties may use to demonstrate private key compromise. 

Thanks,

Ben

[Andrew Ayer]

On Thu, 3 Jun 2021 10:28:02 -0600
Ben Wilson <bwi...@mozilla.com> wrote:

> There were a range of responses, many CAs indicating that they could
> publish a new CPS by the end of May. However, we have not yet made
> announced a date by which we will expect all CAs to have updated their
> CPSes to meet this new requirement. This has lead to some confusion,
> e.g. Bug 1713976

> <https://bugzilla.mozilla.org/show_bug.cgi?id=1713976> was filed

> yesterday for Amazon's CPS not having updated section 4.9.12 of its
> CPS, even though Amazon committed to do so by the end of June.
> Concern was raised in the bug that other dates proposed by CAs might
> be too far away. At the suggestion of Ryan Sleevi, I'm opening
> discussion here on this issue. Mainly, I'm requesting feedback on a
> date by which all CAs should be expected to have updated section
> 4.9.12 in their CPSes with methods that parties may use to
> demonstrate private key compromise.

CAs were given 31 days notice
<https://groups.google.com/g/mozilla.dev.security.policy/c/ZGUuo0_JDUo>
of the new policy, and the discussion of this
particular policy change took place in November of last year
<https://groups.google.com/g/mozilla.dev.security.policy/c/QQmhYW6kxSw/m/DOfGapJDAwAJ>
on mozilla.dev.security.policy, which CAs are required to follow.
19 CAs answered that they would be compliant by the policy's stated
effective date, so it should have been possible for other CAs to comply
by it as well. Any CA which thinks this expectation is unreasonable
should have the burden of demonstrating why the extra time is necessary.

More generally, this approach to effective dates is flawed.
It creates confusion among relying parties because they can't
take the policy's stated effective date at face value, and it's
deeply unfair to the CAs which invest in compliance and become
compliant by a policy's stated effective date. If other CAs, which
invest less in compliance, get de facto automatic extensions to policy
changes, it creates a disincentive to invest in compliance, which runs
contrary to Mozilla's goals as stated in the CA Root Inclusion Factors
document <https://docs.google.com/document/d/1hU4rx59ANz_bwtsdTOTc4Q3SAh4IIgPdXJMB1BNt9SU/edit>.
For future policy changes, the appropriate length of the phase-in
period should be discussed on mozilla.dev.security.policy in an open
and transparent manner before the policy is published, and all CAs
should be held to the same effective date once the policy is published.

Note that the responses to item 9, about ALV errors
<https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a054o00000EL1Fo&QuestionId=Q00152,Q00155,Q00153>
are even more problematic. In particular, I'd like to draw attention to
Telia's response, which indicates that they are operating an unaudited,
unconstrained, intermediate and don't plan to do anything about it until
June 30. Has Mozilla granted Telia an exception to the requirement that
TLS-capable intermediates be audited, and that misissued intermediates
be revoked within 7 days?

Regards,
Andrew

[Ryan Sleevi]

Ben: Historically, Mozilla has provided explicit guidance on compliance dates (e.g. https://wiki.mozilla.org/CA:CertificatePolicyV2.2 ) if there are things not effective immediately.

I have to agree with Andrew here, it's quite surprising and a seeming deviation that Mozilla would either not give expected compliance dates, or allow the CA to define them as a result of the CA communication. The purpose of the discussion period is to understand if there are any concerns with the proposed compliance dates, and none seemed to be raised during the public discussion of the issues, so it's unclear why it would be different now.

That also seems consistent with https://wiki.mozilla.org/CA/Root_Store_Policy_Archive and explicitly calling out any special transitions.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20210603143036.ed04b6869bb889c9cfb54fed%40andrewayer.name.

[Ben Wilson]

Thanks for your comments, Andrew and Ryan.

The survey intended to gauge implementation timeframes for revisions to section 4.9.12 of CAs' CPSes, but we did not intend to allow CAs to define their own compliance dates. In the future, I'll be more careful to make sure that compliance dates are adequately communicated, discussed, and recorded before that version of the MRSP is finalized.

We are currently targeting July 31, 2021, as the date by which we CAs must revise section 4.9.12 of their CPSes. I am adding this date to https://wiki.mozilla.org/CA/Root_Store_Policy_Archive#2.7.1. I will also be reaching out to those CAs that indicated a later date, and I will inform them that they must comply by that date.

On the ALV issue (Item 9), we will also be communicating with the CAs listed in the CCADB that did not include intermediate certificates capable of issuing server certificates in their Standard or Baseline Requirements audits and telling them that they need to file an incident report. Although, note that some CAs did list their intermediate certificate SHA-256 fingerprints in audit statements, but ALV was unable to process them correctly. We are working to improve that situation through communication with CAs and auditors about the formatting of audit letters.

Sincerely yours,

Ben