Without weighing in on the merits of the CA/B forum policy change, I agree with what David says below: TLS client and server roles are specific and well-defined, we cannot redefine them just to get around the new certificate issuance policy.
It is true, however, that maintaining secure private PKI for client authentication can be complex/costly and existing services may not have the necessary functionality to issue client certs. Service operators are now scrambling to discover/enumerate scenarios where they depend on client certs chaining to public roots. Cheers, Andrei From: David Benjamin <[email protected]> Sent: Tuesday, June 17, 2025 11:16 AM To: Klaus Frank <draft-frank-mtls-via-serverauth-extension=40frank....@dmarc.ietf.org> Cc: [email protected] Subject: [EXTERNAL] [TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066 (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=40frank....@dmarc.ietf.org<mailto:[email protected]>> 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 -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
