[Standards] Handling of Extended Key Usage extension in certificates

Hi folks, This is (part of) a discussion I had intended to discuss at the summit, but we already had enough topics to fill the time (!) so I guess it's fine. This change primarily affects server-to-server connections, and therefore server developers. I published a blog post recently which covers some of the background and sparked some discussion: https://blog.prosody.im/2026-letsencrypt-changes/ Basically, OpenSSL (and almost certainly other libraries) validate the Extended Key Usage extension in certificates and, by default, forbid the usage of certificates without the clientAuth purpose from being valid at the client side of a connection. It's important not to be confused by the "client" and "server" terminology here: in a server-to-server connection, the initiating server is a "client" from the perspective of TCP, TLS and the application code. Most CAs have been including the clientAuth purpose in their certificates, however new requirements from Google are insisting that they stop doing this by June 2026. For a long time (at least a decade), Prosody has been overriding OpenSSL's default behaviour and permitting only certificates with the serverAuth purpose to be used for authenticating server-to-server connections, regardless of the direction of the connection. It is our belief that this is the correct way to do things. At least one implementation (ejabberd/fast_tls which also uses OpenSSL) was found so far to depend on the clientAuth purpose being present in certificates used on the "client" side of a server-to-server connection. The fix was released in ejabberd 25.08 last year (there are still many out-of-date servers on the network though). Due to diversity in the CA ecosystem, it's not necessarily safe to use certificates with only the clientAuth purpose to authenticate servers. Unfortunately this is documented nowhere in XMPP currently, which can lead to broken federation at best, and security issues at worst. I've submitted a PR to update XEP-0178, which seemed like the most natural fit for specifying this: https://github.com/xsf/xeps/pull/1501 Regards, Matthew