Hello Jonathan & Yaroslav, Thank you for working on this topic! I'm very interested in it as it addresses a concrete challenge workload developers face today. Now, when hosting a server they need to decide whether they want to offer it using a WebPKI certificate or a Workload Identity Certificate. Often they end up hosting it on 2 separate endpoints, which brings deployment burden, or they solve client authentication higher up the stack, giving up on mTLS. This draft would allow them to satisfy both groups of clients on the same endpoint reducing complexity and deployment burden.
A more concrete example I have in my head is the Ingress Controller pattern in Kubernetes. Workloads that want to perform client authentication using mTLS are in conflict with workloads that want to host APIs to the public, including clients that would struggle processing a CertificateRequest message. Kind regards, Arndt PS: Even more concrete and this is just a guess: I can imagine that this is the reason OpenAI is serving mTLS client authentication at https://mtls.api.openai.com and not on their usual API endpoint. Correct me if I'm wrong but this draft could have prevented that. (Ignoring potential secondary decision points they may have had). On Mon, Jul 7, 2025 at 5:52 PM Jonathan Hoyland <[email protected]> wrote: > Hi WIMSE and TLS, > > We've just published > https://datatracker.ietf.org/doc/draft-rosomakho-tls-wimse-cert-hint/. > We'd like > to get feedback from the group about doing client trust anchor negotiation > in > the TLS handshake. > > This should enable efficient use of client authentication in TLS when a > server > accepts clients both with and without client certificates. Sending a > CertificateRequest to clients that aren't expecting it can break > connections, so > this enables a server to only serve `CertificateRequest`s that it expects > the > client to be able to satisfy. > > Regards, > > Jonathan and Yaroslav > > ---------- Forwarded message --------- > From: <[email protected]> > Date: Mon, 7 Jul 2025, 17:20 > Subject: New Version Notification for > draft-rosomakho-tls-wimse-cert-hint-00.txt > To: Jonathan Hoyland <[email protected]>, Yaroslav Rosomakho < > [email protected]> > > > A new version of Internet-Draft draft-rosomakho-tls-wimse-cert-hint-00.txt > has > been successfully submitted by Yaroslav Rosomakho and posted to the > IETF repository. > > Name: draft-rosomakho-tls-wimse-cert-hint > Revision: 00 > Title: Workload Identifier Scope Hint for TLS ClientHello > Date: 2025-07-07 > Group: Individual Submission > Pages: 7 > URL: > https://www.ietf.org/archive/id/draft-rosomakho-tls-wimse-cert-hint-00.txt > Status: > https://datatracker.ietf.org/doc/draft-rosomakho-tls-wimse-cert-hint/ > HTML: > https://www.ietf.org/archive/id/draft-rosomakho-tls-wimse-cert-hint-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-rosomakho-tls-wimse-cert-hint > > > Abstract: > > This document defines a TLS extension that allows clients to indicate > one or more workload identifier scopes in the ClientHello message. > Each scope consists of a URI scheme and trust domain component, > representing the administrative domain and identifier namespace in > which the client operates. These identifier scopes serve as hints to > enable the server to determine whether client authentication is > required and which policies or trust anchors should apply. This > mechanism improves efficiency in mutual TLS deployments while > minimising the exposure of sensitive identifier information. To > protect confidentiality, this extension can be used in conjunction > with Encrypted Client Hello (ECH). > > > > The IETF Secretariat > > > -- > Wimse mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
