MRSP 3.0: Survey Results and Status Update

[Ben Wilson]

All,

I have reviewed many of the CA operator survey responses, and I am working to present them in a structured and insightful way. I am also preparing an FAQ document that will provide further implementation and compliance guidance for CA operators to address many of the questions and concerns raised in their responses to the survey questions.

To facilitate the display of recent changes to the draft of MRSP 3.0, I have created an additional branch in GitHub—Updates-from-Survey-Responses—which reflects proposed revisions based on the feedback received. And, for a direct comparison between the language in the current MRSP 3.0 branch and this new GitHub branch, see:  Comparison of Branches.

One other key step that I’m working on is to prepare MRSP 3.0 for publication on the Mozilla website, pending legal review. We are on track for this, and I want to reaffirm our commitment to the March 1, 2025, effective date.

To ensure everyone is aligned with upcoming compliance milestones, here’s a brief overview of key dates (some of which are included in the new GitHub branch):

• January 1, 2025: Newly included root CA certificates cannot be dual-purpose (i.e. enabled for both website authentication and email protection). Also, any new root CA certificates with the websites trust bit enabled must demonstrate automated issuance capabilities.
• March 1, 2025: This is the official compliance date when new requirements take effect, unless otherwise specified.
• Annual audit periods beginning after March 1, 2025: CA operators must begin identifying “parked CA keys” in their annual audit reports.
• Annual audit periods beginning after June 1, 2025: A CA operator capable of issuing trusted TLS certificates must obtain a third party assessment of the maintenance and testing of its mass revocation plan.
• September 1, 2025: All CA operators must have a mass revocation plan in place and begin the process to have it tested and evaluated (in accordance with the previous bullet).
• April 15, 2026: Any CA operating a dual-purpose root (with both websites and email trust bits enabled) must submit a transition plan to Mozilla.
• December 31, 2028: The final transition deadline, by which no root CA certificate will have both trust bits enabled.

If you have any questions or need further clarification, please don't hesitate to reach out.

Thanks,

Ben

[Ben Wilson]

All,

In response to survey feedback on the proposed requirements in section 6.1.3 for mass revocation planning and testing, I have developed a draft Mass Revocation Incident Preparation and Testing Plan (MRIP&TP) template.

Since this is not a Mozilla recommendation, but rather a resource that may help CAs in meeting upcoming requirements, I’m wondering how best to share it. Would it be useful to post it to the list for discussion, or would another approach be preferable?

I’d appreciate any thoughts on this.

Thanks,
Ben

[Matt Palmer]

On Tue, Feb 18, 2025 at 12:15:32PM -0800, 'Ben Wilson' via dev-secur...@mozilla.org wrote:
> In response to survey feedback on the proposed requirements in *section
> 6.1.3* for mass revocation planning and testing, I have developed a draft *Mass
> Revocation Incident Preparation and Testing Plan (MRIP&TP)* template.
>
> Since this is *not a Mozilla recommendation*, but rather a resource that

> may help CAs in meeting upcoming requirements, I’m wondering how best to
> share it. Would it be useful to post it to the list for discussion, or
> would another approach be preferable?

If you think it's going to be a draft that'll require significant
revision and third-party input, posting the draft to the list soliciting
comments is probably best.

As far as where the final text goes, the Mozilla wiki would seem
reasonable -- plenty of the information there already is what I would
consider "informative" rather than "normative", so adding this template
would not be out of place, IMO.

- Matt

[高尾由加利]

2025年2月19日(水) 7:13 Matt Palmer <mpa...@hezmatt.org>:

--
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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a31ec4e1-d36d-4975-a288-2a4c4e4e1633%40mtasv.net.

[Jeremy Rowley]

Hi Ben - what is the intent of the change on the "parked keys"? There already is a cradle-to-grave requirement. Is this just clarifying the format that CAs must use when listing key pairs in their audit report? Have CAs not been providing cradle-to-grave audit reports already? I ask as the adoption date could cause confusion about whether this requirement is already applicable to all CAs (which I thought it was).

[Ben Wilson]

Hi Jeremy,

Thanks for reaching out. The intent of the proposed changes is twofold (both a clarification and a new requirement) because:

1. While the "cradle-to-grave" requirement was already present, it wasn’t always clearly articulated or consistently interpreted. Some CAs might have assumed they were meeting it without explicitly providing the necessary documentation or tracking for the entire CA key lifecycle.
2. The clarification aims to ensure that key lifecycle tracking is more comprehensive and consistently reported. By specifying that "parked" keys must be included in key lifecycle management reports (or an equivalent audit section), we are reinforcing the expectation that all CA keys are accounted for throughout their entire lifecycle.

This aligns with GitHub Issue #275, which I opened in January 2024. At the time, I noted that audit templates for key lifecycle management reports are valuable for CAs seeking root inclusion, as they provide evidence of key protection over a period of time. (Period-of-time audits are preferable to point-in-time audits, readiness assessments, or even key generation reports in this context.

Additionally, this change is particularly relevant for intermediate CA certificates that might be signed and created well after a key generation ceremony. In such cases, tracking the status and handling of those "parked" keys becomes especially important to ensure their security and proper management during the period between the key generation ceremony and CA certificate creation.

Additionally, this change is intended to bring further clarity to section 3.1.3 of the MRSP and other parts of section 3, emphasizing the usefulness of period-of-time key lifecycle reports in meeting cradle-to-grave key protection requirements.

With this clarification, we aim to improve the accuracy and completeness of CA key tracking throughout their entire lifecycle (from the key generation report until the key is destroyed or no longer trusted).

Thanks again,

Ben

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c3e32b1a-1b28-4248-b6c4-67da814ba542n%40mozilla.org.

[Ben Wilson]

All,

I have renamed the previously-mentioned branch to Final Updates 3.0 (https://github.com/mozilla/pkipolicy/compare/Final-Updates-3.0), and I'm merging this update branch into the 3.0 branch that has the rest of the changes.

Here are some final edits made today:
https://github.com/mozilla/pkipolicy/compare/695d6c318875a912a4a5ce3fa0d0f6aa1ca5f0d6...2c815ba3bed17a5023b6f283442d71d3c81a3a94.

Of note:

• I have changed the Effective Date to March 15, 2025, made changes to reflect the March 15, 2025, date in several places.
• Under section 6.1.3 for mass revocation plans, I have separated the assessment part more clearly and added a clarification, "The above-referenced June 1, 2025, date is to ensure that compliance with the September 1, 2025, requirements will be evaluated within a reasonable timeframe while allowing CA operators to incorporate mass revocation testing into their CA processes and annual audit cycles. However, the assessment does not have to be conducted as part of the CA operator’s ETSI or WebTrust audit unless the CA operator finds it more convenient to include it within that scope. The assessment may be conducted separately by a qualified third-party assessor, provided it meets the stated evaluation criteria."
• Under section 7.5 for dedicated roots, I added a clarification "CA operators with root certificates that have both the websites and email trust bits enabled SHOULD review the transition schedule associated with Section 7.4 (Root CA Lifecycles) when planning their compliance with this section 7.5. Specifically, CA operators SHOULD be aware that Mozilla’s trust bit transition schedule will result in the removal of the websites trust bit from certain root certificates before December 31, 2028."

Ben

You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsub...@mozilla.org.