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.
Thanks, M.D. On 4/24/2015 3:49 PM, Peter Kurrasch wrote:
I don't think a transfer action by a CA should be treated as an automatic accept by the security community. The purpose of the root certs and thus the CA program is to establish and maintain trust in an organization and it's policies and procedures. From my perspective this means the transfer recipient first must establish that trust and, second, must provide evidence that the transfer itself will be performed in a secure and/or trustworthy manner. As has already been pointed out there are different types of transfers to consider, each with its own conditions and concerns: a) legal ownership transfer, such as when one company buys out another. For example, if Symantec were to assign ownership of all their roots to the US military, is it reasonable that we be expected to transfer the trust we'd previously extended to Symantec? b) physical relocation. For example, if the plan is to drop the private keys in a FedEx envelope and send it across the country we have every reason to expect the NSA to intercept that package. c) changes in "key personnel". For example if the head of the new organization previously ran a sausage factory and has no experience in PKI, I don't think we'd necessarily want to trust that transfer. So, just some thoughts to get the conversation going. I don't so much have a problem with what you've suggested, Kathleen, but I think it's worth taking a step back first and identify the cases we even want to address. Original Message From: Kathleen Wilson Sent: Thursday, April 23, 2015 6:38 PM To: [email protected] Subject: Re: Policy about root cert transfers On 4/23/15 4:21 PM, Kathleen Wilson wrote:All, It has been brought to my attention that we do not have a documented procedure or policy about how to transfer a root certificate from one CA to another. Do we need to add expectations about root cert transfers to Mozilla's CA Certificate Policy? I think, at the minimum, we should add information about our expectations to one of our process wiki pages, or maybe this needs its own wiki page? Here's what I usually tell CAs when they ask: 1) I recommend creating a transfer agreement and have it reviewed by the auditors for both the current and the new CA. 2) New cert issuance (at the current CA's site) should be stopped before the transfer begins. 3) There should be an audit performed at the current CA's site to confirm when the root certificates is ready for transfer. 4) Before the new CA begins issuing certs in the transferred CA cert hierarchy, there should be an audit performed at the new CA's site to confirm that the transfer was successful and that the root cert is ready to resume issuance. 5) The regular annual audit statements are still expected to happen within a timely manner, or the root cert may be removed. 6) Keep the Mozilla CA Certificate Module Owner appraised of the status of these steps, and inform immediately if a problem occurs. I will appreciate your thoughtful and constructive input on this topic. KathleenThings to add: 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 Kathleen _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
