Peter, Thank you very much for your, as always, thorough review.
Let me start by saying I agree there is an opportunity for improving the policies around how key transfers such your recent transfer and Google's are handled. It is my hope we can, through our respective recent experiences performing such transfers, help Mozilla revise their policy to provide better guidance for such cases in the future. As for your specific questions, my responses follow: pzb: First, according to the GTS website, there is no audit using the WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL. However the two roots in the Mozilla CA program currently are EV enabled and at least one subordinate CA under them is issuing EV certificates. rmh: Prior to our final stage of the acquisition we contacted both Mozilla and Microsoft about this particular situation. At this time, we do not have any interest in the issuance of EV SSL certificates, however GlobalSign does. Based on our conversations with representatives from both organizations we were told that since: - The EV OID associated with this permission is associated with GlobalSign and not Google and, - GlobalSign is active member in good standing with the respective root programs and, - Google will not be issuing EV SSL certificates, - Google will operate these roots under their own CP/CPS’s and associated OIDs, - Google issuing a certificate with the GlobalSign OIDs would qualify as miss-issuance. That it would be acceptable for us not to undergo a EV SSL audit, and that GlobalSign could keep the EV right for the associated subordinate CA for the remaining validity period to facilitate the transition (assuming continued compliance). As a former manager of a root program, this seems an appropriate position to take. And as one who has been involved in several such root transfers I think differences in intended use are common enough that they should be explicitly handled by policy. pzb: Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8 December 2016, Google Inc. operated these Roots according to Google Inc.’s Certification Practice Statement." The basic WebTrust for CA and WebTrust BR audit reports for the period ending September 30, 2016 explicitly state they are for "subordinate CA under external Root CA" and do not list the roots in the GTS CPS at all. rmh: I believe this will be answered by my responses to your third and fourth observations. pzb: Third, the Google CPS says Google took control of these roots on August 11, 2016. The Mozilla CA policy explicitly says that a bug report must be filed to request to be included in the Mozilla CA program. It was not until December 22, 2016 that Google requested inclusion as a CA in Mozilla's CA program (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532). This does not appear to align with Mozilla requirements for public disclosure. rmh: As has been mentioned, timing for a transaction like this is very complicated. The process of identifying candidates that could meet our needs took many months with several false starts with different organizations. That said, prior to beginning this process we proactively reached out to both Microsoft and Mozilla root programs to let them know we were beginning the process. Once it looked like we would be able to come to an agreement with GlobalSign we again reached out and notified both programs of our intent to secure these specific keys. Then once the transaction was signed we again notified the root programs that the deal was done. As you know the process to ensure a secure, audited and well structured key migration is also non-trivial. Once this migration was performed we again notified both root programs. Our intention was to notify all parties, including the public, shortly after the transfer but it took some time for our auditors, for reasons unrelated to our audit, to produce the associated audit letters. Once we received said letters, we then filed the bugs. This is, although not our ideal timeline, and based on our understanding, in compliance with the Mozilla root program in that since these roots were already members they did not require us to publicly disclose the above negotiation, contracting, planning, migration and other intermediate steps. pzb: Fourth, the audit reports linked in the bug explicitly set the scope of "subordinate CA operated under external Root CA" and do not include any indication of controls around the issuance of subordinate CA certificates. These audit reports do not have an appropriate scope for a root CA. rmh: Yes, we were also concerned about this topic, especially with the recent scope issues with audits. As such, we discussed this with both our auditors, and the the root programs prior to acquisition of the key material. When looking at this issue it is important to keep in mind Google has operated a WebTrust audited subordinate CA under Symantec for quite a long time. As part of this they have maintained audited facilities, and procedures appropriate for offline key management, CRL/OCSP generation, and other related activities. Based on this, and the timing of both our audit, and key transfer all parties concluded it would be sufficient to have the auditors provide an opinion letter about the transfer of the keys and have those keys covered by the subsequent annual audit. We have provided these letters directly to the root programs and have recently secured permission from the auditors to release them publicly (I will add them to the bug). For those not familiar with the process, If Google had never been a WebPKI CA, this situation would have been addressed with a pre-issuance audit and a subsequent full audit 90 days later. Since Google is a long-time WebTrust audited CA and our audits and acquisition were going to happen approximately at the same time, this would have provided no new evidence to the root programs or the community. The purpose of the audit is to provide assurances to the root program and community that best practices are being followed and the relying parties best interests are being met. In this case following the procedure defined for an new CA would not have aided that goal. As an example, consider the case of a WebPKI trusted root with one key already trusted, they can generate a new key and include it in its next audit without the need to do the pre-issuance audit. I think this is an appropriate position to take and an opportunity to clarify the Mozilla root program to better inform similar cases in the future. It's my hope these answers sufficiently addressed your concerns, if not let me know if there are any clarifications I can make. Thanks again, Ryan Hurst Google, Inc. On Thu, Feb 9, 2017 at 2:06 AM, Gervase Markham <g...@mozilla.org> wrote: > On 09/02/17 05:31, Peter Bowen wrote: > > Third, the Google CPS says Google took control of these roots on > > August 11, 2016. The Mozilla CA policy explicitly says that a bug > > report must be filed to request to be included in the Mozilla CA > > program. > > But the Mozilla CA policy does not require that the organization on the > receiving end of a root transfer must re-apply for inclusion for > already-included certificates. > > > It was not until December 22, 2016 that Google requested > > inclusion as a CA in Mozilla's CA program > > (https://bugzilla.mozilla.org/show_bug.cgi?id=1325532). This does not > > appear to align with Mozilla requirements for public disclosure. > > We require disclosure of root ownership transfer, but not _public_ > disclosure. Kathleen would need to speak regarding dates, but I know > Mozilla was made aware of these transfers significantly before the > inclusion request was filed. > > Apart from this, however, it seems at first glance that the other > assertions made in Peter's post here in mozilla.dev.security.policy are > correct. So CCing Ryan Hurst of GTS for a response. > > Gerv > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
