Confirmed users, Administrators
5,526
edits
CA:RootTransferPolicy: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{DRAFT}} Under discussion in mozilla.dev.security.policy | {{DRAFT}} Under discussion in mozilla.dev.security.policy | ||
= Root Transfer Policy = | |||
The purpose of this page is to document Mozilla’s expectations when the ownership of an included root certificate changes, the organization operating the PKI changes, and/or the private keys of the root certificate are moved to a new location. Throughout such a change, the operation of the root certificate’s private keys and certificate issuance must continue to meet the requirements of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla’s CA Certificate Policy]. | The purpose of this page is to document Mozilla’s expectations when the ownership of an included root certificate changes, the organization operating the PKI changes, and/or the private keys of the root certificate are moved to a new location. Throughout such a change, the operation of the root certificate’s private keys and certificate issuance must continue to meet the requirements of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla’s CA Certificate Policy]. | ||
| Line 15: | Line 15: | ||
* Operation of the PKI is transferred to a different organization who does not currently operate a root certificate included in Mozilla’s program. | * Operation of the PKI is transferred to a different organization who does not currently operate a root certificate included in Mozilla’s program. | ||
* The organization operating the PKI remains the same, but the organization is transferred to a different company or owner. | * The organization operating the PKI remains the same, but the organization is transferred to a different company or owner. | ||
== Physical Relocation == | |||
# Make sure the annual audit statements are current, and notify Mozilla of the pending change. | |||
# Create a transfer agreement and have it reviewed by the auditors. | |||
#* For example, the transfer ceremony should have a documented ceremony and witnessed by auditors AND recorded (for posterity), with a physical exchange of the HSM and a physical exchange of the multi-party authorization keys. | |||
#* ''The biggest challenge here is the "physical exchange" requirement. This is inherently a violation of the BR + Network Security requirements on physical access controls, as the HSM is in-transit away from a secure facility. I suspect there's some possible provision to be made here. I consider a key-wrap solution to be undesirable, because of unknown eavesdropping that cannot be quantified (no matter how many MPLS+VPNs you make, Five Eyes is watching you). Are the auditors supposed to ride across the country / across the world in an armored vehicle carrying the HSM?'' | |||
# Stop new cert issuance (at the current site) before the transfer begins. | |||
# Have an audit performed at the current site to confirm when the root certificates is ready for transfer, and to make sure the key material is properly secured. | |||
# At the new site, perform an audit to confirm that the transfer was successful and that the root certificate is ready to resume issuance. | |||
#* Point in time readiness audit, like we expect any new root to be audited | |||
# Send updated CP/CPS and the PITRA statement to Mozilla | |||
# The regular annual audit statements are still expected to happen within a timely manner, or the root cert may be removed. | |||
That means the new CA must have its operations audited under its ***fully completed transfer*** operations. | |||
The root and all associated intermediates must pass audit against ***then applicable*** requirements only after having the CP/CPS clearly disclosing the details/nature of the transfer. | |||
6) Keep the Mozilla CA Certificate Module Owner appraised of the status of these steps, and inform immediately if a problem occurs. | |||
7) The new CA must follow Mozilla's policy, and provide public-facing CP/CPS documentation and audit statements. So, the new CA has to send Mozilla the URLs to those. | |||
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ | |||
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices | |||
8) The agreement between the current and new CAs should take the trust bit settings into account (Websites (SSL/TLS), Email (S/MIME), and Code Signing), and the current and new CAs should inform Mozilla's CA Certificate Module Owner if one or more of the trust bits should be turned off. Of course, to turn a trust bit on requires the new CA to go through Mozilla's root change process - https://wiki.mozilla.org/CA:How_to_apply#Enable_Additional_Trust_Bits_for_an_included_root | |||
9) "Oh, and you have to tell moz.dev.security.policy after | |||
you did this, rather than just updating your URL with the disclosure" | |||
== Personnel Changes == | |||