top | item 17996949

Google CA Root Inclusion Request

155 points| nailer | 7 years ago |groups.google.com | reply

112 comments

order
[+] scrollaway|7 years ago|reply
https://bugzilla.mozilla.org/show_bug.cgi?id=1325532

> 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.

Finding the "email" bit interesting. All this makes a lot of sense, and I'd say I'm surprised this didn't come sooner but the initial issue was filed 2 years ago, and they must have worked on this for several years already then.

As an aside this is a fascinating glimpse into what it takes to run a (serious) CA. https://static.googleusercontent.com/media/pki.goog/en/GTS-C...

[+] geofft|7 years ago|reply
Comments 28 and 29 confirm that they don't intend to sign email (S/MIME) certs for now, and the PDF from Mozilla in comment 30 says "Mozilla Trust Bits: Websites" and "Mozilla is no longer accepting requests to enable the Code Signing trust bit.", so I think the intent is only to sign websites for now.

That sentence happens to list of four of the six standardized uses of certificates (RFC 5280 section 4.2.1.12; the other two are timestamping and OCSP responses) so I think that's just copied-and-pasted from somewhere. Somewhat poor form to copy-and-paste that if they don't mean it IMO, but it's just prose, not the technical part of the submission.

[+] zokier|7 years ago|reply
I wouldn't read too much into the email part, that is pretty standard thing that pretty much all CAs do. I wouldn't expect Google to pursue email certificates in a major way. It's more like ticking a checkbox in the application and leaving that door open if the need arises. Also might be just some legacy from GlobalSign.
[+] walterbell|7 years ago|reply
Remember there is an AMP proposal for certificates to replace DNS for web site identity. In that scenario, Chrome would stop showing URLs and would only show the human-readable identity that signed the page, as validated by a certificate.

This would allow signed site pages to be navigated offline or replicated widely or blacklisted :( There is a risk that Content IDentity would factor into EU upload filters and "link" taxes.

History and Chrome demo video: https://news.ycombinator.com/item?id=17920720#17923156

[+] geofft|7 years ago|reply
Why is there more risk of sites being blacklisted with this model than with existing mechanisms? Google Safe Browsing can always ban your site. If you say "But people can turn off Safe Browsing," I'll counter with "But people can install their own CA."
[+] andrewstuart|7 years ago|reply
The recent flow of "Google is closing this service", followed by "Google is launching this new service" feels weird.
[+] anfilt|7 years ago|reply
I really hate the current system of CAs. Google may act trust worthy, but I personally don't trust them.

Same can be said of other CAs.

[+] dagenix|7 years ago|reply
So? Many people hate the current system. Its not clear that anyone has a better idea.
[+] nsgi|7 years ago|reply
Now that we have Certificate Transparency you have much less need to trust them. Starting from scratch with a new system at this point would be a massive undertaking, all to attempt to solve a problem which has been largely fixed by CT.
[+] dredmorbius|7 years ago|reply
Thoughts occurring to me: browser devs (Chrome, Firefox, Safari, Edge) aready serve as a link in the CA trust chain, in that they can decert a CA.

Browser dev as CA cuts out the middle man.

Cutting out the midddle man removes a check on bad CA behaviour.

I'm not sure where I stand on this, though I'm somewhat concerned.

[+] exabrial|7 years ago|reply
> These 4 roots were created by GlobalSign and then transferred to Google.

Interesting, why would that happen? Why not generate the keys/certs yourself?

[+] nailer|7 years ago|reply
Cross signing allows support from older root stores.
[+] acidtrucks|7 years ago|reply
I wish x509 certificates had several CA signings. I would feel better n times better about a peer who has n unique validations.

Every new CA that gets included just amplifies opportunities for coercion and blunder.

[+] jhabdas|7 years ago|reply
Is it just me or is Google Groups starting to look not much sleeker than the forums people used to self-host back in the mid-2000's?
[+] zitterbewegung|7 years ago|reply
Step One: Google becomes a CA with a large fanfair and covered in every tech blog

Step Two: Google's entry makes the incumbents either decide to exit the space or change their bad behavior

Step Three: Google exits the space accomplishing their mission and screwing over whoever uses their services.

I really hope that it doesn't end like above but I think this will go the way of Google Fiber. Or maybe this is a play for their cloud services to also have be a CA like Amazon.

[+] magicalist|7 years ago|reply
> Step Two: Google's entry makes the incumbents either decide to exit the space or change their bad behavior

Yes, we wouldn't want the price of certificates to enter a race to the bottom. Let's Encrypt relies on that revenue!

Honestly these comments...

[+] jchw|7 years ago|reply
Yeah I doubt this. I don't know what exactly Google's PKI will be for but to me this seems like a close relative of Google Cloud (esp. DNS) and Google Domains. Also, similar infrastructure services from Google, like Google's public DNS resolver, show no signs of being turned down.

(Disclaimer: I am a Google employee, but I don't work on any of this.)

[+] ubernostrum|7 years ago|reply
The power play in the CA world has already happened, with the major browser and operating-system vendors -- using their position as gatekeepers of the root certificate stores for the overwhelming majority of devices as leverage -- working to clean up a lot of the historical bad behavior.

Also, any unilateral move by Google would have to get past the rest of the CAB, which includes Apple, Microsoft and Mozilla, who all control significant root certificate stores.

[+] Dylan16807|7 years ago|reply
I don't understand why step 2 would happen, but burning off 90% of the existing roots would be a good thing.
[+] sjellis|7 years ago|reply
Now that SSL is effectively mandatory for every HTTP application, cloud providers will all either have to become CAs, or integrate with an external CA like Let's Encrypt.

The existence of LE provides an alternative to commercial and potentially hosting-specific CAs, so a Google CA isn't going to wreck the market. Except for the existing commercial providers who change large fees for not much.

[+] rodgerd|7 years ago|reply
Next: Chrome and Search privilege Google CA over others.
[+] psergeant|7 years ago|reply
Clicking on this is asking me to sign in...?
[+] geofft|7 years ago|reply
It's Google Groups, which has weird behavior if you're somehow associated with a G Suite account that doesn't have Groups enabled. (My employer has some weird G Suite integration that prevents viewing public Google Docs, which has caused me to notice a few websites that are secretly just iframed Google Docs exports....) Try incognito/private browsing mode perhaps.
[+] adtac|7 years ago|reply
Do you have JavaScript disabled? Don't you know we need JS to view nearly static mailing lists with minimal user interaction in 2018? /s
[+] niftich|7 years ago|reply
This submission's title was editorialized by the submitter. It was submitted as "Google CA", which is misleading, as the submission is about the preexisting Google CA's addition as a root CA in the Mozilla trust store. The article's underlying title is the more descriptive 'Google Trust Services Root Inclusion Request'.

The Mozilla bugzilla issue [1] contains a more thorough picture of the process that went into considering these root CAs for inclusion in the Mozilla trust store, while the originally submitted URL [2] is focused on summarizing some of the background and rationale and inviting public comment.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1325532 [2] https://groups.google.com/forum/m/#!topic/mozilla.dev.securi...

[+] geofft|7 years ago|reply
Except that the application in the article contains the following statement:

> 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 is not currently true of the existing Google root, and "Google CA" seems like an accurate-enough way of describing this change.

[+] dang|7 years ago|reply
Ok, we've changed the title to that of the page.
[+] ddtaylor|7 years ago|reply
> Section 1.4.2 of the CPS expressly forbids the use off Google certificates for “man-in-the middle purposes”

Uh huh.

[+] peterwwillis|7 years ago|reply
Two things which I think are technically possible with Google as a CA (please correct me if I'm wrong):

1) Google's new business in China enables Google to give China tools to inspect TLS traffic of arbitrary sites that use Google CA-derived certs

2) Google becomes a competitor to CloudFlare and uses position as CDN to inspect all encrypted traffic for data to mine, and then uses data to make more ad revenue (the way it does now with Gmail, search, etc)

[+] iancarroll|7 years ago|reply
(1) is not technically possible unless Google issues new certificates for each site they want to inspect, and they would immediately be untrusted for doing so. (Admittedly, a CA did this once and is still alive, but they came very close to getting axed.)
[+] vatueil|7 years ago|reply
> technically possible

Yes, it is technically possible for Google to commit corporate suicide.

There are many things which are "technically possible" which are not remotely plausible.

[+] zackbloom|7 years ago|reply
(which is something Cloudflare explicitly does not do)