The three week discussion period for this inclusion request has passed with no comments received. I am now closing this discussion with a recommendation to approve this request. Any further comments should be added directly to the bug.
- Wayne On Thu, Aug 23, 2018 at 3:58 PM Wayne Thayer <wtha...@mozilla.com> wrote: > This request is for inclusion of the Google Trust Services R1, R2, R3, and > R4 roots as documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1325532 > > Google’s application states: > Google is a commercial CA that will provide certificates to customers from > around the world. We will offer certificates for server authentication, > client authentication, email (both signing and encrypting), and code > signing. Customers of the Google PKI are the general public. We will not > require that customers have a domain registration with Google, use domain > suffixes where Google is the registrant, or have other services from Google. > > * BR Self-Assessment: > https://bug1325532.bmoattachments.org/attachment.cgi?id=8943360 > > * Summary of Information Gathered and Verified: > https://bug1325532.bmoattachments.org/attachment.cgi?id=8965095 > > * Root Certificate Download URL: > ** R1: https://pki.goog/gtsr1.crt > ** R2: https://pki.goog/gtsr2.crt > ** R3: https://pki.goog/gtsr3.crt > ** R4: https://pki.goog/gtsr4.crt > > * CP/CPS: > ** CP: https://pki.goog/GTS-CP-1.5.pdf > ** CPS: https://pki.goog/GTS-CPS-2.3.pdf > > * This request is to turn on the Websites trust bit (reference comment #29 > in the bug). EV treatment has not been requested. > ** EV Policy OID: N/A > > * Test Websites: > ** R1: https://good.r1demo.pki.goog https://revoked.r1demo.pki.goog > https://expired.r1demo.pki.goog > ** R2: https://good.r2demo.pki.goog https://revoked.r2demo.pki.goog > https://expired.r2demo.pki.goog > ** R3: https://good.r3demo.pki.goog https://revoked.r3demo.pki.goog > https://expired.r3demo.pki.goog > ** R4: > > * CRL URLs: > ** R1: http://crl.pki.goog/gtsr1/gtsr1.crl > ** R2: https://crl.pki.goog/gtsr2/gtsr2.crl > ** R3: https://crl.pki.goog/gtsR3/gtsr3.crl > ** R4: https://crl.pki.goog/gtsR4/gtsr4.crl > > * OCSP URLs: > ** R1: http://ocsp.pki.goog/gstr1 > ** R2: https://ocsp.pki.goog/gstr2 > ** R3: https://ocsp.pki.goog/gstr3 > ** R4: https://ocsp.pki.goog/gstr4 > > * Audit: Annual audits are performed by Ernst & Young according to the > WebTrust for CA and BR audit criteria. > ** WebTrust: https://cert.webtrust.org/SealFile?seal=2346&file=pdf > ** BR: https://cert.webtrust.org/SealFile?seal=2347&file=pdf > > I’ve reviewed the CP and CPS, BR Self Assessment, and related information > for the Google Trust Services inclusion request that is being tracked in > this bug and have the following comments: > > ==Good== > * Google has supplied a key generation ceremony audit report [1] > * Other than the disclosed intermediates and required test certificates, > no issuance has been detected from these roots. > * Section 1.4.2 of the CPS expressly forbids the use of Google > certificates for “man-in-the middle purposes” > * Appendix C of the current CPS indicates that Google limits the lifetime > of server certificates to 365 days. > > ==Meh== > * These 4 roots were created by GlobalSign and then transferred to Google. > A lengthy discussion regarding the transfer [2] occurred, primarily focused > on existing GlobalSign roots that were purchased rather than these new > roots. However, I believe the following concerns are relevant: > ** From the transfer on 11-August 2016 through 8-December 2016, at the > time it would not have been clear what, if any, policies applied to these > new roots. The applicable CPS during that period [3] makes no reference to > these roots. Google does state in their current CPS that these roots were > operated according to that CPS. > ** From the transfer on 11-August 2016 through the end of Google’s audit > period on 30-September, 2016, these roots were not explicitly covered by > either Google’s audit nor GlobalSign’s audit. However, since Google had > valid WebTrust audits during that period, I believe this is no different > than a CA creating a new root. A counter-argument is that Google prior to > the transfer was not operating publicly-trusted roots and thus should have > undergone a point-in-time audit as if they were a new CA. > > The discussion was concluded with the following statement: > >> > >> https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership >> >> With these changes and the filing of >> https://bugzilla.mozilla.org/show_bug.cgi?id=1347882 , I consider this >> particular discussion RESOLVED. This means Mozilla plans to take no action >> against GTS based on what has been discovered and discussed. It doesn't >> mean people can't continue to make suggestions about improvements to our >> process, citing this situation. >> > > * Earlier this year, Google’s OCSP service was down for over 2 days [4]. > During that time, concerns with Google’s incident reporting mechanism were > raised, but it is not clear that there was ever a policy violation. Google > supplied a fairly detailed incident report. > * The CP is so heavily derived from the BRs that it provides almost no > useful information. It includes repeated references to things that “the CA” > should or must do without clearly identifying Google as “the CA”. > > ==Bad== > NOTE: the issues listed below were addressed by Google after I reported > them, but I am reporting them in the “bad” state in which I originally > found them. > * Version 2.2 of the CPS stated that domain validation method 1 was > performed for OV certificates. It did not state how domain validation is > performed for DV certificates. In addition to the fact that method #1 is > banned after 1-August, I do not believe this meets Mozilla policy section > 2.2: “The CA's CP/CPS must clearly specify the procedure(s) that the CA > employs…”. Google has fixed this issue in CPS version 2.3, although it only > references BR section numbers to “clearly specify the procedures”. > * Section 6.1.1 of version 2.2 of the CPS can be interpreted to state that > the Google CA generates key pairs for its subscribers in violation of > Mozilla policy section 5.2. CPS version 2.3 has corrected this issue. > * The certificate profiles in CPS version 2.2 Appendix A indicated that > TLS certificates can be valid for up to 39 months. Google updated this to a > max validity period of 365 days in version 2.3. > > This begins the 3-week comment period for this request [5]. > > I will greatly appreciate your thoughtful and constructive feedback on the > acceptance of these roots into the Mozilla CA program. > > - Wayne > > [1] https://bug1325532.bmoattachments.org/attachment.cgi?id=8844282 > [2] > https://groups.google.com/d/msg/mozilla.dev.security.policy/1PDQv0GUW_s/oxDWH07VDgAJ > [3] > https://static.googleusercontent.com/media/pki.google.com/en//GIAG2-CPS-1.4.pdf > [4] > https://groups.google.com/d/msg/mozilla.dev.security.policy/MMO3HSYghwQ/XLRuxWtJAwAJ > [5] https://wiki.mozilla.org/CA/Application_Process > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
