Date: Mon, 30 Mar 2026 15:38:50 -0500
From: Nico Williams <nico@cryptonector.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Message-ID: <acrfWoDSHUrYj1if@ubby>
References: 
 <MN2PR17MB40314193002D42E6ED4F465ACD4CA@MN2PR17MB4031.namprd17.prod.outlook.com>
 <MN2PR17MB40315028C6985BD9F4F0C886CD52A@MN2PR17MB4031.namprd17.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <MN2PR17MB40315028C6985BD9F4F0C886CD52A@MN2PR17MB4031.namprd17.prod.outlook.com>
Message-ID-Hash: YVYOCZWYXAGCDTDHYNPX3ZEMGSJ2DYBB
CC: Tls <tls@ietf.org>, "spasm@ietf.org" <spasm@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_=5Blamps=5D_Re=3A_TLS_Client_Certificates=3B_a_sur?=
	=?utf-8?q?vey?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/9o159R9vZQgayL37swt0S_CvLIc>

On Mon, Mar 30, 2026 at 08:04:54PM +0000, Salz, Rich wrote:
> The overwhelming response (strong consensus) — both posted and via
> private replies — is that applications will just switch to
> TLS-Server-Auth identities for the client side.

That violates RFCs 5280 & 8446 and vitiates the Chrome Root Program's
new policy.  Whatever problem that policy change meant to addres might
only be made worse by this approach (sure, only for those apps that
implement this workaround, but for those, yes, it will be worse).

There has to be a better way.

Does the IETF have a Liason to the Chrome Root Program?  Can we reach
out to them and ask them?  When I did they simply did not respond, but
if the IETF TLS and/or LAMPS WG chairs, or IETF Security ADs reach out
to them perhaps they'll respond -- failing that then maybe the IETF
Chair or the IAB.

Nico
--