1325532 - Add Google Root Certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Ryan Hurst]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36

Steps to reproduce:

CA Details
----------

CA Name: Google Trust Services

Website: https://pki.goog 

One Paragraph Summary of CA:

Google Trust Services is run by Google.  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.


This application includes four new root CAs. We have also acquired two roots already in the Mozilla program (GlobalSign R2 and R4), no changes are requested relative to these two roots.


Audit Type (WebTrust, ETSI etc.): 
WebTrust for CA 2.0, BR 2.0

Auditor: 				Ernst and Young USA
Auditor Website: 		http://www.ey.com/  
Audit Document URL(s): 
Web Trust for CAs:	https://cert.webtrust.org/ViewSeal?id=2124
Web Trust BRs: 	   	https://cert.webtrust.org/ViewSeal?id=2125 


Certificate Details Google Trust Services Root R1
--------------------------------------------------

Certificate Name: GTS Root R1
Summary Paragraph:
GTS Root R1 is a Root CA with an RSA key with a 4096 bit long modulus.  It will be used to issue a variety of certificate types via intermediates specific for each certificate type, as defined in our CP and CPS. Initially there will be one intermediate, “GTS X1”. For more information please see attached diagram.

Certificate URL:			https://pki.goog/gtsr1.crt    
Version: 				X.509 v3
SHA1 Thumbprint:            e1:c9:50:e6:ef:22:f8:4c:56:45:72:8b:92:20:60:d7:d5:a7:a3:e8
Public-Key:			(4096 bit)
Not Before:			Jun 22 00:00:00 2016 GMT
Not After :			Jun 22 00:00:00 2036 GMT

CRL URL:				http://crl.pki.goog/gtsr1/gtsr1.crl  
CRL issuance freq.:		At least once a quarter
OCSP URL: 				http://ocsp.pki.goog/gstr1      

Class (DV, IV, OV, or EV):	DV and OV
CP URL:				https://pki.goog/GTS-CP-1.0.pdf      
CPS URL:				https://pki.goog/GTS-CPS-1.0.pdf     
Requested Trust Indicators:	 Website, Email, and Code Signing
URLs of example websites using certificate subordinate to this root (if applying for SSL): 
					https://good.r1demo.pki.goog 
https://revoked.r1demo.pki.goog 
https://expired.r1demo.pki.goog 


Certificate Details Google Trust Services Root R2
--------------------------------------------------


Certificate Name: GTS Root R2
Summary Paragraph:
GTS Root R2 is a Root CA with an RSA key with a 4096 bit long modulus.  It will be used to issue a variety of certificate types via intermediates specific for each certificate type, as defined in our CP and CPS. Initially there will be one intermediate, “GTS X2”. For more information please see attached diagram.

Certificate URL:			https://pki.goog/gtsr2.crt     
Version: 				X.509 v3
SHA1 Thumbprint:            d2:73:96:2a:2a:5e:39:9f:73:3f:e1:c7:1e:64:3f:03:38:34:fc:4d
Public-Key:			(4096 bit)
Not Before:			Jun 22 00:00:00 2016 GMT
Not After :			Jun 22 00:00:00 2036 GMT

CRL URL:				https://crl.pki.goog/gtsr2/gtsr2.crl   
CRL issuance freq.:		At least once a quarter
OCSP URL: 				https://ocsp.pki.goog/gstr2      

Class (DV, IV, OV, or EV):	DV and OV
CP URL:				https://pki.goog/GTS-CP-1.0.pdf      
CPS URL:				https://pki.goog/GTS-CPS-1.0.pdf       
Requested Trust Indicators:	Website, Email, and Code Signing
URLs of example websites using certificate subordinate to this root (if applying for SSL): 
					https://good.r2demo.pki.goog 
https://revoked.r2demo.pki.goog 
https://expired.r2demo.pki.goog 


Certificate Details Google Trust Services Root R3
--------------------------------------------------


Certificate Name: GTS Root R3
Summary Paragraph:
GTS Root R3 is a Root CA with an ECDSA key using secp384r1.  It will be used to issue a variety of certificate types via intermediates specific for each certificate type, as defined in our CP and CPS.  Initially there will be one intermediate, “GTS X3”. For more information please see attached diagram.

Certificate URL:			https://pki.goog/gtsr3.crt     
Version: 				X.509 v3
SHA1 Thumbprint:            30:d4:24:6f:07:ff:db:91:89:8a:0b:e9:49:66:11:eb:8c:5e:46:e5
Public-Key:			ECDSA key using secp384r1
Not Before:			Jun 22 00:00:00 2016 GMT
Not After :			Jun 22 00:00:00 2036 GMT

CRL URL:				https://crl.pki.goog/gtsR3/gtsr3.crl   
CRL issuance freq.:		At least once a quarter
OCSP URL: 				https://ocsp.pki.goog/gstr3      

Class (DV, IV, OV, or EV):	DV and OV
CP URL:				https://pki.goog/GTS-CP-1.0.pdf      
CPS URL:				https://pki.goog/GTS-CPS-1.0.pdf     
Requested Trust Indicators:	Website, Email, and Code Signing
URLs of example websites using certificate subordinate to this root (if applying for SSL): 
					https://good.r3demo.pki.goog 
https://revoked.r3demo.pki.goog 
https://expired.r3demo.pki.goog 


Certificate Details Google Trust Services Root R4
--------------------------------------------------


Certificate Name: GTS Root R4
Summary Paragraph:
GTS Root R4 is a Root CA with an ECDSA key using secp384r1.  It will be used to issue a variety of certificate types via intermediates specific for each certificate type, as defined in our CP and CPS. Initially there will be one intermediate, “GTS X4”. For more information please see attached diagram.

Certificate URL:			https://pki.goog/gtsr4.crt     
Version: 				X.509 v3
SHA1 Thumbprint:            6e:47:a9:c8:8b:94:b6:e8:bb:3b:2a:d8:a2:b2:c1:99
Public-Key:			ECDSA key using secp384r1
Not Before:			Jun 22 00:00:00 2016 GMT
Not After :			Jun 22 00:00:00 2036 GMT

CRL URL:				https://crl.pki.goog/gtsR4/gtsr4.crl   
CRL issuance freq.:		At least once a quarter
OCSP URL: 				https://ocsp.pki.goog/gstr4      

Class (DV, IV, OV, or EV):	DV and OV
CP URL:				https://pki.goog/GTS-CP-1.0.pdf      
CPS URL:				https://pki.goog/GTS-CPS-1.0.pdf     
Requested Trust Indicators:	Website, Email, and Code Signing
URLs of example websites using certificate subordinate to this root (if applying for SSL): 
					https://good.r4demo.pki.goog 
https://revoked.r4demo.pki.goog 
https://expired.r4demo.pki.goog

Comment 1

[Ryan Hurst]

Attachment: GTS PKI Hierarchy.pdf

Comment 2

[Kathleen Wilson]

Francis, Please do the Information Verification for this request.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 3

[Kathleen Wilson]

Ryan, My apologies for the delay in starting the Information Verification for this request due to holidays (December and Chinese New Year). I'm sure Francis will begin Information Verification of this request soon after he returns to the office.

Anyways, I was just looking at https://static.googleusercontent.com/media/pki.goog/en//GTS-CP-1.0.pdf and noticed that it refers to "Effective Date" a lot. But it was not clear to me what the "Effective Date" actually is. Please clarify.

Comment 4

[B]

Is there an ETA on this fix yet?

Comment 5

[Kathleen Wilson]

(In reply to B from comment #4)
> Is there an ETA on this fix yet?

See https://wiki.mozilla.org/CA for the process description.
And note: "It can take as long as two years for a new CA to make it from one end of the process to the other."

Aaron will begin step 4, Information Verification, but we're still waiting for the CA to reply to Comment #3.

and for a response from Google to the questions posted here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/1PDQv0GUW_s/P8kAgEkODwAJ

Comment 6

[David E. Ross]

(In reply to B from comment #4)
> Is there an ETA on this fix yet?

To all those who are impatient for this certificate to be approved and implemented for Gecko-based products:

The presence of a root certificate in the NSS database used by Gecko-based products indicates that users can place some degree of trust in the use of that certificate for secure Web browsing.  For that trust to be valid, the certification authority owning the root certificate must undergo some scrutiny, which takes time.

Further expressions of the need for haste will not speed the process.  Any shortcuts or other measures to hasten the process can only weaken the trust users have in the overall certificate database.

Those who are anxious for these root certificates -- those who already trust them and who have no patience with the Mozilla process for scrutinizing certificate authorities -- can download and install the root certificates themselves.  

Note well:  These are my personal comments.  I do not work for either the Mozilla Foundation or the Mozilla Corporation.  Thus, these comments do not reflect the position of either organization.

Comment 7

[B]

Relevant comments were forwarded to Google's security team to assist.

Comment 8

[Peter Bowen]

(In reply to B from comment #4)
> Is there an ETA on this fix yet?

Is the lack of inclusion causing you a problem?  www.google.com is not currently using certificates that chain to these Google Trust Services CAs, so any errors you are seeing should not be due to this bug.

Comment 9

[Ryan Hurst]

Attachment: Tarsier Key Transference GlobalSign Root R2 and R4 - Final Report

Comment 10

[Ryan Hurst]

Attachment: Report on Management’s Assertion Related to the Key Generation and Key Transference of GTS Root R1, GTS Root R2, GTS Root R3, and GTS Root R4

Comment 11

[Ryan Hurst]

(In reply to Peter Bowen from comment #8)
> (In reply to B from comment #4)
> > Is there an ETA on this fix yet?
> 
> Is the lack of inclusion causing you a problem?  www.google.com is not
> currently using certificates that chain to these Google Trust Services CAs,
> so any errors you are seeing should not be due to this bug.

Peter is right. Though we want very much to have our new roots accepted as part of the Mozilla Root Program, this should not represent a blocking issue at this time. Planning on which root certificates to use when you have so many third-parties who are dependent on you requires long term planning, our guidance for third-parties wanting to trust Google and Alphabet products and services is to use, and periodically ensure the list of roots they use includes those at: https://pki.goog/roots.pem

Comment 12

[Ryan Hurst]

(In reply to Kathleen Wilson from comment #5)
> (In reply to B from comment #4)
> > Is there an ETA on this fix yet?
> 
> See https://wiki.mozilla.org/CA for the process description.
> And note: "It can take as long as two years for a new CA to make it from one
> end of the process to the other."
> 
> Aaron will begin step 4, Information Verification, but we're still waiting
> for the CA to reply to Comment #3.
> 
> and for a response from Google to the questions posted here:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/1PDQv0GUW_s/
> P8kAgEkODwAJ

Thank you Kathleen, I apologize in the delay in answering the questions in that thread. If you check now you will see I have responded now.

Comment 13

[Aaron Wu]

Attachment: CAInformaion_Google_InfoNeeded_20170330.pdf

Comment 14

[Aaron Wu]

Hi Ryan,

Based on the CPS and the information you provided, I've verified and enter into Salesforce for 4 root cases. Please see attachment in Comment#13 and we need your more information input and clarify which marked as "Need Response from CA" and "Need Clarification from CA"


Note:
1. For 'Recommended Practices' please refer to:
https://wiki.mozilla.org/CA:Recommended_Practices#CA_Recommended_Practices
2. For 'Problematic Practices' please refer to:
https://wiki.mozilla.org/CA:Problematic_Practices#Potentially_problematic_CA_practices

Kind regards,
Aaron

Comment 15

[Aaron Wu]

Hi Ryan,

Please also perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ

Please let me know if you have any question, thank you!


Kind regards,
Aaron

Comment 16

[Kathleen Wilson]

I have exchanged email with the auditor and confirmed the authenticity of these two audit statements:

1) Tarsier Key Transference GlobalSign Root R2 and R4 - Final Report Direct Link:
https://bug1325532.bmoattachments.org/attachment.cgi?id=8844281

2) Report on Management’s Assertion Related to the Key Generation and Key Transference of GTS Root R1, GTS Root R2, GTS Root R3, and GTS Root R4 Direct Link:
https://bug1325532.bmoattachments.org/attachment.cgi?id=8844282

Comment 17

[Kathleen Wilson]

Ryan, please respond to Comment #15.

Comment 18

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 19

[kluge]

Attachment: 2017 BR Self Assessment for GTS.pdf

Comment 20

[kluge]

Hi Kathleen and Aaron,

I added the BR Self Assessment as an attachment.

Kind regards,
David

Comment 21

[David E. Ross]

Since at least 19 January 2018 and continuing today, google.com has had a persistent OCSP problem that prevents accessing any Google Web page if OCSP-checking is enabled.  This was reported in the mozilla.dev.security.policy newsgroup.  I will attach an image of the error popup.  

Most significantly, Google seems to lack a reasonable means to report the error.  The only E-mail address in the google.com WhoIs record is [e-mail].  My E-mail to that address with a report of the problem resulted in an automated reply indicating that security issues should instead be reported to [e-mail].  My message to that latter address resulted in an automated reply from [e-mail] that listed a variety of Web addresses for reporting various problems.  Since I refuse to disable OCSP checking and all those Web addresses are for the google.com domain, I consider that response invalid.  

Before this request by Google progresses, I suggest that Google be required to demonstrate that they have a readily-found, public-facing means for individuals to report PKI problems.

Comment 22

[Ryan Sleevi]

David: CAs are required to disclose their problem reporting mechanisms in their CP/CPS. Did you examine the CP/CPS? If not, why not? If so, did you attempt to use that mechanism? This is the same requirement of all CAs, by virtue of the Baseline Requirements.

Comment 23

[David E. Ross]

Attachment: OCSP error popup for google.com

The affected certificate -- Google Internet Authority G2 -- appears to be an intermediate certificate signed by the GeoTrust Global CA root.  If Google cannot properly manage even its intermediate certificate, can it be expected to manage a certification authority and its root certificate?

Comment 24

[David E. Ross]

(In reply to Ryan Sleevi from comment #22)
> David: CAs are required to disclose their problem reporting mechanisms in
> their CP/CPS. Did you examine the CP/CPS? If not, why not? If so, did you
> attempt to use that mechanism? This is the same requirement of all CAs, by
> virtue of the Baseline Requirements.

The OCSP problem appears to be related to an intermediate certificate, not a root.  Thus I do not think Google's CP/CPS would apply.  I raise this issue because it creates a question (at least for me) whether Google can properly operate a certification authority.

Comment 25

[Ryan Sleevi]

(In reply to David E. Ross from comment #24)
> The OCSP problem appears to be related to an intermediate certificate, not a
> root.  Thus I do not think Google's CP/CPS would apply.  I raise this issue
> because it creates a question (at least for me) whether Google can properly
> operate a certification authority.

Then I'm afraid you misunderstand CP/CPSes, as they apply to the hierarchy, and define the set of policies. We can continue this on m.d.s.p., but it does seem that your misunderstanding about how to report problems to CAs - any CA - has lead you to incorrect conclusions, both about responsiveness and what is expected of trusted CAs.

Comment 26

[ryan_hurst]

I have updated the m.d.s.p thread on this incident but given the conversation moved into the bug I wanted to provide the same update here.

The issue has been identified and a fix has been pushed. I have verified the fix personally in several regions but it will take time for the fix to propagate globally.

As for how to contact the Google PKI team or any WebPKI CA, all CAs are required to include contact details in their CPS you can see this detail in our CPS (https://static.googleusercontent.com/media/pki.goog/en//GTS-CPS-2.0.pdf) in sections 4.9.3, 1.5.2 and 2.

Understanding that not all relying parties may be familiar with this practice we also include these contact details in the footer of https://pki.goog.

Additionally, we are actively working on a post-mortem and when it is complete we will share it with the Mozilla community.

Comment 27

[ryan_hurst]

It appears the fix has propagated globally.

Comment 28

[Kathleen Wilson]

I'm beginning to do the Information Verification for this request, and have a question...

Are you requesting the email (S/MIME) trust bit for these root certificates?

If yes, please point me to the sections of the CP/CPS that describe how ownership/control of the email address to be included in the certificate is verified.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control

Comment 29

[ryan_hurst]

Kathleen,

At this time we are not requesting the inclusion of S/MIME. 

We may, at a later date, when our practices are clarified on how we would handle this issuance request this to be added.

Ryan

Comment 30

[Kathleen Wilson]

Attachment: 1325532-CA-Information-April4-2018.pdf

Comment 31

[Kathleen Wilson]

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

Comment 32

[Wayne Thayer]

Ryan: please attach the BR audit report for the period ending on September 30, 2016.

Comment 33

[Wayne Thayer]

I have noted the following concerns with the GTS CPS:
* The CPS states that domain validation method 1 is performed for OV certificates. It does 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…”.
* CPS section 6.1.1 can be interpreted to state that the Google CA generates key pairs for its subscribers in violation of Mozilla policy section 5.2. I suspect this actually a reference to Google as the Subscriber.
* The certificate profiles in CPS Appendix A indicate that TLS certificates can be valid for up to 39 months.

Would you like to update the CPS based on this feedback prior to the public comment period?

Comment 34

[ryan_hurst]

Wayne: Thanks for the review, yes we will attach the audit report for the period ending on September 30, 2016.

As for the changes, we have an updated CP/CPS that is pending, that addresses all of this feedback I think. I would like to publish that before the public audit period if possible.

As for the key generation, yes this is in reference to Google as the subscriber, we will clarify that in the update.


Thank you,

Ryan Hurst

Comment 35

[ryan_hurst]

Wayne,

On 2018-08-01 we published our revised CP/CPS and addresses all of the feedback called out above.

We look forward to the comment period and answering any questions you, or others may have on our practices.

Thanks,

Ryan Hurst

Comment 36

[kluge]

Attachment: GTS - WTBR Report Aug 10.pdf

Comment 37

[kluge]

Attachment: GTS - WTCA Report Sep 30.pdf

Comment 38

[kluge]

Attachment: GTS - WTBR Report Sep 30.pdf

Comment 39

[kluge]

Attachment: GTS - WTCA Report Aug 10.pdf

Comment 40

[kluge]

Wayne, I added the reports as requested. Please let me know if there are any questions.

Comment 41

[Wayne Thayer]

I have begin the discussion period for this request on the mozilla.dev.security.policy forum with 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.

[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

Comment 42

[Wayne Thayer]

The discussion period for this request has ended. Based on the lack of comments [1], I recommend approval of this request.

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/KYwIf67hcMg/3Lt5f_DGDwAJ

Comment 43

[ocdtrekkie]

It is somewhat of a gigantic travesty that the idea of giving a company with unilateral authority to shut down Root CAs (aka, Google's future competitors) the ability to be a Root CA in itself. It seems like the general public (specifically, HN) wasn't aware of this until after the comment period concluded. The severity of this, and the fact that nobody commented, suggests this was nowhere near as public as it should've been.

To my knowledge, Google is responsible to noone but itself. While people have suggested that Google must answer to the CAB with regards to it's Root CA decisions for Chrome or Android, Google's own policy states it "reserves the right" and does not mention the CAB at all: https://www.chromium.org/Home/chromium-security/root-ca-policy While other browsers could choose not to follow along with Google's decision, a Root CA distrusted by Chrome is not a Root CA.

If Mozilla is to demonstrate any concern for freedom and openness on the Internet, it must reject this request, and not allow a company which already can summarily execute members of the Root CA group from being a competitor in that group as well.

Comment 44

[Kathleen Wilson]

(In reply to ocdtrekkie from comment #43)
> It is somewhat of a gigantic travesty that the idea of giving a company with
> unilateral authority to shut down Root CAs (aka, Google's future
> competitors) the ability to be a Root CA in itself. It seems like the
> general public (specifically, HN) wasn't aware of this until after the
> comment period concluded. 

This is under discussion here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/KYwIf67hcMg/lhedV-mTBgAJ

Comment 45

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #44)
> (In reply to ocdtrekkie from comment #43)
> > It is somewhat of a gigantic travesty that the idea of giving a company with
> > unilateral authority to shut down Root CAs (aka, Google's future
> > competitors) the ability to be a Root CA in itself. It seems like the
> > general public (specifically, HN) wasn't aware of this until after the
> > comment period concluded. 
> 
> This is under discussion here:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/KYwIf67hcMg/
> lhedV-mTBgAJ

I believe that this concern has been fully discussed, and that the discussion has concluded.

Comment 46

[Kathleen Wilson]

As per Comment #42, and on behalf of Mozilla I approve this request from Google Trust Services LLC (GTS) to include the following root certificates:

** 'GTS Root R1' (Websites)
** 'GTS Root R2' (Websites)
** 'GTS Root R3' (Websites)
** 'GTS Root R4' (Websites)

I will file the NSS bug for the approved changes.

Comment 47

[Kathleen Wilson]

I have filed bug #1496204 against NSS for the actual changes.