On Fri, April 24, 2015 7:25 am, Ben Wilson wrote: > Kathleen, > I think we need to drill down into what is meant by "audit". Also, I > don't > think a CA who is under ongoing audit obligations should have a special > "audit" just for a root transfer. Neither should the current CA that is > operating under audit be required to have a special audit. If two > entities > (A and B), operating CAs under the WebTrust requirements and both approved > as operators by Mozilla transfer root key from A to B, then the only thing > required should be documented custody and procedural controls that are > audited. So one audit - that A and B observed stated custody controls and > security procedures when they effectuated the transfer from one location > to > another. Also, let's assume, for the sake of discussion, that the root > key > transfer can be done through a secure VPN tunnel in an encrypted and > controlled fashion with an out-of-band transfer of activation data for the > encapsulated key, such that the key moves halfway around the world without > physical courier. What then? > Ben
Just trying to combine the points raised from many threads (and I think you've got good points here, Ben), let's see if we've got the permutations of concerns covered. Note - many of these dimensions are not *presently* things that factor in to the Mozilla policy, but it's clear that some people in the list wish to at least discuss whether or not they're worth distinguishing, so trying to cover for completeness. Dimension 1 - Who currently holds the key? - Existing CA with a current audit - Existing CA with an out of date audit, but within the 'grace' window that is implicitly allowed but explicitly discouraged Dimension 2 - What is the state of the current key holder? - Currently practicing business - Business in some form sale - Business in some form of liquidation / receivership - Business in the process of being acquired - Business that has been acquired - Out of business [is this possible while still holding assets?] Dimension 3 - Who is the organization receiving the key? - Entity that operationally controls an existing CA recognized by Mozilla - And has a current audit - And has an expired audit - Entity that has no pre-existing relationship with Mozilla Dimension 4 - Who operates the organization receiving the key? - Government entity - Incorporated business nominally controlled by government entity - Independent business [Not sure if we can actually make the distinctions, but it's come up in the past CA policy discussions] Dimension 5 - How will the key be delivered? - Physical transfer of existing HSM - FIPS 140 Level 3 compliant key wrapping, single-delivery - FIPS 140 Level 3 compliant key wrapping, multi-party - Non-FIPS 140 Level 3 compliant key wrapping Dimension 6 - Who will oversee the execution of the transfer? [which is really like 3 or 4 dimensions, but bear with me] - Nobody; no ceremony documented not recorded - Nobody; no ceremony documented, but recorded - Nobody; ceremony documented, but not witnessed - Nobody; ceremony documented and recorded, but not witnessed - Auditors; no ceremony documented, but witnessed - Auditors, ceremony documented and witnessed Are there more nuances? I don't know. Should Mozilla policy cover what to do in all these cases? I should hope not. Are there things we should mandate? Maybe. Are there principals we can take away from these? I should hope so. FWIW, my own take would be the transfer ceremony would 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. Regardless of whether it's an existing CA or a new CA, I would want a PITRA for the new holder. If the existing audit has lapsed, then I consider it game over for that root - you cannot execute a transfer; the existing holder MUST bring their audit current, MUST notify Mozilla, and MUST have the lapse evaluated according to the existing guidelines BEFORE executing such a transfer. I think 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? I don't know. Of course, the alternative to this degree of complexity is to not treat it as an exchange of the existing key, but a key rollover-like event. Rather than transferring the HSM, the existing holder signs a certificate for the new holder (with the new holder having done all the appropriate ceremonies and PITRA of a root CA). Once that is complete, a ceremony to securely destroy the existing root is performed. Having completed that ceremony, the status within the root store is conferred upon the new holder - a root certificate (non-self-signed) for the certified key is automatically added to Mozilla, with all the rights and responsibilities that entails, and the existing certificate is removed. The new "holder" can use the cross-signed certificate however they wish - it can work with existing clients [via cross-signing] or new clients [via the root]. There are all sorts of trade-offs here, but hopefully I've captured some of the many nuances here with "transfer" that have *always* existed in such programs, but which have hitherto been unexplored by the community. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
