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
<https://github.com/mozilla/pkipolicy/issues/291>.

Again, here is a comparison
<https://github.com/mozilla/pkipolicy/compare/3b7d84f5c9708cf6be9655319825d60ea338eca4...ad8e1766be6e0e9a93a64b0b71506ae923086ec5>
of the proposed MRSP v3.1
<https://github.com/BenWilson-Mozilla/pkipolicy/blob/3.1/rootstore/policy.md>
(working draft, subject to change) vs. the current MRSP v3.0
<https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/>
.


*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

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabPp-ABSM%3DMjKXGK%3DhbaH1WoT59r7_WsD4XbmPhQorHqw%40mail.gmail.com.

Reply via email to