| Internet-Draft | Workload Identifier Scope Hint for TLS C | July 2025 |
| Rosomakho & Hoyland | Expires 8 January 2026 | [Page] |
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).¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://yaroslavros.github.io/tls-wimse-cert-hint/draft-rosomakho-tls-wimse-cert-hint.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-rosomakho-tls-wimse-cert-hint/.¶
Discussion of this document takes place on the Transport Layer Security mailing list (mailto:tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe at https://www.ietf.org/mailman/listinfo/tls/.¶
Source for this draft and an issue tracker can be found at https://github.com/yaroslavros/tls-wimse-cert-hint.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Mutual TLS (mTLS) is commonly used to authenticate both endpoints of a [TLS] connection, especially in service-to-service communication within distributed systems. In many deployments, client authentication is conditional: only certain clients are required to present a certificate, and the decision is based on the nature of the client.¶
This document defines a TLS extension that allows clients to indicate one or more workload identifier scopes in the ClientHello message (Section 4.1.2 of [TLS]). Each identifier scope is a subset of Workload Identifier [Reference TBD] and consists of a URI scheme and trust domain (e.g., spiffe://example.org or https://botfarm.example.com) and indicates a namespace under which the client may present an authenticated identifier. Workload identifier scopes act as hints that inform the server of the client intended identifier before the TLS handshake is completed. Based on this information, the server can determine whether client certificate authentication is desirable and, if so, what policy or certificate validation rules should apply.¶
This approach enables more flexible and efficient authentication strategies in environments where different clients may be subject to different requirements. For example:¶
A server may enforce mTLS only for clients of specific workload identifier scope and allow others to connect without client certificate authentication on TLS layer.¶
A server may use the provided workload identifier scopes to generate an appropriate list of Certificate Authorities extension (Section 4.2.4 of [TLS]) in CertificateRequest message (Section 4.3.2 of [TLS]).¶
The server may reject the connection early if none of the advertised workload identifier scopes are authorized.¶
By only sending scheme and trust domain (omitting the path), this extension limits exposure of cleartext information. Where further confidentiality is desired, clients are encouraged to include this extension only in ClientHelloInner of Encrypted Client Hello ([ECH]) to ensure confidentiality of the workload identifier scopes.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document defines a new TLS extension named workload_identifier_scope_hint, which is carried in the ClientHello message. The extension provides the server with one or more workload identifier scopes that the client associates with itself. This allows the server to evaluate authentication requirements prior to sending a CertificateRequest message.¶
The workload_identifier_scope_hint extension is structured as follows:¶
opaque WorkloadIdentifierScope<1..2^16-1>;
struct {
WorkloadIdentifierScope identifierscopes<3..2^16-1>;
} WorkloadIdentifierScopeHintExtension;
¶
identifierscopes:A list of UTF-8 encoded absolute URI absolute URI strings as defined in [URI] containing only the scheme and trust domain components of Workload Identifiers defined in TBD.¶
The path, query, and fragment components MUST NOT be included. Clients MAY include multiple identity scopes if they operate within more than one trust domain or namespace.¶
The extension MUST appear only in the ClientHello. Servers MUST abort TLS handshake with an illegal_parameter alert if this extension appears in any other handshake message. Similarly, clients MUST abort TLS handshake if this extension appears in any message from the server.¶
Upon receiving the extension, the server:¶
MAY use the identifier scopes to determine whether to send a CertificateRequest message.¶
MAY use the identifier scopes to construct Certificate Authorities extension in the CertificateRequest message.¶
MAY use the identifier scopes to select a trust anchor or policy.¶
MAY reject the handshake early with handshake_failure alert if none of the identifier scopes are acceptable.¶
MUST NOT treat inclusion of the extension as proof of identity. The identifier scopes are advisory and unauthenticated until verified during client authentication.¶
If the extension is absent, the server proceeds with the default client authentication behavior.¶
This extension is intended to improve the flexibility of client authentication policies in TLS. However, because it introduces unauthenticated identity hints early in the handshake, several security considerations apply.¶
Workload identifier scopes may contain sensitive information, such as deployment structure or tenant-specific data. Since this extension is sent in the clear as part of the ClientHello, exposure of these identifier scopes may allow passive observers to infer client roles, access patterns, or security posture.¶
To mitigate this risk, clients SHOULD include this extension only in ClinetHelloInner if [ECH] is available. ECH encrypts the ClinetHelloInner and its extensions under the server's public key, preventing visibility of the identifier scopes to on-path observers.¶
If ECH is not in use, clients SHOULD avoid including sensitive or detailed identifier scopes in this extension unless required by policy.¶
The workload identifier scopes conveyed in this extension are not authenticated. They are advisory in nature and MUST NOT be treated by the server as a proof of identity. Servers MUST perform full cryptographic verification of the client certificate before relying on any identity claim.¶
Servers MAY enforce policies based on the presence or absence of expected identifier scopes in the ClientHello. However, this enforcement must be restricted to access control decisions prior to authentication, such astriggering client authentication or rejecting the handshake.¶
If ECH is not deployed, an attacker with network visibility may collect workload identifier scopes by observing repeated TLS handshakes. This could aid in reconnaissance or allow inference of infrastructure details. To reduce this risk, clients may:¶
Servers receiving unknown or malformed identifier scopes SHOULD ignore them and proceed with the default authentication policy. Servers SHOULD NOT terminate connections solely due to unrecognised identifier scopes unless explicitly configured to do so.¶
IANA is requested to assign a new value from the TLS ExtensionType Values registry:¶
TODO acknowledge.¶