You are correct, and the answer is - no-one using publicly-trusted TLS certs for client authentication is actually doing any authentication. At best, they're verifying the other party has an internet connection and perhaps the ability to read.
It was only ever used because other options are harder to implement.
It seems reasonable for server-to-server auth though? Suppose my server xmpp.foo.com already trusts the other server xmpp.bar.com. Now I get some random incoming connection. How would I verify that this connection indeed originates from xmpp.bar.com? LE-assigned client certs sound like a good solution to that problem.
> It seems reasonable for server-to-server auth though? Suppose my server xmpp.foo.com already trusts the other server xmpp.bar.com.
If you already trust xmpp.foo.com, then you probably shouldn't be using PKI, as PKI is a complex system to solve the problem where you don't have preexisting trust. (I suppose maybe PKI could be used to help with rolling over certs)
Which is almost exactly why WebPKI doesn't want to support such use-cases. Just this EKU change alone demonstrates how it can hinder WebPKI changes.
Can you point out, at which point in time exactly, the public TLS PKI infrastructure has been reduced to WebPKI?
Can you point out at which point in time exactly it was designed to serve every use-case?
The public TLS PKI was never supposed to serve every use case and you know it. But let me point out when it was possible to get a public CA certificate for an XMPP server with SRVname and xmppAddr:
Ironically, this was the last server certificate I obtained pre-LetsEncrypt.So you understand that there are different purposes as well. Are you saying that you can't get a client auth certificate any more?
Huh? The entire purpose of that EKU change was to disallow that usecase. How did that demonstrate problems for WebPKI?
This post here is the demonstration, that some non-WebPKI purpose is causing issues and complaints. This has happened before with SHA-1 deprecation. WebPKI does not want this burden and should not have this burden.
Ok, so this is an official split of "WebPKI" and "everything else PKI" then?
Last time I checked, Let's Encrypt was saying they provide free TLS certs, not free WebPKI certs. When did that change?
That's being overly pedantic. PKIs for different purposes have been separate for a while, if not from the start. LE is still giving you a "TLS cert".