Having gained a good understanding of Peter and Ryan's positions, I think I am now in a position to evaluate Peter's helpful policy suggestions.
Whether or not we decide to make updates, as Kathleen pronounced herself satisfied at the time with Google's presented documentation and migration plan, it would be unreasonable for us to retroactively censure Google for following that plan. On 09/02/17 22:55, Peter Bowen wrote: > Policy Suggestion A) When transferring a root that is EV enabled, it > should be clearly stated whether the recipient of the root is also > receiving the EV policy OID(s). I agree with this suggestion; we should update https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually incorporate it into the main policy when we fix https://github.com/mozilla/pkipolicy/issues/57 . > I think that this is the key issue. In my reading, "root > certificates" are not members of the program. Rather organizations > (legal entities) are members and each member has some number of root > certificates. > > Google was not a member of the program and had not applied to be a > member of the program at the time they received the roots already in > the program. This seems problematic to me. https://wiki.mozilla.org/CA:RootTransferPolicy says that "The organization who is transferring ownership of the root certificate’s private key must ensure that the transfer recipient is able to fully comply with Mozilla’s CA Certificate Policy. The original organization will continue to be responsible for the root certificate's private key until the transfer recipient has provided Mozilla with their Primary Point of Contact, CP/CPS documentation, and audit statement (or opinion letter) confirming successful transfer of the root certificate and key." I would say that an organization which has acquired a root certificate in the program and which has provided Mozilla with the above-mentioned information is thereby a member of the program. As the policy says that the transferring entity continues to be responsible until the information is provided, that seems OK to me. This position would logically lead to the position that a root inclusion request from an organization which does not have any roots is also, implicitly, an application to become a member of the program but the two things are distinct. One can become a member of the program in other ways. Membership is sort of something that happens to one automatically when one successfully achieves ownership of an included root. > Policy Suggestion B) Require that any organization wishing to become > a member of the program submit a bug with links to content > demonstrating compliance with the Mozilla policy. Require that this > be public prior to taking control of any root in the program. We do require this, but not publicly. I note and recognise Ryan's concern about requiring advance disclosure of private deals. I could see a requirement that a transferred root was not allowed to issue anything until the appropriate paperwork was publicly in place. Would that be suitable? > Policy Suggestion C) Recognize that root transfers are distinct from > the acquisition of a program member. Acquisition of a program > member (meaning purchase of the company) is a distinctly different > activity from moving only a private key, as the prior business > controls no longer apply in the latter case. https://wiki.mozilla.org/CA:RootTransferPolicy does make this distinction, I feel - how could it be better made? > Policy Suggestion D) Moving from being a RA to a CA or moving from > being a single tier/online (i.e. Subordinate-only) CA to being a > multi-tier/root CA requires a PITRA Again, would this be covered by a requirement that no issuance was permitted from a transferred root until all the paperwork was in place, including appropriately-scoped audits? This might lead to a PITRA, but would not have to. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
