Ryan, Thank you for the quick reply. My comments and questions are inline.
On Thu, Feb 9, 2017 at 11:55 AM, Ryan Hurst via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > 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. Where I see opportunities below, I'm marking them with "Policy Suggestion". > 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. Mozilla recognizes 2.23.140.1.1 as being a valid OID for EV certificates for all EV-enabled roots (https://bugzilla.mozilla.org/show_bug.cgi?id=1243923). 1) Do you consider it mis-issuance for Google to issue a certificate containing the 2.23.140.1.1 OID? 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). > 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. It was not. 2) Will Google be publishing an audit report for a period starting 11 August 2016 that covers the transferred GS roots? If so, can you estimate the end of period date? > 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. 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. 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. 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. > 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. I don't see how having a subordinate issuing CA leads to the conclusion that they have "facilities and procedures appropriate for offline key management". Running an online and offline CA are two rather different things and usually have different controls. 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 > 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. I disagree. There is no evidence of operational controls over Subordinate CA Certificate Life Cycle Management. This is highlighted by the fact that the neither the management assertion nor the opinion list this topic at all. 3) Does Google have audited controls around offline operations and Subordinate CA certificate issuance? One more item: The GTS CPS says that "Between 11 August 2016 and 8 December 2016, Google Inc. operated these Roots according to Google Inc.’s Certification Practice Statement." The latest Google Inc CPS I could find is the one dated July 2016 (http://static.googleusercontent.com/media/pki.google.com/en/GIAG2-CPS-1.4.pdf). The Google CPS says "The Google Internet Authority may issue Subscriber Certificates only to the following organizations: Google and Google Affiliates." 4) Do you believe that this restriction is appropriate for roots in the Mozilla program? The Google CPS says it only covers Google Internet Authority G2. 5) Is there a version of the CPS that covers the GS roots? > 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 agree creation of a new CA under the existing audited controls does not require a pre-issuance audit. However that is not applicable to this case. > 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. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
