Confirmed users, Administrators
5,526
edits
CA:RootTransferPolicy: Difference between revisions
Jump to navigation
Jump to search
→Physical Relocation
| Line 7: | Line 7: | ||
== Physical Relocation == | == Physical Relocation == | ||
Physical | 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 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. | * 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 | 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 agreement and have it reviewed by the auditors. | ||
#* For example, the transfer ceremony should have a documented ceremony | #* 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. | ||
#* ''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?'' | #* ''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 | # 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 | # 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 and that the root certificate is ready to resume issuance. | # 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 | # 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. | # 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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ 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://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ | ||
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices | 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 [[CA:How_to_apply#Enable_Additional_Trust_Bits_for_an_included_root|Mozilla's root change process]]. | |||
== Personnel Changes == | == Personnel Changes == | ||