IETF Logo Mail Archive

[TLS] -03 update to draft-beck-tls-trust-anchor-ids

Devon O'Brien <asymmetric@google.com> Wed, 18 December 2024 22:15 UTC

Return-Path: <asymmetric@google.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 5BD51C18DB93 for <tls@ietfa.amsl.com>; Wed, 18 Dec 2024 14:15:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.607
X-Spam-Level:
X-Spam-Status: No, score=-17.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 TQzellDoyoby for <tls@ietfa.amsl.com>; Wed, 18 Dec 2024 14:15:05 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 8FBE5C151989 for <tls@ietf.org>; Wed, 18 Dec 2024 14:15:05 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5401af8544bso581e87.1 for <tls@ietf.org>; Wed, 18 Dec 2024 14:15:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1734560103; x=1735164903; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=y4n1Ss9ex/MeH4qtAAjupcl+QxV4KBIejInWZX2sm+8=; b=G2XuoYQmb/2uVQKdOHE5aObsnU3WYsVcPKCJS5kS/R5IIyQ/9cMdfNVgnaD28yLqZl jgugy8n/44BV9eGPpzTvqWcYlXMEhNvI2DTN6iPl5a84WS+jLxSU/C7lMZnYQgjSSeIR td4LAInjLMfp9layLgqUxI8S6VrdV14kAhEq/yUya3tfSPEjkYFS+9UUMiok2KkHGQIb le/HuSZUSL1qW4AeXcY70Yj+NxnWrDVzeR8Ah44wOB5EePfy+5S6tHLMCvtPZTmfa3ZS B91T1z9Kh1TMWYad+mcXLLInT1Uq2GR2gVaac/OQISiSh7+eZA+iOSG9d/QHYQLgM1Ot kW/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734560103; x=1735164903; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=y4n1Ss9ex/MeH4qtAAjupcl+QxV4KBIejInWZX2sm+8=; b=e4/q/XCTZTOLujyCMDKo7nuohua1oPe6k+7AYr5ltcwefMHn9rnv5IQTfllahgrMDR 2k3oEP2DvbExW12mv3I3/9a3uUMhbyfeDCuBBRQFUA3nOHG7KnXL5Vg/PquayIbaozTO fCB3TCK+m43VXcW+bGfSWBNxdCcprc/6NwgFTOTDD+NaUhqMfkJiiLljju8X6uJ8eZd9 vAUaTTweIDBMJR8d6KOcxryUCwQP6Z11FK8B/U8QhA6QK0zvkSaW1RJJ7/xfCGo1XfcL JLtKEFIHiTNVaMXgNJ8Xlk+KaCNCC8ODZW8RtDb/q5O3vqkKRVEl9JBuuHJyQwCGENj/ Hqeg==
X-Gm-Message-State: AOJu0Yzwh3tO9PXtVVfriwj+VYFL/sGipJkMfrJDkcjQKZ8QiH7EgEDU 9Jya5fEFhG0CvJl6HGArcjCi2B2SabR0333377oP/xM6wqlC1Wva+GVfBgLWtzuKzy3PnRPSFp/ 3tLsffHwH1tbdtI5kb3r5jSuM5fQ/sD7hwAQwwbIOP+FoSOy1loDXcJw=
X-Gm-Gg: ASbGncvquMMQXrO1yvK+7KS6esTei9bGkw8lwC+cav4OOPUwzHTYmuyfoYck6k+dxom bk4joWpclwF8P09ZapNgcJZw4mJ+vM98K+gHiNv1R
X-Google-Smtp-Source: AGHT+IFzDKHtZRygjHPCqCBI4Ew4W+6KdDIWWai3EfdIOkxUPnlkWPD24/jGsz5nh0JBeo4uBZNiPHZA5hYMOZRtqiE=
X-Received: by 2002:a05:6512:3693:b0:53d:e822:ebaf with SMTP id 2adb3069b0e04-542218ad510mr63733e87.4.1734560102513; Wed, 18 Dec 2024 14:15:02 -0800 (PST)
MIME-Version: 1.0
From: Devon O'Brien <asymmetric@google.com>
Date: Wed, 18 Dec 2024 14:14:50 -0800
Message-ID: <CAD2nvsQcCnP08iB5NyBBan1wCa27fK-unjfbcdfqRRePgiAHcQ@mail.gmail.com>
To: TLS List <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c0df44062992be36"
Message-ID-Hash: E3GU3QXLPJB2ES24XLD2VBXYQT2D6VWW
X-Message-ID-Hash: E3GU3QXLPJB2ES24XLD2VBXYQT2D6VWW
X-MailFrom: asymmetric@google.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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] -03 update to draft-beck-tls-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/eFWzwM0uKV8RdiJ1ZV2-ivzDGw8>
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>

We have cut a new -03 version of the Trust Anchor Identifiers draft:

URL:
https://www.ietf.org/archive/id/draft-beck-tls-trust-anchor-ids-03.txt

Status:   https://datatracker.ietf.org/doc/draft-beck-tls-trust-anchor-ids/

HTML:
https://www.ietf.org/archive/id/draft-beck-tls-trust-anchor-ids-03.html

While we didn’t get any mic time in Dublin to present the updates since our
presentation in Vancouver, we had several conversations with attendees and
have incorporated some suggested changes as a result.

Changes include:

   -

   Removed remaining dependencies on text contained in the TLS Trust
   Expressions I-D
   -

   Switched the term “subscriber” to “authenticating party”, for the role
   that presents a certificate
   -

   Cleaned up the security and privacy considerations to be more concise
   -

   Simplified the optional ACME integration
   -

   Rearranged several sections for clarity
   -

   Clarified definition of trust anchors to better match RFC 5280
   -

   Added a copy of the TrustAnchorIdentifiers ASN.1 module to the appendix
   -

   Fixed several typos throughout


We'd also like to thank everyone for a very productive interim in October.
It was good to see the broad interest in solving this problem, and to hear
from the experiences of folks in the TLS ecosystem.

For folks who had been mostly following the earlier Trust Expressions work,
Trust Anchor Identifiers is the alternate design that we originally
presented in Vancouver. It's quite different from Trust Expressions, so we
invite you to take a look at the new draft. Based on the working group
feedback from that session, there was a clear preference for Trust Anchor
Identifiers, so recent changes have been focused entirely on this draft.

We think the current state of Trust Anchor Identifiers draft is a good
starting point for the working group. It follows the standard negotiation
pattern used throughout TLS while aiming to be flexible and not specific to
one particular PKI or type of TLS client. As always, we’re happy to talk
through any questions or topics related to this draft.

-Devon

v2.29.0 | Report a Bug | By Email | System Status