Hi, because of recent events with policies of public CAs and associated "fallout" that removed the ability to get publicly trusted certificates with clientAuth for dNSName and ipAddress I've written this early draft of a now standard I'd like to propose. As this breaks any and all mutual TLS authentication between systems relying upon public trusted certificates (like XMPP, AD FS, or SMTP with mutual authentication, like e.g. the Microsoft Exchange Hybrid deployment uses) some solution is required.
Within this draft I basically sharpen the definition of "id-pk-clientAuth" and "id-pk-serverAuth". "id-pk-clientAuth" should no longer be used for dNSName and ipAddress (aka device) certificates and instead a TLS-server should be allowed to accept a "id-pk-serverAuth" certificate. As long as it expects device-to-device authenticated sessions. This should also address the obscure and unspecified "security concerns" the Google Chrome team stated as reason for the policy change that caused any and all CAs to drop issuing clientAuth certificates. Even the ones that still issue certificates with the clientAuth flag set do NOT do so for devices and only for endusers and organizations (EV and OV). Besides that as also Lets Encrypt stopped including the clientAuth flag the only free and publicly trusted certificates available are of type id-pk-serverAuth". Therefore to keep systems relying upon the mutual authentication of TLS between servers operational it is necessary to allow servers to use id-pk-serverAuth certificates for TLS-Client Authentication. In addition I also tried to outline how a server should validate the received TLS certificates. The validation of the client certificate may currently be a bit too verbose and complex. The main goal is to do forward-confirmed reverse DNS lookup, allow for DANE/TLSA provided certificates, as well as services behind SVCB and SRV records (this part may be unnecessary and maybe can be scratched from the draft, I'm not entirely sure). I also provided steps for verifying the source port which may also be unnecessary. I would have hoped that we've more time on this matter, but as the first CAs already stopped issuing such certificate and the commonly used lets Encrypt certificates are not valid that long either this topic is kinda urgend. I'm open to alternative solutions though. It would be great to find some people to push this forward to at least have a standard to move over to. Instead of being left with a bunch of broken services. Sincerely, Klaus Frank Further links for the background of the above referenced policy change: * https://googlechrome.github.io/chromerootprogram/ * https://community.letsencrypt.org/t/do-not-remove-tls-client-auth-eku/237427 * https://github.com/processone/ejabberd/issues/4392 * https://github.com/cabforum/servercert/issues/599 A new version of Internet-Draft draft-frank-mtls-via-serverauth-extension-00.txt has been successfully submitted by Klaus Frank and posted to the IETF repository. Name: draft-frank-mtls-via-serverauth-extension Revision: 00 Title: Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages. Date: 2025-06-16 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-frank-mtls-via-serverauth-extension-00.txt Status: https://datatracker.ietf.org/doc/draft-frank-mtls-via-serverauth-extension/ HTML: https://www.ietf.org/archive/id/draft-frank-mtls-via-serverauth-extension-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-frank-mtls-via-serverauth-extension Abstract: This document aims to standardize the validation of mutual TLS authentication between servers (server-to-server). It outlines recommended validation flows as well as provides practical design recommendations. Basically the EKU id-kp-clientAuth and id-kp- serverAuth get more precisely defined to represent their common understanding by issuing CAs and browsers. id-kp-clientAuth aka. "TLS WWW client authentication" SHOULD mean authentication of a natural or legal entity. id-kp-serverAuth aka. "TLS WWW server authetnication" SHOULD mean authentication of a device. When two id- kp-clientAuth certificates are used this means E2E authentication between two users. Where as two id-kp-serverAuth certificates being used means server-to-server authentication. And one user and one server certificate within one TLS connection means client-to-server (or technically also server-to-client). The term "TLS-Client" SHOULD no longer be used and mean the party sending the initial package while establishing a TLS connection. This helps to avoid design issues moving forward as currently some people thought TLS-Client auth was only ever used in "client-to-server" and never within "server-to-server" context. Which sparked the demand for this document to begin with to keep server-to-server auth with public trusted certificates working. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
