> 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.
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.
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.
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.
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."
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.
Pretty sure this is fairly old, and pretty sure they are following Amazon's lead...almost literally via copy + paste(as an ode of approval and liking what they are doing)
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.
I think the argument is that existing CAs with mediocre practices are currently profitable, but in the presence of Google competition will stop being profitable and decide to exit, and may not decide to return if Google leaves.
(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.)
Google did not request and were not granted EV treatment for this CA. So even if it mints certificates with an EV OID in them that will get ignored in Firefox.
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.
It would be rational and moral (within Google's own worldview) to sell EV, drive all the other EV sellers out of business, and then stop. It's a lot harder to get into the EV business than into the homeopathy business, so it's not quite comparable to your doctor trying to drive the homeopaths out of business.
It's not a fundamental part of most cryptocurrencies: it suffices to have a private key be able to send and receive money from its own account, without knowing what legal entity controls that account.
It's not a fundamental part of Signal; the cryptosystem only identifies phone numbers, not legal identities. Similarly, it's not a fundamental part of Keybase, which only identifies social media accounts.
It's not a fundamental part of PGP; it's traditional to verify legal identity (and some users have a need for that), but it's not at all required and you can have a pseudonymous key in the strong set pretty easily.
It's not a fundamental part of military encryption, where the legal entity is just "this country's military," but internal distinctions matter.
It's not a fundamental part of Tor, which goes to lengths to lose track of the legal identity of its users.
There are advantages to identifying the legal entity that controls a website, sure, but 99% of the advantage of SSL is identifying a site name so that cookies are only sent to the same site, JavaScript is only accepted from the same site, a bookmark opens only the same site, a link from elsewhere on the web opens only the same site, etc. And in most cases, "legal entity" is just a proxy for "entity I expect". When I visit gmail.com, I'm looking for the entity I previously visited at gmail.com; knowing that gmail.com is now Alphabet instead of Google doesn't really help me, but knowing that it's the same site does. When I register an account in person at First Bank of Springfield and go home to log in, I care less that the website I find is controlled by one of the many First Banks of the many Springfields than that it is the same entity I just signed up for an account with - and I can guarantee that by typing in the https URL they gave me on the welcome brochure.
In cryptocurrencies the desire is often to not tie a legal entity to a wallet, hence digital cash. Likewise Tor, again anonymity may be the entire the purpose. However other mechanisms exist that do exactly this when desired: Tor only uses EV SSL to make sure you're communicating with the legal entity you think you are. At CertSimple we have customers including Privacy International and Buzzfeed that use our Tor EV product for exactly this.
Linking PGP keys to identities is done at most well known universities, as you noted.
Keybase links pubkeys to social media accounts, but that's also the point: a single network endpoint is not a sufficient indicator of identity.
Debian key parties link passports and drivers licenses to pubkeys.
Windows binaries are signed with EV certs.
> I can guarantee that by typing in the https URL they (the bank) gave me on the welcome brochure.
Users will never type in most URLs, let alone every URL.
Who requires these certs? I've always gotten the impression they are useful for 1) checking a box on some form; and 2) making more money for CAs.
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.
Everyone who operates a website with users that can be the phishing targets. Plain certs (DV) only tell you that you are talking to a server that that has been validated to belong to a domain (and the taking is done encrypted).
Extended validation and organization validation (EV and OV) certificates do not solve any technical cause of phishing. They're also poor instruments for attacking the social efficacy of phishing attacks. The phishing demo you linked in that Twitter page is not mitigated by EV or OV certificates.
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.
That assumes that a significant number of people a) know that Google has a EV certificate and b) actually check it. To the first point, I'm not sure that Google actually does have an EV cert - looking at Google.com, I think they just have a DV cert. And to the second point, I suspect that few people actually check if the cert is EV or DV (If they check that the connection is encrypted at all).
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?
There's not a lot of point to EV. Google and eBay don't even EV their primary domains; given what high-profile targets those are for phishing, the fact that they're not EV should tell you something about its utility as an anti-phishing measure.
As per [1], twitter does use EV certs, but not everywhere. It depends on the geographical location. The author of this article (Troy Hunt) never noticed this inconsistency, whilst he works in security.
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.
I recommend this presentation to help dispel a lot of misconceptions about phishing and how easy it is for even highly technically and security literate people to get phished:
If you think EV has magical phishing-prevention sauce, you probably want to do more research on the topic. Especially since browsers are starting to tone down or even remove special visual signifiers for EV certs (since, if EV had incredible anti-phishing power, they wouldn't be doing that).
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.)
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)
This is the best guarantee any company ever gives.
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.
Many of the products Google has already shut down would easily have passed a reasonable good faith judgement that they were too expensive to keep running. I don't see how this would be any different. I know that "reasonable good faith" is a legal term of art, and I'm saying that I don't think Google would struggle to meet that standard if they needed to shut one of these services down.
"Many of the products Google has already shut down would easily have passed a reasonable good faith judgement that they were too expensive to keep running."
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.
What does "protection" and "guarantee" really mean? If a dozen meteors simultaneously strike every Google datacenter and office location, would the products continue to live on, even in the face of every conceivable guarantee their leadership makes before the event?
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.
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.)
AWS likely doesn't have because they don't have the same trust problem Google does. Google likely were loosing from GCP deals because of this, so they put it in there to appease customers.
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.
Hell, I bet there are insiders who were surprised about the decision to close up shop on Google Inbox. There's no guarantee that Cloud and Domains will never be closed, but that's on the level of RIM no longer making Blackberries. Google's a modern Internet company and has bet, and bet big, on being a leading cloud services provider, and Domains are a key component to having a vertically integrated offering.
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.
> Hell, I bet there are insiders who were surprised about the decision to close up shop on Google Inbox.
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 suspect Inbox was never meant to survive. It had small details that prevented mass adoption. For instance, it took them months after launch to implement an automatic signature, and then they added the artificial restriction to only allow them in your gmail.com account, not other accounts like in gmail. This prevented a lot of people whose workplace policy requires a specific signature, me included, from completely ditching gmail.
That article mentions that bundles are supposed to arrive in Gmail soon. My point still stands that Inbox features would be not-so-difficult to add to Gmail.
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.
Wouldn't be surprised if it was related to their new Titan Security Keys. They are advertised as 2-factor authentication devices but they almost certainly have the ability to act as a certificate store. If you have a CA you can start issuing certs to people and drop the password / user name login altogether.
Google has been behind the effort to kill client certificates on the web, though, and as as someone who has run a web host for a large client-cert-using population I think this is a reasonable move: in particular, the protocol doesn't provide confidentiality for client cert data any more than it provides for server cert data, so if your name is in the subject it is sent in the clear which is a huge privacy violation, and there's no obvious way to implement a "logout" button, because auth is tied to SSL. You can work around these things, but at that point it's not obviously better than just doing some auth with WebCrypto (or your own WASM) and localStorage, and the tradeoff of using SSL client certs is that the complexity is inside your SSL layer and not sandboxed to the individual websites.
I happen to like, and have used, mutual authentication (and thus client certs) for B2B HTTPS APIs where the systems at both ends are servers not people or user agents. I agree it's not so great for people.
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".
A logout button could work the same way as with usernames and passwords. Sure you could use the cert to reauth the user with every page load but you could also use a traditional login page you just replace the user / password entry with the certificates and then operate as usual from there. Same with privacy it is all in the implementation details.
A logout button doesn't give extra security if anyone with access to the PC can hit the 'login' button. So unless access to the cert is behind a password there is no useful way to logout using client certs.
The user usually has the option to require a pin be supplied to unlock the hardware token. The advantage to certificates on a hardware token is that they can't be stolen remotely unlike a user name and password which can be compromised on either the user end or service provider end.
i.e., put a cookie on the site, and trust the cookie instead of the cert for all pages except the login one? That leaves you with all the usual problems of cookie-based logins that certs are supposed to solve (revocation, risk of being stolen, etc.), and also if you want to do that you can just put a private key in localStorage and use WebCrypto on the login page. Or with username + no password + FIDO security key as your only factor, if you want a hardware token, or whatever. There's no advantage in using SSL for this.
The point of the hardware token is that the credential never touches the PC. Putting a private key in local storage is no better than a user name and password because it leaves it open to theft. The most common problem that an everyday user faces is either a data breach on the service provider end or a virus / keylogger on their PC. Hardware tokens with certs solve both those problems in terms of account access.
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.
An EFF member has tried to convince me that Google is subject to the whims of the CAB, but failed to explain to me how. Google's Root CA policy doesn't mention the CAB, and specifically provides Google's own authority to remove CAs as it sees fit.
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.
Would Mozilla be able to risk being the browser that can't access Google services? I am not sure that's a realistic scenario for any of the major browser vendors. But arguably if Google's Root CA were never to gain multi-browser support in the first place, they'd never be able to launch their service to begin with.
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.
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.
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.
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.
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.
That makes sense, but since users are disagreeing about what's accurate here, it's probably best that we stick with the original title of the article.
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.
Nobody is actually disagreeing that Google is making a public CA, as it is in the body of the article, and is written by a Google employee. Rather niftich didn't read the article (and is common on HN) and wanted to say thee title wasn't accurate.
You're welcome to revert it back to the original title ('Google CA') as you mention.
> original title is the title of the article. Otherwise anyone could rewrite any title and call theirs the original.
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.
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)
(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.)
>and they would immediately be untrusted for doing so
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.
I agree with your point, though you might be exaggerating their current market share a bit. But Chrome does not make certificate trust decisions on most platforms, so it would certainly be a wild scenario for them to do something like this.
I think your (1) makes it sound like more work than it really is
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.
> 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...