Has anyone actually given a good explanation as to why TLS Client Auth is being removed?

dextercd 11 hours ago | parent | next [-]

It's a requirement from the Chrome root program. This page is probably the best resource on why they want this: https://googlechrome.github.io/chromerootprogram/moving-forw...

▲

10 hours ago | parent | next [-]

[deleted]

▲

0xbadcafebee 7 hours ago | parent | prev [-]

I get why Chrome doesn't want it (it doesn't serve Chrome's interests), but that doesn't explain why Let's Encrypt had to remove it. The reason seems to be "you can't be a Chrome CA and not do exactly what Chrome wants, which is... only things Chrome wants to do". In other words, CAs have been entirely captured by Chrome. They're Chrome Authorities.

Am I the only person that thinks this is insane? All web security is now at the whims of Google?

▲

dextercd 4 hours ago | parent [-]

All major root store programs (Chrome, Apple, Microsoft, Mozilla) have this power. They set the requirements that CAs must follow to be included in their root store, and for most CAs their certs would be useless if they aren't included in all major ones.

I don't think the root programs take these kind of decisions lightly and I don't see any selfish motives they could have. They need to find a balance between not overcomplicating things for site operators and CAs (they must stay reliable) while also keeping end users secure.

A lot of CAs and site operators would love if nothing ever changed: don't disallow insecure signature/hash algorithms, 5+ year valid certs, renewals done manually, no CT, no MPIC, etc. So someone else needs to push for these improvements.

The changes the root programs push for aren't unreasonable, so I'm not really concerned about the power they have over CAs.

That doesn't mean the changes aren't painful in the short term. For example, the move to 45 day certificates is going to cause some downtime, but of course the root programs/browsers don't benefit from that. They're still doing this because they believe that in the long term it's going to make WebPKI more robust.

There's also the CA/Browser Forum where rule changes are discussed and voted on. I'm not sure how root programs decide on what to make part of their root policy vs. what to try to get voted into the baseline requirements. Perhaps in this case Chrome felt that too many CAs would vote against for self-interested reasons, but that's speculation.

▲

mcpherrinm 4 hours ago | parent [-]

The "client cert" requirements were specifically not a CABF rule because that would rule it out for everyone complying with those rules, which is much broader than just the CAs included in Chrome.

Some CAs will continue to run PKIs which support client certs, for use outside of Chrome.

In general, the "baseline requirements" are intended to be just that: A shared baseline that is met by everyone. All the major root programs today have requirements which are unique to their program.

	▲	dextercd 3 hours ago \| parent [-]
		Thanks for chiming in! I remember now that you also said this on the LE community forum. Right, that explains it. So the use would be for things other than websites or for websites that don't need to support Chrome (and also need clientAuth)? I guess I find it hard to wrap my head around this because I don't have experience with any applications where this plus a publicly trusted certificate makes sense. But I suppose they must exist, otherwise there would've been an effort to vote it into the BRs. If you or someone else here knows more about these use cases, then I'd like to hear about it to better understand this.

▲

singpolyma3 11 hours ago | parent | prev | next [-]

Because Google doesn't want anyone using PKI for anything but simple websites

▲

cryptonector 11 hours ago | parent | prev | next [-]

One reason is that the client certificate with id-kp-clientAuth EKU and a dNSName SAN doesn't actually authenticate the client's FQDN. To do that you'd have to do something of a return routability check at the app layer where the server connects to the client by resolving its FQDN to check that it's the same client as on the other connection. I'm not sure how seriously to take that complaint, but it's something.

▲

greyface- 6 hours ago | parent | prev [-]

It competes with "Sign in with Google" SSO.