[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 >
- [TLS] Adoption Call for Trust Anchor IDs Joseph Salowey
- [TLS] Re: Adoption Call for Trust Anchor IDs David Benjamin
- [TLS] Re: Adoption Call for Trust Anchor IDs Bob Beck
- [TLS] Re: Adoption Call for Trust Anchor IDs Andrew Chen
- [TLS] Re: Adoption Call for Trust Anchor IDs Ryan Hurst
- [TLS] Re: Adoption Call for Trust Anchor IDs Brendan McMillion
- [TLS] Re: Adoption Call for Trust Anchor IDs Robert Relyea
- [TLS] Re: Adoption Call for Trust Anchor IDs Loganaden Velvindron
- [TLS] Re: Adoption Call for Trust Anchor IDs Martin Thomson
- [TLS] Re: Adoption Call for Trust Anchor IDs David Adrian
- [TLS] Re: Adoption Call for Trust Anchor IDs Watson Ladd
- [TLS] Re: Adoption Call for Trust Anchor IDs Mike Shaver
- [TLS] Re: Adoption Call for Trust Anchor IDs Stephen Farrell
- [TLS] Re: Adoption Call for Trust Anchor IDs Thom Wiggers
- [TLS] Re: Adoption Call for Trust Anchor IDs Bas Westerbaan
- [TLS] Re: Adoption Call for Trust Anchor IDs Clint Wilson
- [TLS] Re: Adoption Call for Trust Anchor IDs Kyle Nekritz
- [TLS] Re: Adoption Call for Trust Anchor IDs Christopher Patton
- [TLS] Re: Adoption Call for Trust Anchor IDs Kathleen Moriarty
- [TLS] Re: Adoption Call for Trust Anchor IDs Dennis Jackson
- [TLS] Re: Adoption Call for Trust Anchor IDs Kampanakis, Panos
- [TLS] Re: Adoption Call for Trust Anchor IDs Nick Harper
- [TLS] Re: Adoption Call for Trust Anchor IDs Salz, Rich
- [TLS] Re: Adoption Call for Trust Anchor IDs David Schinazi
- [TLS] Re: Adoption Call for Trust Anchor IDs Christopher Wood
- [TLS] Re: Adoption Call for Trust Anchor IDs Joseph Salowey