Google CA Root Inclusion Request
groups.google.com
groups.google.com
> 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...
https://static.googleusercontent.com/media/pki.goog//en/GTS-...
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.
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
[1] https://cloudplatform.googleblog.com/2017/09/introducing-man...
Same can be said of other CAs.
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.
Interesting, why would that happen? Why not generate the keys/certs yourself?
This adds another layer of color to that story.
https://news.ycombinator.com/item?id=13494780
This has been brewing for quite a while now.
Every new CA that gets included just amplifies opportunities for coercion and blunder.
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.
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...
(I don't think the scenario as a whole seems likely, but this specific argument is analogous to e.g. concerns about Uber and Lyft competing with taxies on VC-subsidized pricing that will run out one day, or the loss of SF laundromats thanks to laundry startups.)
Although the Google CA, Google's root trust programme, and the Chrome TLS implementation people are three distinct teams at Google, common sentiment among the technically savvy (which would include all three groups) is that EV is either entirely or largely pointless and nobody cares, so it would not make sense to request EV treatment.
Your general thrust is right, there are other things CAs issue that Let's Encrypt does not, but the numbers still tell a story of solid growth even in the Web PKI, Let's Encrypt grew the market considerably, seizing 75% of a market that is now five times bigger than before doesn't squeeze out other people.
And, if its my job to check that box or to make money for a CA, well, that's fine. But, it terms of them actually having a real use, I'd love for someone to tell me what that real use actually is.
For example: https://twitter.com/musalbas/status/1038919152826757122
Having an EV cert for yourwebsite.com does nothing to prevent fishing if people are directed to someotherwebsite.com.someotherwebsite.com. So, whats the point if going through the extra pain / expense of getting one?
Given that he never noticed it, and the fact that I've never heard of anyone else noticing it. I'd say that even when high-profile targets deploy EV, it still does nothing.
A possible exception might be banks. I've heard (I think in the HN comment thread of [1]) of people actually calling up banks asking why the name isn't in the green part of the browser. I know I check that address most often. I guess people are just most security aware when it comes to mixing the internet and money.
[1] https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas...
These "extra" certificates are sold at a premium 1) so CAs can earn more, despite the race to the bottom; and 2) so potential victim companies of data breaches can point to all the "extra" effort (read: money) they invested in security. But they fundamentally do not improve security, because they're predicated on the idea that non-technical end users will use increasingly more sophisticated methods of identity assurance. The software security industry has decades of case studies which demonstrate this is not the case.
Simply put: you can't solve phishing by stuffing more and more authentication signals into a URL bar and a padlock icon. Approximately all users won't even bother to check and most will simply click through warnings. Trying to design better, more "verified" certificates is a clear example of a local maximum. It seizes upon a weak proxy for security against phishing, then tries to optimize further with the bureaucratic scar tissue of identity verification. In so doing it completely loses focus on the core issue.
(Disclaimer: I am a Google employee, but I don't work on any of this.)
Google is a public company and as such they are required to release certain information in annual report, so their investment in the cloud is verifiable.
Not an insider, but TBH, I was always pretty much sure that one of Gmail or Inbox will go away soon. With Gmail having more user base, it was natural for Inbox to be subsumed by gmail.
Inbox was not really fundamentally different from Gmail. It offered some new features, but I can't imagine that it would be too hard to implement them in Gmail too (e.g., snooze feature).
I disagree, and suspect that anyone else that used custom bundles would too.
This guy sums it up well: https://www.androidpolice.com/2018/09/12/google-may-push-peo...
It's much easier than developing and maintaining 2 apps, and testing them on variety of platforms (Web, ios, android etc.) and device/browser combinations.
It was already getting confusing with smart compose (https://www.blog.google/products/gmail/subject-write-emails-...) coming to Gmail, but not to Inbox.
Point being; the only guarantees that any consumers should hold companies accountable to is: Does the product make money, and is it parallel to their conceivable long-term vision? That's literally all that matters. That's the only data consumers can use to decide whether a product will still exist in 10 years.
Google Cloud is this. Its absolutely profitable. And cloud tech is so deep in their DNA, they're literally decades ahead of anyone else. They were running containers and clusterized homogeneous server resource pools 8 years before anyone else knew to call them that, its just taking them time to productize everything they use internally.
Trust money. Trust vision. Don't trust words. G-Suite, Cloud, and Domains are very safe products.
https://news.ycombinator.com/item?id=17997494
No, it wouldn't require them to keep it operating if all of Google was simultaneously destroyed by meteors. But it would probably allow lawsuits against Google if they didn't give the required advance notice merely due to a change in business strategy, without a sufficient reason.
Interestingly, AWS doesn't have that kind of guarantee, though they do have a long public cloud track record of not turning stuff down.
You make a lot of additional good points about why these Google products are safe.
I'm not convinced I'd put Domains in that list, and for G Suite and GCP I'd only put the core services (G Suite jargon) and GA offerings (GCP jargon). Plus some other services under those umbrellas if Google has told you something about their plans under NDA, which they do for many customers.
But Google reliably provides transition plans and data exports if they do turn anything down, and I expect that will continue.
(Disclosure: I formerly worked for Google and GCP in particular, but no more recently than early 2015 and I have no current insider info.)
One year is way too short as well. Enterprise application development does not happen at that speed . Teams and budgets are not readily available to start migration to something equivalent just coz Google felt like it.
Even if that's not a problem migration may not even possible with proprietary APIs. You may have to deprecate entire fearures. If your SLA is longer and reasonable time to your customers, you are screwed.
As an outsider, you would know from the terms of service: https://cloud.google.com/terms/
7.2 Deprecation Policy. Google will announce if it intends to discontinue or make backwards incompatible changes to the Services specified at the URL in the next sentence. Google will use commercially reasonable efforts to continue to operate those Services versions and features identified at https://cloud.google.com/terms/deprecation without these changes for at least one year after that announcement, unless (as Google determines in its reasonable good faith judgment):
(i) required by law or third party relationship (including if there is a change in applicable law or relationship), or
(ii) doing so could create a security risk or substantial economic or material technical burden.
The above policy is the "Deprecation Policy."
If you click through to https://cloud.google.com/terms/deprecation you will see the covered services. (Reasonable good faith is a legal term of art, so no, Google would not get away with whatever silly edge case people come up with)
That isn't the standard listed. It's "substantial economic burden".
None of those services were a substantial economic burden for a many-billion dollar company, so sorry, but i completely disagree.
For smaller companies if something becomes too expensive or hard, they just go out of business. For larger companies, they have to draw the line somewhere. You won't get stronger guarantees from anyone, that would be insane.
Google definitely has a history of turning down free services when they're proving unprofitable, but that's only free services. There's no history of Google turning down paid services without good notice that I know of.
FWIW TLS 1.3 encryption kicks in before the certificates get sent, in either direction, so if you like/ need client certs but worry about confidentiality you should go to 1.3
Oh TLS 1.3 also has nicer filters so you can tell a client "Hi, please send me a client cert, but, I want one that has the following properties based on ASN.1 OIDs" whereas with earlier TLS versions you could only say "Here is the list of Certificate Authorities which I trust to issue client certs, give me any cert you have from one of those CAs".
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.
Whether or not Mozilla, Microsoft, or Apple follow suit, if Google were to chose to distrust a CA, such as they did with Symantec, due to Chrome's 60%+ market share, that CA is out of business, regardless of what any other browser vendor says on the matter. Whether or not the other vendors choose to follow suit doesn't change the fact that the CAB has no legal authority over Google, and Google is a significant majority of the browser market.
Google's going to maintain a root store either way. The parent I replied to was worried that Google becoming a CA would be a power play to eliminate all other CAs and then Google would get out of the business. Apple, Microsoft and Mozilla have the power to drop Google's CA from their root stores and make Google-issued certs worthless on a huge number of devices worldwide, which is how they act as a balance against unilateral moves by Google-the-CA.
I don't think Google would "embrace, extend, extinguish" the CA market though as the parent suggested, the CA system gives Google a massive amount of control of the Internet at large, and I can't fathom them giving it up.
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.
Here's static HTML version:
https://groups.google.com/forum/m/?_escaped_fragment_=topic/...
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...
> 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.
Dan how about you change it to:
> "Customers of the Google PKI are the general public"
From the actual article if you think "Google CA" is too short, or just restore the original title?
Once a thread gets this popular, it's not so title-dependent anyway. Readers will click on the comments and quickly get up to speed with what the article is about.
You're welcome to revert it back to the original title ('Google CA') as you mention.
Also, please don't slight another user like that on HN.
I've put "CA" back in the title above.
Those sentences seem to contradict each other. Let's leave original title ('Google CA') and current title (whatever it is when you read this) as their existing meanings.
The ancestor post said 'Google CA' was misleading despite the article contents saying Google is making a CA. I criticised the action, which deserves criticism, and very specificaly did not criticise the user.
But I don't really want to expend any more energy here and suspect you don't either so let's leave this discussion.
Uh huh.
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)
All we know is it's somthing Cloudflare explicitly claims not to do.
What you'd do is issue a subCA, an intermediate certificate that says whoever has this key is allowed to issue more certificates, then you bake that subCA and the key into a MITM appliance. It mints the leaf certificates, in real time, when a connection happens. At the scale of a medium-sized corporation you can buy this off the shelf from a dozen or more companies, but obviously the off-the-shelf product produces untrustworthy certs.
Usually what a business does is they set Windows Group Policy to say oh, actually we trust these bogus certs. They're supposed to mint a new key for this purpose, but I've seen big companies screw that up and trust the demo keys supplied with the product. This is fine because they're your machines, you set Group Policy. Don't want to trust dubious third rate "MITM appliances" from so-called security companies? Then don't add one in Group Policy.
But if you gave these MITM appliances a "real" publicly trusted subCA they would work, and it would be seamless as far as ordinary Web users are concerned (it's not entirely undetectable, but no ordinary users would notice). It would definitely work for a fair-size company, or a small country. And maybe if you had the hardware and the money you could do it to, say, China, or America.
We know TrustWave issued such a subCA to Walgreens, which caused a big fuss in 2012, and Mozilla told CAs that even though their policies had never specifically forbidden this it was a terrible idea, and they needed to confess and stop doing it. In 2013 the French government was caught doing this too, and their CA root was locked to ccTLDs controlled by France (France owns a bunch of quasi-independent little island nations with TLDs) in Firefox. In 2015 CNNIC did this "by mistake" selling a subCA to a company that, it says, didn't even want a subCA but just somebody screwed up. CNNIC was distrusted.
Untrusted by whom? Let me remind you that Google also owns the most popular browser used to access the web. There are already plenty of websites that don't work in any other browser. So they won't even notice if non-Google browsers suddenly don't trust the certificate anymore.
Yes, it is technically possible for Google to commit corporate suicide.
There are many things which are "technically possible" which are not remotely plausible.