On 08/03/2017 18:12, Ryan Hurst wrote:
jacob: Could a reasonably condition be that decision authority, actual and
physical control for a root are not moved until proper root program
coordination has been done (an action which may occur after/before the
commercial conclusion of a transaction).  From a business perspective
this could be comparable to similar requirements imposed on some
physical objects that can have public interest implications.

Microsoft has a similar requirement in their program, we had to get permission
from them before we could finalize commercial terms for this acquisition.
I personally think this is a good policy and one I think Mozilla should adopt 
as well.

It adds more complexity to these acquisitions in that one needs to get the 
approvals
from multiple parties but I think that the value to the ecosystem warrants
this complexity.


Jacob: For clarity could Google and/or GTS issue a dedicated CP/CPS pair for
the brief period where Google (not GTS) had control of the former
GlobalSign root (such a CP/CPS would be particularly simple given that
no certificates were issued).  Such as CP/CPS should also clarify any
practices and procedures for signing revocation related data (CRLs,
OCSP responses, OCSP responder certificates) from that root during the
transition.  The CP/CPS would also need to somehow state that the
former GlobalSign issued certificates remain valid, though no further
such certificates were issued in this interim period.

Similarly could Google and/or GTS issue a dedicated CP/CPS pair for the
new roots during the brief period where Google (not GTS) had control of
those new roots.

While we want to work with the community to provide assurances we followed
best practices and the required policies in this transfer I do not think this 
would provide
any further insights.

Before the transfer we, and our auditors, reviewed the CP/CPS, as well as the 
policies
and procedures associated with the the management of these keys, and found them 
to be
both compliant with both the requirements and best practices. In other words,
both we, and our auditors, are stating, as supported by the opinion letter, 
that we believe the
Google CP/CPS covered these keys during this period.

If we created a new CP/CPS for that period it would, at best, be a subset of the
Google CP/CPS and offer no new information other than the omission of a few 
details.

Could you maybe clarify what your goals are with this request, with that we can 
potentially
propose an alternate approach to address those concerns.



This was merely suggested as a possible way to formally answer the
fears and questions posed by others about the situation during the
transition and the discussed inapplicability of some wording in the
old Google CP/CPS to the new situation.


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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to