Google has recently imposed a rule that CA roots trusted by Chrome must be used solely for the core server-authentication use case, and can't also be used for other stuff. They laid out the rationale here: https://googlechrome.github.io/chromerootprogram/moving-forw...
It's a little vague, but my understanding reading between the lines is that sometimes, when attempts were made to push through security-enhancing changes to the Web PKI, CAs would push back on the grounds that there'd be collateral damage to non-Web-PKI use cases with different cost-benefit profiles on security vs. availability, and the browser vendors want that to stop happening.
Let's Encrypt could of course continue offering client certificates if they wanted to, but they'd need to set up a separate root for those certificates to chain up to, and they don't think there's enough demand for that to be worth it.
Why can't Let's Encrypt push-back on this for their users' sake? What is Google going to do? distrust LE certs?
Google Chrome (along with Mozilla, and eventually the other root stores) distrusted Symantec, despite being the largest CA at the time and frequently called "too big to fail".
>when attempts were made to push through security-enhancing changes to the Web PKI, CAs would push back on the grounds that there'd be collateral damage to non-Web-PKI use cases
Do you (or anyone else) have an example of this happening?
After the WebPKI banned the issuance of new SHA-1 certificates due to the risk of collisions, several major payment processors (Worldpay[1], First Data[2], TSYS[3]) demanded to get more SHA-1 certificates because their customers had credit card terminals that did not support SHA-2 certificates.
They launched a gross pressure campaign, trotting out "small businesses" and charity events that would lose money unless SHA-1 certificates were allowed. Of course, these payment processors did billions in revenue per year and had years to ship out new credit card terminals. And small organizations could have and would have just gotten a $10 Square reader at the nearest UPS store if their credit card terminals stopped working, which is what the legacy payment processors were truly scared of.
The pressure was so strong that the browser vendors ended up allowing Symantec to intentionally violate the Baseline Requirements and issue SHA-1 certificates to these payment processors. Ever since, there has been a very strong desire to get use cases like this out of the WebPKI and onto private PKI where they belong.
A clientAuth EKU is the strongest indicator possible that a certificate is not intended for use by browsers, so allowing them is entirely downside for browser users. I feel bad for the clientAuth use cases where a public PKI is useful and which aren't causing any trouble (such as XMPP) but this is ultimately a very tiny use case, and a world where browsers prioritize the security of ordinary Web users is much better than the bad old days when the business interests of CAs and their large enterprise customers dominated.
[1] https://groups.google.com/g/mozilla.dev.security.policy/c/RH...
[2] https://groups.google.com/g/mozilla.dev.security.policy/c/yh...
[3] https://groups.google.com/g/mozilla.dev.security.policy/c/LM...
This sounds a lot like the "increasing hostility for non-web usecases" line in the OP.
In theory, Chrome's rule would split the CA system into a "for web browsers" half and a "for everything else" half - but in practice, there might not be a lot of resources to keep the latter half operational.
It is really great how they write "TLS use cases" and in fact mean HTTPS use cases.
CA/Browser Forum has disallowed the issuance of server certificates that make use of the SRVName [0] subjectAltName type, which obviously was a server use case, and I guess the only reason why we still are allowed to use the Web PKI for SMTP is that both operate on the server hostname and it's not technically possible to limit the protocol.
It would be perfectly fine to let CAs issue certificates for non-Web use-cases with a different set of requirements, without the hassle of maintaining and distributing multiple Roots, but CA/BF deliberately chose not to.
[0] https://community.letsencrypt.org/t/srvname-and-xmppaddr-sup...
I’m disappointed that a competitor doesn’t exist that uses longevity of IP routing as a reputation validator. I would think maintaining routing of DNS to a static IP is a better metric for reputation. Having unstable infrastructure to me is a flag for fly by night operations.
Well, be prepared for certificates that change every 7 to 47 days, as the Internet formally moves to security being built entirely on sand.
I wonder if this is a potential "off switch" for the internet. Just hit the root ca so they can't hand out the renewed certificates, you only have to push them over for a week or so.
People will learn to press all the buttons with scarry messages to ignore the wrong certificates. It may be a problem for credit cards and online shopping.
HSTS was specifically designed to block you from having any ignore buttons. (And Firefox refuses to implement a way to bypass it.)
But this is also why the current PKI mindset is insane. The warnings are never truly about a security problem, and users have correctly learned the warnings are useless. The CA/B is accomplishing absolutely nothing for security and absolutely everything for centralized control and platform instability.
Isn't LE used for half the web at this point?
Calling Google's bluff and seeing if they would willingly cut their users off from half the web seems like an option here.
That's not how this would work.
Based on previous history where people actually did call google's bluff to their regret, what happens is that google trusts all current certificates and just stops trusting new certs as they are issued.
Google has dragged PKI security into the 21st century kicking and screaming. Their reforms are the reason why PKI security is not a joke anymore. They are definitely not afraid to call CA companies bluff. They will win.
How is "client certificates forbidden" in any way an improvement?
Not forbidden, just not going to be a part of WebPKI.
It's one of those things that has just piggybacked on top of WebPKI and things just piggybacking is a bad idea. There have been multiple cases in the past where this has caused a lot of pain for making meaningful improvements (some of those have been mentioned elsewhere in this thread).
What exactly do you mean with "WebPKI"?
The PKI system was designed independently of the web and the web used to be one usecase of it. You're kind of turning that around here.
The current PKI system was designed by Netscape as part of SSL to enable secure connections to websites. It was never independent of the web. Of course PKIs and TLS have expanded beyond that.
"WebPKI" is the term used to refer to the PKI used by the web, with root stores managed by the browsers. Let's Encrypt is a WebPKI CA.
The idea of a PKI was of course designed independently, there are many very large PKIs beyond WebPKI. However the one used by browsers is what we call WebPKI and that has its own CAs and rules.
You're trying to make it sound like there has ever been some kind of an universal PKI that can be used for everything and without any issues.