On Monday, April 24, 2017 at 9:58:29 PM UTC-7, Jakob Bohm wrote: > On 25/04/2017 05:04, Ryan Sleevi wrote: > > On Mon, Apr 24, 2017 at 9:42 PM, Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> On 25/04/2017 03:10, Peter Kurrasch wrote: > >> > >>> Fair enough. I propose the following for consideration: > >>> > >>> Prior to transferring ownership of a root cert contained in the trusted > >>> store (either on an individual root basis or as part of a company > >>> acquisition), a public attestation must be given as to the intended > >>> management of the root upon completion of the transfer. "Intention" must > >>> be one of the following: > >>> > >>> A) The purchaser has been in compliance with Mozilla policies for more > >>> than 12 months and will continue to administer (operate? manage?) the > >>> root in accordance with those policies. > >>> > >>> B) The purchaser has not been in compliance with Mozilla policies for > >>> more than 12 months but will do so before the transfer takes place. The > >>> purchaser will then continue to administer/operate/manage the root in > >>> accordance with Mozilla policies. > >>> > >>> How about: > >> > >> B2) The purchaser is not part of the Mozilla root program and has not > >> been so in the recent past, but intends to continue the program > >> membership held by the seller. The purchaser intends to complete > >> approval negotiations with the Mozilla root program before the transfer > >> takes place. The purchaser intends to retain most of the expertise, > >> personnel, equipment etc. involved in the operation of the CA, as will > >> be detailed during such negotiations. > >> > >> This, or some other wording, would be for a complete purchase of the > >> business rather than a merge into an existing CA, similar to what > >> happened when Symantec purchased Verisign's original CA business years > >> ago, or (on a much smaller scale) when Nets purchased the TDC's CA > >> business unit and renamed it as DanID. > >> > > > > Why is that desirable? If anything, such acquisitions seem to be more > > harmful than helpful to the CA ecosystem. That is, why _wouldn't_ a merge > > be useful/desirable? What problems are you attempting to solve? > > > > Look at my two examples of past acquisitions. As far as I remember, in > neither case was the purchasing security company previously a trusted > CA, and they took over practically the whole operation with no initial > changes besides a name change. > > Another variant of this scenario is when a CA restructures its formal > ownership structure, such as inserting or removing one or more levels > of companies between the ultimate owners and the CA operations > activity. In many cases this would technically be an acquisition by a > new company that isn't a CA itself (as the acquiring company would > often be an empty shell). One example would be the recent creation of > GTS from part of Google Inc, since GTS was a new company with no past > CA activity, while the acquired Google division had a past as a SubCA > and a recently acquired root cert. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded
Jakob, I would add that in cases where CA organizations are acquired outright and the staff and infrastructure are retained it is often only for a limited period of time. In other words, the acquisition takes place and then after some relatively short period of time we see the acquirer try to: - align operations with other parts of the business, - achieve cost savings, - improve technology, performance, scale and disaster recovery ability. These all tend to result in a reboot of "what was there" prior to the acquisition. In these situations dislocated key staff often finds new roles at another CA or move on to non-ca related roles and sleep better ;) Ryan _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
