]> Zscaler

yrosomakho@zscaler.com

Cloudflare

jonathan.hoyland@gmail.com

Transport Layer Security tls wimse identifier workload hint This document defines a TLS extension that allows clients to indicate one or more workload identifier origins in the ClientHello message. Each origin consists of a URI scheme and trust domain component, representing the administrative domain and identifier namespace in which the client operates. These identifier origins 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). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Mutual TLS (mTLS) is commonly used to authenticate both endpoints of a 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 origins in the ClientHello message (). As defined in , workload identifier origin is a subset of workload identifier and consists of a URI scheme and a trust domain (e.g., spiffe://example.org or wimse://botfarm.example.com). It indicates a namespace under which the client may present an authenticated identifier. Workload identifier origins 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 origin and allow others to connect without client certificate authentication on TLS layer.
• A server may use the provided workload identifier origins to generate an appropriate list of Certificate Authorities extension () in CertificateRequest message ().
• The server may reject the connection early if none of the advertised workload identifier origins 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 () to ensure confidentiality of the workload identifier origins.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

TLS Extension Format This document defines a new TLS extension named workload_identifier_origin_hint, which is carried in the ClientHello message. The extension provides the server with one or more workload identifier origins that the client associates with itself. This allows the server to evaluate authentication requirements prior to sending a CertificateRequest message. The workload_identifier_origin_hint extension is structured as follows: ; struct { WorkloadIdentifierOrigin identifierorigins<3..2^16-1>; } WorkloadIdentifierOriginHintExtension; ]]>

identifierOrigins:

A list of UTF-8 encoded absolute URI strings as defined in containing only the scheme and trust domain components of Workload Identifiers as defined in . URI strings MUST NOT contain a path component.

Clients MAY include multiple identity origins 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.

Server Processing Rules Upon receiving the extension, the server:

• MAY use the identifier origins to determine whether to send a CertificateRequest message.
• MAY use the identifier origins to construct Certificate Authorities extension in the CertificateRequest message.
• MAY use the identifier origins to select a trust anchor or policy.
• MAY reject the handshake early with handshake_failure alert if none of the identifier origins are acceptable.
• MUST NOT treat inclusion of the extension as proof of identity. The identifier origins are advisory and unauthenticated until verified during client authentication.

If the extension is absent, the server proceeds with the default client authentication behavior.

Security Considerations 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.

Confidentiality of Workload Identifier Origins Workload identifier origins 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 origins 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 is available. ECH encrypts the ClinetHelloInner and its extensions under the server's public key, preventing visibility of the identifier origins to on-path observers. If ECH is not in use, clients SHOULD avoid including sensitive or detailed identifier origins in this extension unless required by policy.

Unauthenticated Hints The workload identifier origins 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 origins in the ClientHello. However, this enforcement must be restricted to access control decisions prior to authentication, such astriggering client authentication or rejecting the handshake.

Identifier Origins Enumeration If ECH is not deployed, an attacker with network visibility may collect workload identifier origins by observing repeated TLS handshakes. This could aid in reconnaissance or allow inference of infrastructure details. To reduce this risk, clients may:

• Use generic or opaque identifier origins when full disclosure is not required.
• Limit use of the extension to trusted networks or peers.
• Use ECH to encrypt the extension contents.

Server Response Behaviour Servers receiving unknown or malformed identifier origins SHOULD ignore them and proceed with the default authentication policy. Servers SHOULD NOT terminate connections solely due to unrecognised identifier origins unless explicitly configured to do so.

IANA Considerations IANA is requested to assign a new value from the TLS ExtensionType Values registry:

• The Extension Name should be workload_identifier_origin_hint
• The TLS 1.3 value should be CH
• The DTLS-Only value should be N
• The Recommended value should be Y
• The Reference should be this document

Normative References This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Zscaler CyberArk This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in digital credentials, including X.509 certificates and security tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. Independent Fastly Cryptography Consulting LLC Cloudflare This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]

Acknowledgments TODO acknowledge.