CA:RootTransferPolicy: Difference between revisions
| Line 14: | Line 14: | ||
In all of these cases, the CA should take the following steps, and immediately notify Mozilla if a problem occurs. | In all of these cases, the CA should take the following steps, and immediately notify Mozilla if a problem occurs. | ||
# Make sure the annual audit statements are current, and notify Mozilla of the pending change. | # 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. | # Create a transfer plan (and agreement of more than one CA is involved) and have it reviewed by the auditors. | ||
#* For example, the transfer ceremony should have a documented ceremony witnessed by auditors and recorded (for posterity), with a physical exchange of the HSM and a physical exchange of the multi-party authorization keys. | #* For example, the transfer ceremony should have a documented ceremony witnessed by auditors and recorded (for posterity), with a physical exchange of the HSM and a physical exchange of the multi-party authorization keys. | ||
# Stop new certificate issuance at the current site before the transfer begins. | # Stop new certificate issuance at the current site before the transfer begins. | ||
# Have an audit performed at the current site to confirm when the root certificate is ready for transfer, and to make sure the key material is properly secured. | # Have an audit performed at the current site to confirm when the root certificate is ready for transfer, and to make sure the key material is properly secured. | ||
Revision as of 22:50, 28 May 2015
DRAFT
The content of this page is a work in progress intended for review.
Please help improve the draft!
Ask questions or make suggestions in the discussion
or add your suggestions directly to this page.
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 Mozilla’s CA Certificate Policy.
Change in Legal Ownership
An example of a change in legal ownership is when one company buys another. This does not necessarily imply that there will be a change in operation of the root certificate or change in location of the root certificate's private keys. The CA should let Mozilla know when there is a change of ownership and the impact to the operation of the root certificate, and must continue to publish their CP/CPS and annual audit statements according to Mozilla’s CA Certificate Policy.
Physical Relocation
Physical relocation of the root certificate's private key may occur when a CA:
- Moves their private keys to another location owned by that CA.
- Transfers the private keys to another CA that already has other root certificates included in Mozilla’s program.
- Transfers the private keys to another CA that does not have root certificates included in Mozilla’s program.
In all of these cases, the CA should take the following steps, and immediately notify Mozilla if a problem occurs.
- Make sure the annual audit statements are current, and notify Mozilla of the pending change.
- Create a transfer plan (and agreement of more than one CA is involved) and have it reviewed by the auditors.
- For example, the transfer ceremony should have a documented ceremony witnessed by auditors and recorded (for posterity), with a physical exchange of the HSM and a physical exchange of the multi-party authorization keys.
- Stop new certificate issuance at the current site before the transfer begins.
- Have an audit performed at the current site to confirm when the root certificate 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, that they private key remained secure throughout the transfer, and that the root certificate is ready to resume issuance (i.e. a PITRA; just as 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.
When the physical relocation involves moving the certificate's private key to another CA, the CA who is transferring the root certificate’s private key must ensure that the transfer recipient is able to meet Mozilla’s CA Certificate Policy, and will continue to be responsible for the root until the transfer recipient has provided Mozilla with their Primary Point of Contact, CP/CPS documentation, and audit statement confirming successful transfer of the root.
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
The agreement between the current and new CAs must 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 if one or more of the trust bits should be turned off. Of course, to turn on a trust bit requires the new CA to go through Mozilla's root change process.
Personnel Changes
Personnel Changes may include one or more of the following.
- Operation of the PKI is transferred to a different organization who is already operating root certificates 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.