[TLS] I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066

[Klaus Frank <[e-mail]>]

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.