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
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to