[TLS] Re: Adoption Call for Trust Anchor IDs

Ryan Hurst <ryan.hurst@gmail.com> Wed, 15 January 2025 22:10 UTC

Return-Path: <ryan.hurst@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19492C16940A for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 14:10:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoSdYy9luuvU for <tls@ietfa.amsl.com>; Wed, 15 Jan 2025 14:10:22 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 1A295C1D5C45 for <tls@ietf.org>; Wed, 15 Jan 2025 14:10:22 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-303489e8775so3215031fa.3 for <tls@ietf.org>; Wed, 15 Jan 2025 14:10:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736979020; x=1737583820; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rjHALhhE0vlF0nAcZd9n4VTj8kw+pRXgh6yNLyybdeM=; b=dJZMu/cpwTiW3CDBNb/FpTsBef29tIfd0pPt2eRV/5b8oJx2+c9wi4k+UcBaROwoZ2 IpHjGNkXWI0W/4bvJUcLeLo9EDh20BcIiQinjT5MziwMX44L4tbh1NLddpHshPl2FdJK VrCaLmS1YjGf4Y3hMoaT2AAR9KvTC7UuLJmx1FJfrVkzh0NSImnAQIhQIRnQQw7wNKN7 ykRfpOHIEe7qQ+qRCrFmDzA5jsE50iM0vvT03q9toyqfzs4a7N9rdXZsUah7a2j1L3IU C5Pf46Bw+A4uQOr6nPecH9qOrIXS1IMrbz9PogH+ILAUdzGpdQ/qEOOW2NHLh1O9EJ2A N70A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736979020; x=1737583820; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rjHALhhE0vlF0nAcZd9n4VTj8kw+pRXgh6yNLyybdeM=; b=IaKOcaP8hVT6pQvtIXXceYTCZJhvpCwJ3OFqxpGSFqvKeTZ0STTlCc33Hk/WCmSOoS /Go7YaaLdy/1dhplozHuqL5NkmviYeoMXZivCmoQGB2/WAAn6TurtNpntB9VKu3FY3/h H/rp5UAWeAYLOP+fvO9w6qtrmSy+WNdwqoLyohoDY0kzX14YBkGfxBrB4FIYQ4j5vq+E w5Qc7pVbvEaYvlTb/JAb+M0NGIzrrbA6kWahjAIRPsUC00VxYf+SJVwf2XdJ473eFBCT gXZm7PmMGt8M7927whJZr7XORw8rYx9B9RNpUregB7I5TIK9OIa2+p2Vgd4UfcKXuKJj 41GQ==
X-Gm-Message-State: AOJu0YyZo+k0RKJiZAu7gtBGXgw/Q0yp/rqzMkZaytXFX24dpcxoEuyS K7iYSI/RprtwBwWrXGLyB/roPqlfWL/Sn45VdjfX8WtY1X1sf/sVKY/209kn6GTWZRhKTMaqDtE JVCSZdH2usq5NdYlA3CZ5P7sSocWDivZ8
X-Gm-Gg: ASbGncvTVeQe/0xS7Jgu5rKZRLgF9akr9BpIlHOm89aOP1yJFKi1pgEokRlw39onm2V Ok41JM42pGtbm8byA2eshIY9121ijv8UcWluR7EPv1Is0k+d7Rv5cczc=
X-Google-Smtp-Source: AGHT+IEqeDi1/FpxOMJSva1yIPrp9KkU4mIgZAKOnTJPdMhmgcJRFinEDiAhEWGcmJEGHtxQAfawfqOcQEthYRy7Zm4=
X-Received: by 2002:a2e:a586:0:b0:302:3021:9b29 with SMTP id 38308e7fff4ca-305f4531012mr106861761fa.4.1736979019773; Wed, 15 Jan 2025 14:10:19 -0800 (PST)
MIME-Version: 1.0
References: <CAOgPGoDHaHXAcpXjtzoA7U-T7B0LoqxSxXsbp7-Rq+gF3shj7Q@mail.gmail.com>
In-Reply-To: <CAOgPGoDHaHXAcpXjtzoA7U-T7B0LoqxSxXsbp7-Rq+gF3shj7Q@mail.gmail.com>
From: Ryan Hurst <ryan.hurst@gmail.com>
Date: Wed, 15 Jan 2025 14:10:07 -0800
X-Gm-Features: AbW1kvZ8wsZQAGsrkhBC3j_-4gIr6rtillLZEh3Fz2rm-F0CFX1nAC-QkxxIo74
Message-ID: <CALVZKwatg8P5_p7MBOVB1DHEXW0Q3W+=_Jvzt3zJffNJMF0iHQ@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Content-Type: multipart/alternative; boundary="00000000000074bf3f062bc5f1e7"
Message-ID-Hash: ZEMATGZZYAFQKLVHNDQ5OZB6WWNSOT3O
X-Message-ID-Hash: ZEMATGZZYAFQKLVHNDQ5OZB6WWNSOT3O
X-MailFrom: ryan.hurst@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: "<tls@ietf.org>" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Adoption Call for Trust Anchor IDs
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/SqrjTTKTyRyu6H9c4idyEnD1-sg>
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>

As someone with experience building and managing many CAs, running a root
program, and building out platform technology to enable TLS use cases, I
believe this work is important and fully support its adoption. Today’s
manual, out-of-band management of trust anchors not only holds the web back
but also unnecessarily exposes users to trust anchors that are not
essential for enabling TLS on the web. This proposal provides a credible
path to address this lack of agility. While it’s clear that this
slow-moving and fragile approach is already problematic, it will only
become more challenging as time goes on. As with all specifications,
adoption remains the key challenge, but I believe this draft offers a
practical solution to these issues without disrupting existing systems.

Ryan Hurst

On Wed, Jan 15, 2025 at 8:00 AM Joseph Salowey <joe@salowey.net> wrote:

> At the trust tussle Interim in October we had consensus that the working
> group was interested in working on the following problem:
>
> “Avoid client trust conflicts by enabling servers to reliably and
> efficiently support clients with diverse trust anchor lists, particularly
> in larger PKIs where the existing certificate_authorities extension is not
> viable”
>
> After IETF 121, we asked for submissions for possible working group
> adoption as a starting point for this work. We received two submissions:
>
> [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03
> <https://datatracker.ietf.org/doc/draft-beck-tls-trust-anchor-ids/>
>
> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00
> <https://datatracker.ietf.org/doc/draft-jackson-tls-trust-is-nonnegotiable/>
>
> [1] defines a new protocol mechanism, while [2] provides an explanation of
> why the mechanism in [1] may not be needed and may be problematic. Since
> the second draft does not define a protocol mechanism we are not
> considering it for adoption, but we request that working group members
> review both documents and use [2] as input into determining whether we
> should adopt [1] as a working group item.  Adoption as a working group item
> means the working group has change control over and can modify it as
> necessary; an adopted document is only a starting point.  Please respond to
> this thread if you think the document should be adopted as a working group
> item. If you think the document is not appropriate for adoption please
> indicate why.  This adoption call will close on February 7, 2025.  Also
> please remember to maintain professional behavior and keep the discussion
> focused on technical issues.
>
>
> Thanks,
>
>
> Sean, Deirdre and Joe
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>