Ryan, I appreciate you finally sending responses. I hope you appreciate that they are clearly not adequate, in my opinion. Please see the comments inline.
On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst <r...@google.com> wrote: > First, let me apologize for the delay in my response, I have had a draft of > this letter in my inbox for a while and have just been unable to get back to > it and finish it due to scheduling conflicts. I promise to address all other > questions in a more prompt manner. > > >> pzb: Mozilla recognizes 2.23.140.1.1 as being a valid OID for >> EVcertificates 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). > > > rmh: Yes. We believe that until we have: > > - The associated policies, procedures, and other associated work completed, > > - Have successfully completed an EV audit, > > - And have been approved by one or more of the various root programs as an > EV issuer. > > > That it would be an example of miss-issuance for us to issue such a > certificate. Given the EV-enabled status, this seems like a reasonable path forward. >> 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. > > rmh: I just attached two opinion letters from our auditors, I had previously > provided these to the root programs directly but it took some time to get > permission to release them publicly. One letter is covering the key > generation ceremony of the new roots, and another covering the transfer of > the keys to our facilities. In this second report you will find the > following statement: > > > ``` > In our opinion, as of November 17, 2016, Google Trust Services LLC > Management’s Assertion, as referred to above, is fairly stated, in all > material respects, based on Certification Practices Statement Management > Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key > Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and > Criteria for Certification Authorities v2.0. > ``` > > Based on our conversations with the various root program operator's prior to > our acquisition it has been our plan and understanding, that we can utilize > these opinion letters to augment the webtrust audit with the material > details, relating to these activities. It is our hope that this also > addresses you specific concern here. > >> 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? > > rmh: It is our belief, based on our conversations with the various root > store operators, as well as our own auditors that the transfer itself is > covered by the opinion letters. With that said our audit period is October > 1st to the end of September. The associated report will be released between > October and November, depending on our auditors schedules. 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. >> pzb: 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. > > We discussed the topic of disclosure with the root program administrators > prior to our acquisition. Our goal was to tell the community as soon as > possible, the complexity of this transaction made it hard to get a hard date > for that announcement. Based on our conversations with root program > administrators we were told the policy did not require disclosure to be > public which left the timing of that notification up to us. > > As for the recommendation to clarify the policy in this area, I think it > would be valuable to do that. > > Both of your recommendations seem reasonable, my concern with B) is how to > do so in a way that does not make it impossible or even more complicated to > successfully negotiate such a deal. As long as the disclosure was limited to > intent to become a member then I think that goal would be achieved. 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. >> pzb: 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. > > rmh: We understand this concern. We believe that not all operators of a > subordinate CA have the policies and procedures to effectively manage a root > ca and its keys. However, in our case, for various reasons, Google did have > the associated policies and procedures. Prior to the acquisition we > discussed this situation with the browser root programs, and mutually came > to the conclusion that relying on the opinion letters from the auditors to > demonstrate these would be sufficient. > >> 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. > > >>pzb: 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. > > > First, for others, Google was, and is, operating as a subordinate CA with > its own facilities, policies, and procedures and not an RA. As part of this, > Google has maintained operational policies, procedures for all the common > processes, including but not limited to generation and CA keys, managing > offline keys, generating and publishing CRLs, OCSP responses, and incident > response. > > > In the opinion letter you will find the following statement: > ``` > In our opinion, as of November 17, 2016, Google Trust Services LLC > Management’s Assertion, as referred to above, is fairly stated, in all > material respects, based on Certification Practices Statement Management > Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key > Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and > Criteria for Certification Authorities v2.0. > ``` > > > It was both our hope and understanding that this is sufficient to concern > here. 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. Given the BR limitations around use of root CA keys, this is the critical portion of the certificate issuance criteria; very few subscriber (e.g. non-CA) certificates are issued by root CAs. > As you have noted to me personally in the past you found it odd that Google > generated a new GIAG2 regularly, this is a function of the way Symantec has > structured our agreement with them. This required, as you might imagine, > Google to have developed and maintained the frameworks to support this > activity. > > If there are issues here with the scope of the opinion letter as worded, I > would be happy to work with the auditors to clarify it. > >> pzb: 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). > > We determine we were not explicit enough in the original publication of the > GTS CPS, for this reason we updated it > (http://static.googleusercontent.com/media/pki.goog/en//GTS-CPS-1.5.pdf) and > it now states: > > “Prior to 11 August 2016, the Roots R2, R4, GTS Root R1, GTS Root R2, GTS > Root R3 and GTS Root R4 were operated by GMO GlobalSign, Inc. according to > GMO GlobalSign, Inc.’s Certificate Policy and Certification Practice > Statement. Between 11 August 2016 and 8 December 2016, Google Inc. operated > these Roots according to Google Inc.’s Certification Practice Statement. As > of 9 December 2016, Google Trust Services LLC operates these Roots under > Google Trust Services LLC’s Certificate Policy and Certification Practice > Statement.” > > It is our hope this makes it clearer. This is the exact text I quoted. >> pzb 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? > > This statement reflects the contractual limitation Symantec has on Google > relative to GIAG2. > > To your question of applicability, I believe it is appropriate in this case. > Google and Google Affiliates operate some of the most popular and frequented > sites on the web, as part of that Google often hosts customer applications > and content. > > As I understand it, the goal of the Mozilla root program is to enable sites > just like these to offer their services over SSL. Enabling Google to do so > for its own properties and its customers seems well within the intent of the > program. 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. Mozilla has consistently taken the position that roots that exclusively issue to a single company are not acceptable in the root program. >> pzb: The Google CPS says it only covers Google Internet Authority G2. > >> 5) Is there a version of the CPS that covers the GS roots? > > After a review of the GTS CPS, it became clear we were not sufficiently > clear when the transition from the GIAG2 CPS to the GTS CPS happened, as per > above we have since made a text clarification we hope addresses this > question: > > “Prior to 11 August 2016, the Roots R2, R4, GTS Root R1, GTS Root R2, GTS > Root R3 and GTS Root R4 were operated by GMO GlobalSign, Inc. according to > GMO GlobalSign, Inc.’s Certificate Policy and Certification Practice > Statement. Between 11 August 2016 and 8 December 2016, Google Inc. operated > these Roots according to Google Inc.’s Certification Practice Statement. As > of 9 December 2016, Google Trust Services LLC operates these Roots under > Google Trust Services LLC’s Certificate Policy and Certification Practice > Statement.” 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. I know that you appreciate the importance of clarity and transparency in public CA operations and I hope you can clarify the issues with your answers. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
