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.
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.
In practice this might just mean that applications designed to use web PKI certs start ignoring the value of the extendedKeyUsage extension. OP says Prosody already does this.
Well, if libraries like OpenSSL check extendedKeyUsage by default but provide an option to disable this, then most apps benefit from more stringent security, but ones like Prosody with unusual use cases can continue to make those use cases work. That doesn't sound like the worst thing in the world, necessarily? (I'm not sure how Prosody actually implemented this, though, or whether OpenSSL actually works that way.)
So that argues against including CAs that don't issue server authentication cerificates. That's somewhat reasonable, although it does put non-browser use cases in an awkward position, since there isn't currently a standard distribution channel for trusted CAs that is independent of browsers.
But prohibiting certs from being marked for client usage is mostly unrelated to that goal because:
1. There are many non-web use cases for certificates that are only used for server authentication. And
2. There are use cases where it makes sense to use the same certificate used for web PKI as a client with mTLS to another server using web PKI, especially for federated communication.
>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.
But this has nothing to do with clientAuth as in this case the payment processor uses a server certificate and terminal connect to the payment processor, not the other way around. So this change would not have prevented this and I don't see what browsers can do to prevent it - after all, the exact same situation would have happened if the payment processors used a HTTPS-based protocol.
Yeah, the more I think about it the more futile this effort starts to look. The industry is investing tons of resources into building and maintaining an open, highly secure PKI ecosystem which allows any server on the public internet to cryptographically prove its identity, and Google wants to try to prevent anyone who's not a web browser from relying on that ecosystem? Seems impossible. The incentives are far too strong.
Google is hoping that after this change other TLS clients will go off and build their own PKI entirely separate from the web PKI, but in reality that would take way too much redundant effort when the web PKI already does 99% of what they want. What will actually happen is clients that want to use web certs for client authentication will just start ignoring the value of the extendedKeyUsage extension. The OP says Prosody already does. I don't see how that's an improvement to the status quo.
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".
Given how ubiquitous LE is, I think people will switch browsers first. non-chrome browsers based on chrome are plenty as well, they can choose to trust LE despite Chrome's choices. Plus, they had a good reason with Symantec, a good reason to distrust them that is. This is just them flexing, there is no real reason to distrust LE, non-web-pki does not reduce security.
GP gave a very good reason that non-web-PKI reduces security, you just refused to accept it. Anybody who has read any CA forum threads over the past two years is familiar with how big of a policy hole mixed-use-certificates are when dealing with revocation timelines and misissuance.
"it's complicated" is not the same as "it's insecure". Google feels like removing this complexity improves security for web-pki. Improving security is not the same as saying something is insecure. Raising security for web-pki is not the same as caliming non-web-pki usage is insecure or is degrading security expectations of web-pki users. It's just google railroading things because they can. You can improve security by also letting Google decide and control everything, they have the capability and manpower. But we don't want that either.
Neither, I meant if enough people panic and stop using chrome, website operators need not worry much. Safari is default on macs, and Edge is default on windows, both can render any website that can't be accessed in Chrome, so it'll make Chrome the browser that can't open half of the websites, instead of half of the websites out there suddenly being incompatible with chrome. The power of numbers is on LE's side.
If they wanted, they absolutely can distrust LE. The trick is to distrust only certificates issued after specific date (technically: with „NotBefore” field after specific point in time), so the certs already issued continue to work for the duration of their validity (until „NotAfter”). That way they can phase out even the biggest CAs. Moreover, they have infrastructure in place and playbook well rehearsed on other CAs already.
Even then, is the message "stop using chrome after this date because half the internet will break" (because where will all those non-paying people go to?), or "stop using LE and start paying someone for a free service"?
I bet google themselves would be scared of anti-trust lawsuits over this. Even if they weren't, i don't think they'll really go so far as to compromise the security of half of the internet just to get their way on this one small improvement.
The point about antitrust lawsuits I concur, but LE is not the only free-as-in-beer ACME. For one, there's ZeroSSL, then Actalis, SSL.com. For some time BuyPass offered free certs, but it does no longer. Last but not least Google itself has Public CA that offers certs over ACME, a fact that I think would be a huge fulcrum for antitrust suit. I would also expect that all other CAs would deploy ACME endpoints to attract at least some part of the cake (note they're in business of being vultures already). So the message will be „go find another CA, here are three examples, sorted randomly like the European first boot UX, just change the URI in certbot config".
Perhaps this shouldn't be left to the CA/B board, it has critical economic impact on many countries, it should be regulated by them?
Either way, I think LE has enough power to at least push-back and see where things fall. continuing to support users can't hurt them, until they truly have no other choice.
> [...] it has critical economic impact on many countries, it should be regulated by them?
This was exactly the point of recent (2024) eIDAS update, which introduced EU Trusted Lists. The original draft was that the browsers were mandated to accept X.509 certs from CAs („TSP”s) accredited in EU by national bodies. Browsers were supposed not to be free to just eject CAs from their root programs for any reason or no reason at all, but in case of infractions they were supposed to report to CAB or NAB that would make the final decision.
Browesers responded by lobbying, because the proposal also contained some questionable stuff like mandatory EV UI, which the browsers rightfully deprecated, and also it wasn't clear if they can use OneCRL and similar alternative revocation schemes for mitigations of ongoing attacks. The language was diluted.
Interestingly though, doesn't this threat become less credible the shorter certificate lifetimes get? Back in the day they could just do this and server admins would figure out how to switch to a new CA the next time they got around to renewing their certificate. Now though that's all automated, so killing a CA will likely nuke a bunch of sites.
This is good point. I think it would still be discounted in favour of suggesting another CAs that users can switch to, but you're right, the promise was that cert management would be hands off, and changing CAs is not hands off in any ACME client that I know of. Best Google could do would be to shift the blame to LE/ISRG, because it was ISRG that promised this automation.
They can do this with certificate transparency other wise CA can sign whatever date they want. But if they collude with CT that can issue rouge certificates for targeted attacks.
Yes, that's all right, there's already a requirement that they submit to one Google CT log and one non-Google CT log. They thought about it already. The playbook I mentioned they've been rehearsing contains specific threat against backdating certs, they say they'll distrust immediately if they detect, and they have means of detecting backdating on significant scale (esp. for LE, where they submit 100% issued certs, not just the subset that is intended for consumption with Chrome).
> 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 an entire new root? Perhaps set up a ACME profile [1] where the requestor could ask for clientAuth if their use case would be helped; the default would be off.
Google would be free to reject with-clientAuth HTTPS server certificates in their browser, but why should they care if a XMPP or SMTP server has a such a certificate if the browser never sees it?
According to Google. Why do they get to dictate this?
Per the current (2.2.2) CAB requirements [1], §7.1.2.10.6, "CA Certificate Extended Key Usage": id-kp-clientAuth is a MAY.
If I was (say) Let's Encrypt I would (optionally?) allow it and dare Google/Chrome to remove my root certificate. Letting bullies get away with this kind of non-sense only encourages them.
Have you been reading the thread? https://news.ycombinator.com/item?id=46952590 there are a lot of reasons why browsers need to care about whether CAs are issuing insecure certificates to XMPP or SMTP servers (or credit card machines)
> […] there are a lot of reasons why browsers need to care about whether CAs are issuing insecure certificates to XMPP or SMTP servers (or credit card machines)
Why does having the clientAuth capability make a certificate "insecure"?
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.
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.
As a general rule in cryptography, a lot of vulnerabilities relate confusing the system by using a correct thing in the wrong context. Making it a rule that you have to use separate chains for separate purposes is a good rule from a general design standpoint.
> Making it a rule that you have to use separate chains for separate purposes is a good rule from a general design standpoint.
No it's not. It's a specific argument, that's true only in specific cases. You shouldn't handle knives, is equally a good rule from a general design standpoint. But nonsensical when you're a chef.
You should have separate chains is a reasonable decision when the ability to rotate out a compromised chain, and insulate some downtime, from other chains/usages is desirable. Needing to manage multiple cert chains is more overhead. Making use or maintenance harder. It increases complexity.
Large companies have never been afraid of more overhead. It's their singular advantage.
Removing features someone is using, and calling it better security, when it doesn't actually meaningfully reduce or remove some risk is weaponized incompetence. And sufficiently advanced incompetence, is....
There's no world where anyone gains additional protection, from a 3rd party compromise. Or one where LE has one of chains compromised, but doesn't rotate all of them.
Except we didn't get a separate chain - all we got is that from now on software will just ignore the "client" flag and accept the "server" flag for client purposes, adding one more hack onto the pile of hacks that is the Internet.
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).
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.
Google didn't drag anyone anywhere without LE though.
Sure, they supported the nascent HTTPS very early on, but most of the web thought that certificates were "too expensive for the likes of us", and so only really banks and the like actually adopted HTTPS. Most of the internet was still HTTP only for years after HTTPS was available.
Only when LE came along and started offering free certificates and facilitated a massive uptake in HTTPS websites were Google ever in a position to default to marking HTTP as "insecure and dangerous".
I've got no figures, but I suspect that if LE were to kick their heels in, that Google wouldn't dare risk half the internet not working using their browser. I'm sure that would be some people who didn't want to be collateral damage if there was a standoff and would switch to a CA that complied with Google's will, but I suspect most people would be happy to see Google challenged on this. And end users would hopefully discover that every other browser still worked, just Chrome had broken, and Chrome would quite rapidly fall out of favour.
While google did do a lot of work on making https by default be a thing, that is only a small part of what im refering to. Google did huge amount of work to make https high quality, so that sites using it were actually secure. They increased standards for CAs significantly, took a much tougher line on CAs who violated the rules, pushed certificate transparency hard (which is probably one of the most important developments for security of TLS ecosystem). Chrome was the first browser to support HSTS which is very important for https to work in practise. Google maintains the hsts preload list.
Google didn't just make TLS popular, they made it secure.
It's how it should work but the supposed CA browser "forum" has become a browser dictatorship. While there have been issues where CAs were dragging their feet, just letting Google dictate whatever they want is not the solution.
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.
The German NSA intercepted the jabber.im server with a physical interposer device, issued themselves an LE certificate and MITMed this service for months
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.
The CA/B is basically some Apple and Google people plus a bunch of people who rubber stamp the Apple and Google positions. Everyone is culpable and it creates a self-fulfilling process. Everyone is the expert for their company's certificate policy so nobody can tell them it's dumb and everyone else can say they have no choice because the CA/B decided it.
Even Google and Apple from a corporate level likely have no idea what their CA/B reps are doing and would trust their expertise if asked, regardless of how many billions of dollars it is burning.
The CA/B has basically made itself accountable to nobody including itself, it has no incentives to balance practicality or measure effectiveness. It's basically a runaway train of ineffective policy and procedure.
The real takeaway is that there's never been a lot of real thought put into supporting client authentication - e.g. there's no root CA program for client certificates. To use a term from that discussion, it's usually just "piggybacked" on server authentication.
Imho because to put both into a certificate just by convention (or what was the reason to still do it?) is for a CA that has the webpki in scope is not best practice.
From experience people are often misleading the client authentication part as a substitute for user authentication what you simply don't get and than they are surprised that anyone with the certificate can login...
Yeah people with knowledge should know the difference but I have seen this way too many times...The thing I really see LE is problematic is the topic of revocation. Yes revocation is broken but the only working mechanism with ocsp stapling was brought to the graveyard (aka made optional by the cab) with the argument of data privacy issues under the normal ocsp umbrella...Yeah back to CRLs/proprietary browser revocation mechanisms such as CRLsets (https://www.grc.com/revocation/crlsets.htm#:~:text=What%20is...) combined with CTlogs as a reactive measure that simply don't work in practice/are too slow (e.g. remember the Fina CA/Cloudflare incident and the time it went unnoticed).
I have the feeling the driver for LE were rather the costs than the data privacy arguments brought up.
