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

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 01 April 2026 03:17 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 63220D481B56 for <tls@mail2.ietf.org>; Tue, 31 Mar 2026 20:17:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775013476; bh=O2NWnp3k5kxBQG3aNJTN5+PuDizT4HkFBvh+5T2AOUQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=vCETNTAEGfe2+g1ydxFOo6tKevmqgFVh0WvFm46Z2Ofrsxn48tewjmP1UIlu6axQj WIjvD9zTQpVxxCHVyYsua1Fu4SJ/jiiXBqRqyj+aZb2OUZBlYw0xwRLNe2NVvUdLGI dy3ec5MqNtilSs5icGjTa0pVppDRSHzq1JlPeQXY=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level:
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 PJNsG-SxXBuQ for <tls@mail2.ietf.org>; Tue, 31 Mar 2026 20:17:56 -0700 (PDT)
Received: from mail-oo1-f48.google.com (mail-oo1-f48.google.com [209.85.161.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id E665DD481B48 for <tls@ietf.org>; Tue, 31 Mar 2026 20:17:55 -0700 (PDT)
Received: by mail-oo1-f48.google.com with SMTP id 006d021491bc7-67f01a40420so451963eaf.1 for <tls@ietf.org>; Tue, 31 Mar 2026 20:17:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1775013469; cv=none; d=google.com; s=arc-20240605; b=AFHs9I91rBzX/X11mmreJXygoajKl1Wbqyo5AB5iVz1DckwVul5UrRRT9Pn8FmEm8n xyZaReH2EVxcJu5kVWR9oKJLLTa6qG3Y+Jw52lU7UOEbg8zI7tkGpM0itlVEy0R2A4EU 2jsSpAk5BBYD9b+lILylJmP+wfhPlGBjuYcgGHvXqQXWtCIgAn/SGwCVWRbwMYJ2OYQs Bdk18RPtISf8P1S2K/ld/QKUZbfKpEYewSQ+9YVD3+HLoIGpEhCK8GVoyCODETizGU+a fQ9COX9X11i+wg7EYkUf/pHiEHIQbnM9VKRAtVgyuakXFFEhJIRcqT5W5P78nsBzCrkN GJLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version; bh=O2NWnp3k5kxBQG3aNJTN5+PuDizT4HkFBvh+5T2AOUQ=; fh=/XG8Tv0lhE9iJRuASUSc3RdWv4wuE2syfQmK3JxM79s=; b=fXeMQdHhlocriuXnuFWEauW86j9CHZLFA8p8cxKzW+nvr0IBKScRh3YK0JTnHgsHcw mcJzlGrlNKRHPeQ86erzRrf8FeFj+YHIjcPeOUBkODrdGbcLKYGOdXbMkz52bWJI9CLu j50FlBfMiEP2fxsSv8j7Ih98aByeF/W6AgMbg0eLMULAVMpfVGqSWRsWGlDw2H7qhjY8 AzHiDedDlMLxWwZxm1ZVqJIFYkjpwlzWMa+kyWTQuVCJM/+pNyVLtt39ird4sKVyCpJa kyzAH7atDpKCpfONxdu58z7ayHPSu9MzigC0G1zhHZvorxlXgFZK2REsilr1Lz8iWhAX o8nA==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775013469; x=1775618269; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=O2NWnp3k5kxBQG3aNJTN5+PuDizT4HkFBvh+5T2AOUQ=; b=gSDWsGNfaiVkbTKOAjLDhzH2hX6qqsIYHSz4GCYFouDpUC2GfhZFO3p8Czy7lZKEWH p7nGGHASWBdoEu6TKKSfTzliTCH6urtYCOpLuWWSvEfRws/75NOB3yMY7h9QL5bO1haE Anl06ZEsD+t2my4VGzG0eslZs+ZVIujSNGCWaS6AlixOZk4DEdhGbPG/0az4INPIwIoJ idy22wjlCv+0qjJQPTQ/vO6yA+CfCzECTdZwQcCC1Jr7gycoLhbYmEeehrYmY2Vpw4Bw WwVI0BBK29cTHAssGQGrCG1f1gww84f6+4W3secm8vCgd/fOkigyj+0hr0KKN7wUz5i0 2NsQ==
X-Forwarded-Encrypted: i=1; AJvYcCXs9IBfPaLW9V7xzZy3akfsYtzHALa2PP5wdmotNwUU4h9cNqChHpyLrWTmJcmMA6rUPt8=@ietf.org
X-Gm-Message-State: AOJu0YxwyCaB7zsJt2JGicpJfNjS3btWwAWpnx4LZuEdbk4E2a7DEnxo v/x3e7qHdCrS2XO43vwYOWxh49NjVhtyQfxOOe71eJdPVoUncIFfOEmFiah/i4y/yHnGP/F4yPB pXwVt2uRiGo5ZS/1C8T6HviF9/WWJK44=
X-Gm-Gg: ATEYQzxbt/HaivGJ4rx/XJlRVvJX0GCt41DSgA6ZAFuWdSpVa26KciI7g1OtcLqSc2R Rgvl3AZ9hhw00kGQu+sEjUWt/1PawfnWaC1jlgygFJyn6QhUgz1JKUt5uDGJi/K5Atefsy55VCk IS3QZP4ovDCb+TxeabcQXYx8Ywa3r2i9e8ifrVA1OLlFxs5ZOdFQwb02S+8ptU9/q3wIVL0nL22 18r8oZCP6EQoj6FL8fi/LiiWgR8Fy/S5XEwjjoTPLXxg47Hiwvlc97xGNOG7atgypFct4Iu6uaJ qQrWg+YC92K0j5a8o8zapYCkS7TTRLX86rZA7jE7mjpdBz6wDik4XqrzLLO/gt4cpCdjvOLPTLj 4DpakLEIJJ46bGRzlzov8EQ==
X-Received: by 2002:a05:6820:1745:b0:67e:1380:a042 with SMTP id 006d021491bc7-67fabc08b4bmr1003655eaf.24.1775013469346; Tue, 31 Mar 2026 20:17:49 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR17MB40314193002D42E6ED4F465ACD4CA@MN2PR17MB4031.namprd17.prod.outlook.com> <MN2PR17MB40315028C6985BD9F4F0C886CD52A@MN2PR17MB4031.namprd17.prod.outlook.com> <acrfWoDSHUrYj1if@ubby> <CAKZgXHqKBwYqjB3SOexT1B3=P2m83esgQTV74PJtjk+LGwAhcA@mail.gmail.com> <CACf5n7-n6xj35ukPznkes8rDx9-QWi+CDntt2Z5jcM1L+uo1RQ@mail.gmail.com>
In-Reply-To: <CACf5n7-n6xj35ukPznkes8rDx9-QWi+CDntt2Z5jcM1L+uo1RQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 31 Mar 2026 23:17:36 -0400
X-Gm-Features: AQROBzCNac0PwGaeAJrrZxkJgC0upOUXNhwk6pY2IjPgj_ObojvQgxwXATtSc0U
Message-ID: <CAMm+LwiGABsBzMD4v-DrPqyAbnAT4Z0Mp6Ee_Az0BSu0G7nZEA@mail.gmail.com>
To: David Adrian <davadria@umich.edu>
Content-Type: multipart/alternative; boundary="0000000000004fe049064e5d874f"
Message-ID-Hash: UHFXKDEYM4AVYE4OATY5JPUSQ5A7FVEE
X-Message-ID-Hash: UHFXKDEYM4AVYE4OATY5JPUSQ5A7FVEE
X-MailFrom: hallam@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Tls <tls@ietf.org>, "spasm@ietf.org" <spasm@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: [lamps] Re: Re: Re: TLS Client Certificates; a survey
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EKumowdi4riyZm3HzydMi9dlOC8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

On Tue, Mar 31, 2026 at 8:00 PM David Adrian <davadria@umich.edu> wrote:


> History has taught us that commingling PKI use cases causes more harm than
> good. It is a consistent security problem when PKI hierarchies intended for
> public web sites get entangled in non-web use cases. As an example, such
> behavior slowed the deprecation of SHA-1 in 2018 because payment card
> terminal implementations and their corresponding root stores could not be
> updated.
>

The original concept of X.509v3/PKIX was that there were two types of
certificate, certificate signing certificates and end entity certificates.
While there are certainly very good arguments for cryptographic hygiene and
use of separate private keys for separate applications, that only leads us
to separation of concerns between end-entity certificates.

I would have rather more sympathy for the position of the browser providers
in 2018 if they had not been so intractably opposed to adding support for
SHA-2 back when I was pushing for that in 2002. The transition from MD5 to
SHA-1 had only been possible because the browsers already supported SHA-1
and it was clear that we would be in a mess if SHA-1 failed long before the
2005 RSA announcement which rather than spurring deployment of SHA-2 caused
many to decide that we should instead wait for SHA-3.

The problem we faced as CAs was that nobody would be able to make use of
SHA-2 certificates until they were widely supported in the browsers so it
really didn't make sense for the browser providers to block on CA support.

In the event, a certain browser provider flipped from being non commital in
their plans to add support to insisting the problem was so severe we had to
do transition immediately. So no, I don't draw the same conclusions.


As to applying the 'commingling' argument to roots, I am rather surprised
because root certificates aren't really certificates at all in PKIX terms.
While they are presented as self signed certificates, that is really just a
syntactic convenience that avoided having to define a new structure. The
signature on a root certificate doesn't have meaning after it has been
installed in a root store so whether it is SHA-1, SHA-2 or MD4 makes little
real difference.

No, I cannot see a good argument for Web client and Web server certificates
being separate applications not to be commingled.