[lamps] Re: TLS Client Certificates; a survey

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 23 March 2026 16:16 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 8177CCFF7AEA for <spasm@mail2.ietf.org>; Mon, 23 Mar 2026 09:16:02 -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 LZ5jDmlLnBJt for <spasm@mail2.ietf.org>; Mon, 23 Mar 2026 09:16:02 -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 0CBF3CFF7AE0 for <spasm@ietf.org>; Mon, 23 Mar 2026 09:16:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1774282560; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : content-transfer-encoding : from; bh=qLdk1B8PEWvZZiQh5jGuHqsvetlYNsR5NuboxRKC0Qs=; b=BnYpd48fJGzPj5/t9M7pI21sdbPJWljJ+QC2a8xIi06nW+P67SckVexcJI5L5Qr+FV6bM 4NSMcCHFAMurMHaT+yZovaN/2FNJn0FGQgVhpbmrDKi5xeP2/vsi4Osi3LwG8ZGIqeDho3V t2gJVFvSUEcNTIscqLi9mvu9eH07iL4=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id 0D039938E14; Tue, 24 Mar 2026 03:16:00 +1100 (AEDT)
Date: Tue, 24 Mar 2026 03:15:59 +1100
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: spasm@ietf.org
Message-ID: <acFnP10qMoESdD30@chardros.imrryr.org>
References: <MN2PR17MB40314193002D42E6ED4F465ACD4CA@MN2PR17MB4031.namprd17.prod.outlook.com> <acFbuTA8Wm20nQ2s@chardros.imrryr.org> <acFjOWV5IlrT1Ytx@ubby>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <acFjOWV5IlrT1Ytx@ubby>
Mail-Followup-To: <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: TNMHBWSKHZP37O6LACXDAZCBICT25TES
X-Message-ID-Hash: TNMHBWSKHZP37O6LACXDAZCBICT25TES
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 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/G6PelsxeUFKSLA6djzg5WK2w-XY>
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 Mon, Mar 23, 2026 at 10:58:49AM -0500, Nico Williams wrote:

> On Tue, Mar 24, 2026 at 02:26:49AM +1100, Viktor Dukhovni wrote:
> > [ Below, surely a longer answer than solicited.  TL;DR, a workaround may
> >   soon be added in Postfix 3.12 dev snapshots, that avoids the issue by
> >   accepting serverAuth certificates from SMTP over TLS clients. ]
> 
> Is this for SMTP ETRN?

No, and perhaps you're thinking of ATRN instead, but also not for that,
since Postfix does not support ATRN.  Rather it is mostly for policy
servvice callouts, which get to see the issuer and subject CNs only when
the certificate chain is trusted.

Access control by public key or certificate fingerprint is independent
of PKI trust.

But my long answer was not really intended to digress into SMTP access
policy discussions.  Rather, it was an opportunity to give some context
to a workaround that others may find useful in their applications, if
the use-case warrants going there, rather than (generally better)
rethinking whether relying on a third-party CA is the right way to
handle client certs.

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