What is the lack of pragmatism you are talking about?

There might be some confusion here, as there is no refusal at all.

As stated in the blog post, we (Prosody) have been accepting (only) serverAuth certificates for a long time. However this is technically in violation of the relevant RFCs, and not the default behaviour of TLS libraries, so it's far from natural for software to be implementing this.

There was only one implementation discovered so far which was not accepting certificates unless they included the clientAuth purpose, and that was already updated 6+ months ago.

This blog post is intended to alert our users, and the broader XMPP community, about the issue that many were unaware of, and particularly to nudge server operators to upgrade their software if necessary, to avoid any federation issues on the network.

Sorry, I probably misunderstood, I thought there were resistance to update the corresponding specs. I understand that non XMPP specs might refuse to be updated, but at least this behavior could be standardized for XMPP specifically.

Yeah, the resistance is outside the XMPP community. However we have a long history of working with internet standards, and it's disappointing to now be in an era where "the internet" has become just a synonym for "the web", and so many interesting protocols and ideas get pushed aside because of the focus on browsers, the web and HTTPS.

A common saying in the IETF is "there is no protocol police."

You don't have to do what the RFC says.

The article literally talks about how one of the server implementations does exactly that:

> Does this affect Prosody?

> Not directly. Let’s Encrypt is not the first CA to issue server-only certificates. Many years ago, we incorporated changes into Prosody which allow server-only certificates to be used for server-to-server connections, regardless of which server started the connection. [...]

It is not pragmatic to design your protocol for web use cases when it's not the web.

On the contrary, setting up a separate PKI for XMPP would be what is not pragmatic or even feasible at all. The pragmatic choice is to make use of the options available even if some people find them icky.

Unless im missing something, this is a poor design full stop. How are they validating SAN on these client certificates?

XMPP identifiers have domain names, so the XMPP server can check that the DNS SAN matches the domain name of the identifiers in incoming XMPP messages.

I've seen non-XMPP systems where you configure the DNS name to require in the client certificate.

It's possible to do this securely, but I agree entirely with your other comment that using a public PKI with client certs is a recipe for disaster because it's so easy and common to screw up.