> pzb: I appreciate you finally sending responses. I hope you appreciate
> that they are clearly not adequate, in my opinion. Please see the > comments inline. Again, sorry for the delay in responding, I will be more prompt moving forward. > pzb: This does not resolve the concern. The BRs require an "an unbroken > sequence of audit periods". Given that GlobalSign clearly cannot make > any assertion about the roots after 11 August 2016, you would have a > gap from 11 August 2016 to 30 September 2016 in your sequence of audit > periods if your next report runs 1 October 2016 to 30 September 2017. I understand your point but this is not entirely accurate. Our strategy, to ensure a smooth transition, which was reviewed with the auditors and root program administrators was that we take possession of the root key material and manage it offline, in accordance with our existing WebTrust audit and the “Key Storage, Backup and Recovery Criterion”. It was our, and EY's opinion that the existing controls and ongoing WebTrust audits were sufficient given this plan and scope. As such, during the period in question, the existing audits provide an un-broken sequence of audit periods. That said, we will follow-up with our auditors to see if it is possible to extend the scope of our 2017 audit to also cover this interval to ensure the community has further assurances of continuity. > pzb: Based on my personal experience, it is possible to negotiate a deal > and set a closing date in the future. This is standard for many > acquisitions; you frequently see purchases announced with a closing > date in the future for all kinds of deals. The gap between signing > the deal and closing gives acquirers the opportunity to complete the > steps in B. As I stated, I think that moving forward this could be a good policy change, I am hesitant to see any user agent adopt policies that are overly prescriptive of commercial terms between two independent parties. > pzb: You appear to be confusing things here. "Subordinate CA Certificate > Life Cycle Management" is the portion of the WebTrust criteria that > covers the controls around issuing certificates with the cA component > of the basicConstraints extension set to true. It has nothing to do > with operating a subordinate CA. I am familiar with the "Subordinate CA Certificate Life Cycle Management" controls I just should have been more explicit in my earlier response. These keys were generated and stored in accordance with Asset Classification and Management Criterion, and Key Storage, Backup and Recovery Criterion. Before utilizing the associated keys in any activity covered by the “Subordinate CA Certificate Life Cycle Management” criterion all associated policies and procedures were created, tested and then reviewed by our auditors. Additionally, those auditors were present during the associated ceremony. All such activities which will be covered under our 2017 audit. This is similar to how a CA can, and does, revise and extend their policies between audits to cover new products and services. This is consistent with the approach we discussed, and had approved with the various root program administrators. > pzb: You have stated that the Google CPS (not the GTS CP/CPS) was the > applicable CPS for your _root CAs_ between 11 August 2016 and 8 > December 2016. The Google CPS makes these statements. Therefore, you > are stating that the roots (not just GIA G2) were only permitted to > issue Certificates to Google and Google Affiliates. Correct, these roots were not used to issue certificates at all until last week and when one was used, it was used to issue a subordinate CA certificate to Google. Though we do not have a product or service to announce currently, we can say we will expand the use of GTS beyond GIAG2, at which time policies, procedures, CP and CPS will be updated accordingly. This progression makes sense as we're moving from a constrained intermediate to a Root. > Mozilla has consistently taken the position that roots that exclusively issue to a > single company are not acceptable in the root program. Google and its affiliate companies are more than a single company. Additionally, clearly the intent of this rule is to prevent thousands of organizations issuing a handful of certificates polluting the root store. In the case of Google and its Affiliate companies, we operate products and services for our customers. This is similar to how Amazon and a number of other root operators operate products and services for their customers, the core difference being the breadth of user facing products we have. > This does not address the question. The Google CPS clearly states > that it only covers the GIA G2 CA. You have stated that the Google > CPS (not the GTS CP/CPS) was the applicable CPS for your _root CAs_ > between 11 August 2016 and 8 December 2016. This puts your statement > at adds with what is written in the CPS. As stated previously, since Google already had a WebTrust audit in good standing, and that the acquisition happened inline with our standing regular audit, the root program administrators agreed to the use of an opinion letter in lieu of repeating the audit 90 days letter. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
