MRSP 3.1: Issue #291: Change in Ownership or Control

[Ben Wilson]

All,

This is the last thread introducing this batch of changes to the Mozilla Root Store Policy (MRSP) for version 3.1 (although minor changes may be incorporated prior to finalization).  This email begins discussion of a proposed replacement of section 8.1 relating to changes in ownership or control of a CA operator or a root CA key pair.

These changes are intended to clarify expectations and improve consistency in how Mozilla evaluates changes involving CA operators (e.g. acquisitions, transfers of control, and changes in the custody of CA private keys). The goal is to ensure that such events are assessed for risk in a structured and transparent manner.

The proposed changes primarily address GitHub Issue #291.

Again, here is a comparison of the proposed MRSP v3.1 (working draft, subject to change) vs. the current MRSP v3.0.

Overview of Proposed Changes

1. Scope and Notification Requirements

The proposed section 8.1 provides a more clearly defined scope of transactions covered, including:

·       Changes in ownership or control of a CA or CA operator; and 

·       Transfers of custody or control of CA private keys corresponding to certificates included in Mozilla’s root store. 

The CA operator is required to notify Mozilla of such changes and provide updated CP/CPS documentation, if appropriate.  Also, both the existing CA operator and any acquiring entity assuming responsibility for CA operations are accountable for full compliance with the MRSP.

2. Risk-Based Evaluation Framework

The transaction will be assessed for whether it introduces new or increased risk to continued compliance, taking into account factors such as:

·       Changes in ownership, governance, or compliance oversight; 

·       Integration or migration of systems, infrastructure, personnel, or key control; 

·       Changes to certificate issuance practices or CP/CPS documentation; and 

·       The scope and continuity of audit coverage. 

The evaluation will also consider whether existing audited systems, controls, and personnel are preserved, and whether the acquiring entity has relevant experience operating publicly trusted CAs.

Importantly, the proposal clarifies that an acquisition of a CA operator as a going concern, without material changes to operations or practices, does not by itself indicate increased risk.

3. Public Discussion and Transparency

The proposed section 8.1 outlines when public discussion is required versus when it is not:

·       A public discussion is required where a transaction introduces new or increased risk; 

·       A public discussion is not required where no such risk is identified; and 

·       Mozilla retains discretion to initiate a public discussion in any case where additional transparency or community input is warranted. 

This is intended to balance transparency with proportionality, ensuring community input when transactions might meaningfully affect risk.

4. Outcomes and Enforcement

The revised section outlines potential outcomes.  If concerns are identified, Mozilla may:

·       Impose conditions or require remediation; 

·       Maintain inclusion of affected certificates subject to those conditions; or 

·       Remove certificates from the root store where necessary. 

Additionally, where a transaction prevents Mozilla from completing its evaluation or results in unresolved concerns, the CA operator must refrain from issuing new certificates until those concerns are resolved.

 

Feedback on the proposed direction and draft language is welcome.

Thanks,

Ben Wilson
Mozilla Root Program