As discussed previously, Let's Encrypt issues certificates with ExtKeyUsage=Server,Client: extendedKeyUsage "TLS Client Authentication" in TLS server certificates
What's not clear from said thread or the relevant RFCs (RFC 8555 - Automatic Certificate Management Environment (ACME) and RFC 8737 - Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension) is why the existing ACME challenge types are an insufficient proxy for ExtKeyUsage=clientAuth.
I'm interested in hearing the community's approach to rationalizing the above, beyond historical tradition, and if anyone is actually using it for client auth.
Consider that there are two types of usable LE/ACME identifiers for client auth: DNS or IP (here we're assuming that wildcard DNS likely doesn't matter from a client auth perspective).
IF a public CA were to be used as a Client Auth (and we'll use, as some suggested, SMTP server<->server message protection as an example), it's not clear what the server's validation model on the client certificate would be: would one blindly accept any certificate? Would one attempt to validate identity via the network layer, e.g., matching IP SAN->client origin IP or doing a (reverse) DNS lookup (from client IP -> hostname or DNS SAN->client IP)? &c.
Now consider how this certificate was obtained and what that implies for this example (TLS for a non-HTTPS protocol):
If dns-01 challenges were used, the requesting ACME client could have no direct relationship to the client that would use these credentials, but such is DNS. This does not imply the existence of any other tenant services on this host, but doesn't preclude them.
If tls-alpn-01 or http-01 were used, a direct connection to the server must've been made, but only to a HTTP server! This implies the existence of some other tenant, whether temporary (e.g., a standalone ACME client) or persistent (e.g., a long-term nginx instance, perhaps serving unrelated content under the same domain). Admittedly, all three of ports 80, 443, and 465 are privileged to bind to, so if the operator is running distinct web and mail services (which should not have cross-permissions to impersonate each other) they have arguably made a mistake. If they're e.g., hosting a webmail instance alongside their SMTP server, this might make some sense, but still might arguably be nice to separate the webmail service's certificate's capabilities from the SMTP service's cert (server-only in the former case and client+server in the latter) to prevent misuse.
In any case, presently a certificate for e.g., a parallel web service could be used to impersonate a certificate given to the e.g., SMTP service which has legitimate use cases for client authentication.
Regardless, at least from my view, neither challenge type can truly validate that client usage is allowed: the latter two (tls-alpn-01 and http-01) strictly validate that a server is present and serving the challenges -- which IMO, does not justify clientAuth usage -- with http-01 even following redirects to potentially non-authoritative systems. And in the former case (dns-01), the service itself isn't contacted, so presumably a stronger authentication onus would be on the server to validate the peer's presented certificate.
It seems in general like future support for the End User challenge types (in draft presently: ACME End User Client and Code Signing Certificates) would be the correct approach here, with perhaps a characterization that existing challenge types might not be sufficient to fully justify ExtKeyUsage=clientAuth.
In short, the protocol which is used to (correctly) justify server usage may not be the protocol or service using client auth and it may not be desirable for it to have client auth permissions.
My interest here, in the matter of disclosure, is that we've recently added support for ACME to Hashicorp Vault, eliding ExtKeyUsage=clientAuth, under the opinion that the existing challenges are not a sufficient characterization of these capabilities. I'm mostly curious to explore if any thought has been given to ACME's influence on key usage capabilities as I've been unable to find much literature on the subject.
As an aside, I think there is a use case here for (potentially cross-tenant) microservice authentication when reliance on public CAs are sufficient; when a service is uniquely identified via a 1:1 correspondence to DNS records, and proper restrictions around client auth are used, using ACME challenges for this is OK. But I don't think this is generally an acceptable (i.e., public internet for all consumers) thing to do more broadly.