[lamps] Re: [TLS] TLS Client Certificates; a survey

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 26 March 2026 06:25 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: spasm@mail2.ietf.org
Delivered-To: spasm@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 49519D19A984 for <spasm@mail2.ietf.org>; Wed, 25 Mar 2026 23:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=dukhovni.org
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xUO7hAZ_G1J for <spasm@mail2.ietf.org>; Wed, 25 Mar 2026 23:25:32 -0700 (PDT)
Received: from chardros.imrryr.org (chardros.imrryr.org [144.6.86.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 869A7D19A51F for <spasm@ietf.org>; Wed, 25 Mar 2026 23:24:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1774506274; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : content-transfer-encoding : from; bh=oE6cpbwJw1ELT9RVlddyDxvjzsQ8A8ALfL08jNX6ISg=; b=GP+cRb1XlwYEtfCiBU1xYAHdgReXxOueyL36tsm4gCY4X9bXBlADedXuR84fM0Jwgr4X5 g19Gz0jMTCGXa1fCVv83QANW2LRna2VlS5RToelAc6w3+pcgIZ2vEXH2KJGCMHUVk/od9cB ifQjDpLx8jp8fo4IClWgFf7rbP+pO8o=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id C60B4938E14; Thu, 26 Mar 2026 17:24:34 +1100 (AEDT)
Date: Thu, 26 Mar 2026 17:24:34 +1100
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: spasm@ietf.org
Message-ID: <acTRIp94ico8p2RE@chardros.imrryr.org>
References: <MN2PR17MB40314193002D42E6ED4F465ACD4CA@MN2PR17MB4031.namprd17.prod.outlook.com> <acSdA5dgEpvgxxtR@ubby> <acSzrW_Wee0xIeBH@chardros.imrryr.org> <acS53PNkvItHKpwR@ubby> <96490FD2-1D40-4748-92F0-63160460A6BA@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <96490FD2-1D40-4748-92F0-63160460A6BA@gmail.com>
Mail-Followup-To: <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: FKWCKIHYO4R4NYF2Z4CZKX4FEEQMPCXA
X-Message-ID-Hash: FKWCKIHYO4R4NYF2Z4CZKX4FEEQMPCXA
X-MailFrom: ietf-dane@dukhovni.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spasm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: spasm@ietf.org
Subject: [lamps] Re: [TLS] TLS Client Certificates; a survey
List-Id: This is the mail list for the LAMPS Working Group <spasm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/XTLZTPl0NEgstYRWeV_9LgUwYx8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Owner: <mailto:spasm-owner@ietf.org>
List-Post: <mailto:spasm@ietf.org>
List-Subscribe: <mailto:spasm-join@ietf.org>
List-Unsubscribe: <mailto:spasm-leave@ietf.org>

On Thu, Mar 26, 2026 at 03:14:49PM +0900, Seo Suchan wrote:

> Wonder if allowing tls root ca to have dedicate clientauth eku only
> (no serverauth) subca is good stop gap. So clientauth cert can't
> backflow to browsers, but allowing clientauth certs to be chained to
> tls root cas

That violates the CRP (Chrome Root Programme) rules as I understand
them, but what is possible is for the CA to not enroll the real root
in the CRP, and instead enroll only subsidiary CAs that don't issue
clientAuth:

        root -> intermediate CRP trust anchor  -> EE cert
         |
         \__--> non-CRP intermediate -> EE cert

but this would require the various popular CAs to be willing to make the
effort to support clientAuth by doing that (thus coördinating with the
CRP before introducing new intermediates).

And of course some servers might need separate certificates if they
need to be valid for both browser clients and in server-to-server
contexts as clients.

-- 
    Viktor.  🇺🇦 Слава Україні!