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

[David Benjamin <[e-mail]>]

(As always, wearing an individual hat here. In particular, I am *not*
speaking on behalf of the Chrome Root Program.)

This draft is not the way to solve this problem.

The point of markers like EKUs is to avoid cross-protocol attacks. Client
and server here do not refer to abstract classifications of entities. They
are specific, well-defined roles in the TLS protocol. Whether the TLS
client represents a human or a backend service, it is a client as far as
TLS is concerned. This draft breaks this. TLS stacks that implement it risk
cross-protocol attacks.

As for PKI hierarchies, the Web PKI, as curated by web clients,
authenticates web servers. All the policies and expectations around it,
from monitoring to domain validation to Certificate Transparency, are
maintained with web servers in mind. This blog discusses some of this:
https://blog.mozilla.org/security/2021/05/10/beware-of-applications-misusing-root-stores/

That is not to say that backend services shouldn’t authenticate as TLS
clients with certificates. If a backend service needs to take the role of a
TLS client, a certificate from some PKI is a fine way to solve that. But
there is no reason for that to use the same PKI hierarchies as web server
authentication. You could use entirely private hierarchies, hierarchies
shared across a large class of applications (e.g. all of S/MIME), or
anything in between. As noted elsewhere in this thread, and in the
references you linked, this is the standard way you build applications with
TLS and X.509:
https://github.com/cabforum/servercert/issues/599#issuecomment-2954343849
https://community.letsencrypt.org/t/do-not-remove-tls-client-auth-eku/237427/70
https://community.letsencrypt.org/t/do-not-remove-tls-client-auth-eku/237427/92

Separate hierarchies allow the policies around each to be tailored to the
needs of specific relying parties that support them. In the case of client
and server certificates, they’re already entirely separate roles in the
protocol, so there is no benefit in tying them together.

This goes in both directions. The Web PKI allows a service that speaks HTTP
on port 80 to obtain a certificate. (This is the ACME http-01 challenge.)
That makes sense for web servers. It might not make sense for arbitrary
backend-to-backend applications, where port 80 may be served by a less
trusted process. Web serving and backend-to-backend communication are
different applications, with different needs.

Hope that helps give some background on how TLS uses certificates!

David

On Tue, Jun 17, 2025 at 9:17 AM Klaus Frank
<draft-frank-mtls-via-serverauth-extension=[e-mail]>
wrote:

>
>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>