



Transport Layer Security                                         B. Beck
Internet-Draft                                                   OpenSSL
Intended status: Standards Track                             D. Benjamin
Expires: 19 March 2026                                        Google LLC
                                                              D. O'Brien
                                                                        
                                                              K. Nekritz
                                                                    Meta
                                                       15 September 2025


                      TLS Trust Anchor Identifiers
                   draft-ietf-tls-trust-anchor-ids-02

Abstract

   This document defines the TLS Trust Anchors extension, a mechanism
   for relying parties to convey trusted certification authorities.  It
   describes individual certification authorities more succinctly than
   the TLS Certificate Authorities extension.

   Additionally, to support TLS clients with many trusted certification
   authorities, it supports a mode where servers describe their
   available certification paths and the client selects from them.
   Servers may describe this during connection setup, or in DNS for
   lower latency.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://tlswg.github.io/tls-trust-anchor-ids/draft-ietf-tls-trust-
   anchor-ids.html.  Status information for this document may be found
   at https://datatracker.ietf.org/doc/draft-ietf-tls-trust-anchor-ids/.

   Discussion of this document takes place on the Transport Layer
   Security Working Group mailing list (mailto:tls@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/tls/.  Subscribe
   at https://www.ietf.org/mailman/listinfo/tls/.

   Source for this draft and an issue tracker can be found at
   https://github.com/tlswg/tls-trust-anchor-ids.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.



Beck, et al.              Expires 19 March 2026                 [Page 1]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 19 March 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     2.1.  Terminology and Roles . . . . . . . . . . . . . . . . . .   5
   3.  Trust Anchor Identifiers  . . . . . . . . . . . . . . . . . .   5
     3.1.  Relying Party Configuration . . . . . . . . . . . . . . .   6
     3.2.  Authenticating Party Configuration  . . . . . . . . . . .   7
   4.  TLS Extension . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Certificate Selection . . . . . . . . . . . . . . . . . .   8
     4.3.  Retry Mechanism . . . . . . . . . . . . . . . . . . . . .   9
   5.  DNS Service Parameter . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.2.  Configuring Services  . . . . . . . . . . . . . . . . . .  12
     5.3.  Client Behavior . . . . . . . . . . . . . . . . . . . . .  12
   6.  Certificate Properties  . . . . . . . . . . . . . . . . . . .  12
     6.1.  Media Type  . . . . . . . . . . . . . . . . . . . . . . .  13
     6.2.  ACME Extension  . . . . . . . . . . . . . . . . . . . . .  14
   7.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Making Use of Newly-Trusted CAs . . . . . . . . . . . . .  15
     7.2.  Removing Untrustworthy CAs  . . . . . . . . . . . . . . .  16



Beck, et al.              Expires 19 March 2026                 [Page 2]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


     7.3.  Key Rotation  . . . . . . . . . . . . . . . . . . . . . .  16
     7.4.  Other Root Transitions  . . . . . . . . . . . . . . . . .  17
     7.5.  Intermediate Elision  . . . . . . . . . . . . . . . . . .  17
     7.6.  Conflicting Relying Party Requirements  . . . . . . . . .  18
     7.7.  Backup Certificates . . . . . . . . . . . . . . . . . . .  18
     7.8.  Public Key Pinning  . . . . . . . . . . . . . . . . . . .  18
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  18
     8.1.  Relying Parties . . . . . . . . . . . . . . . . . . . . .  19
     8.2.  Authenticating Parties  . . . . . . . . . . . . . . . . .  20
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
     9.1.  Incorrect Selection Metadata  . . . . . . . . . . . . . .  20
     9.2.  Trust Anchor Negotiation  . . . . . . . . . . . . . . . .  21
       9.2.1.  Relying Party Policies  . . . . . . . . . . . . . . .  21
       9.2.2.  Agility . . . . . . . . . . . . . . . . . . . . . . .  21
       9.2.3.  Serving Multiple Certificates . . . . . . . . . . . .  22
       9.2.4.  Targeting TLS Interception  . . . . . . . . . . . . .  22
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
     10.1.  TLS ExtensionType Updates  . . . . . . . . . . . . . . .  23
     10.2.  Media Type Updates . . . . . . . . . . . . . . . . . . .  23
     10.3.  PKIX Registry Updates  . . . . . . . . . . . . . . . . .  24
     10.4.  CertificatePropertyType Registry . . . . . . . . . . . .  25
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     11.2.  Informative References . . . . . . . . . . . . . . . . .  26
   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  27
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  28
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28

1.  Introduction

   TLS [RFC8446] authentication uses X.509 certificates [RFC5280] to
   associate the _authenticating party's_ TLS key with its application
   identifiers, such as DNS names.  These associations are signed by
   some certificate authority (CA).  The peer, or _relying party_,
   curates a set of CAs that are trusted to only sign correct
   associations, which allows it to rely on the TLS to authenticate
   application identifiers.  Typically the authenticating party is the
   server and the relying party is the client.

   An authenticating party may need to interoperate with relying parties
   that trust different sets of CAs.  Section 4.2.4 of [RFC8446] defines
   the certificate_authorities extension to accommodate this.  It allows
   the authenticating party to provision multiple certificates and
   select the one that will allow the relying party to accept its TLS
   key.  This is analogous to parameter negotiation elsewhere in TLS.






Beck, et al.              Expires 19 March 2026                 [Page 3]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   However, certificate_authorities's size is impractical for some
   applications.  Existing PKIs may have many CAs, and existing CAs may
   have long X.509 names.  As of August 2023, the Mozilla CA Certificate
   Program [MOZILLA-ROOTS] contained 144 CAs, with an average name
   length of around 100 bytes.  Such TLS deployments often do not use
   trust anchor negotiation at all.

   Without a negotiation mechanism, the authenticating party must obtain
   a single certificate that simultaneously satisfies all relying
   parties.  This is challenging when relying parties are diverse.  PKI
   transitions, including those necessary for user security, naturally
   lead to relying party diversity, so the result is that service
   availability conflicts with security and overall PKI evolution:

   *  For an authenticating party to use a CA in its single certificate,
      all supported relying parties must trust the CA.  PKI transitions
      then become difficult when authenticating parties support older,
      unupdated relying parties.  This impacts both new keys from
      existing CA operators and new CA operators.

   *  When a relying party must update its policies to meet new security
      requirements, it adds to relying party diversity and the
      challenges that authenticating parties and CAs face.  The relying
      party must then choose between compromising on user security or
      burdening the rest of the ecosystem, potentially impacting
      availability in the process.

   To address this, this document introduces Trust Anchor Identifiers
   (Trust Anchor IDs).  There are three parts to this mechanism:

   1.  Section 3 defines _trust anchor IDs_, which are short, unique
       identifiers for X.509 trust anchors.

   2.  Section 4 defines a TLS extension that communicates the relying
       party's requested trust anchors, and the authenticating party's
       available ones.  When the relying party is a TLS client, it can
       mitigate large lists by sending a, possibly empty, subset of its
       trust anchors to the TLS server.  The server provides its list of
       available trust anchors in response so that the client can retry
       on mismatch.

   3.  Section 5 allows TLS servers to advertise their available trust
       anchors in HTTPS or SVCB [RFC9460] DNS records.  TLS clients can
       then request an accurate initial subset and avoid a retry
       penalty.

   Together, they reduce the size costs of trust anchor negotiation,
   supporting flexible and robust PKIs for more applications.



Beck, et al.              Expires 19 March 2026                 [Page 4]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document additionally uses the TLS presentation language,
   defined in Section 3 of [RFC8446], and ASN.1, defined in [X680].

2.1.  Terminology and Roles

   This document discusses three roles:

   Authenticating party:  The party authenticating itself in the
      protocol.  In TLS, this is the side sending the Certificate and
      CertificateVerify message.

   Relying party:  The party whom the authenticating party presents its
      identity to.  In TLS, this is the side that validates a
      Certificate and CertificateVerify message.

   Certification authority (CA):  The service issuing certificates to
      the authenticating party.

   Additionally, there are several terms used throughout this document
   to describe this proposal:

   Trust anchor:  A pre-distributed X.509 name and public key that
      relying parties use to determine whether a certification path is
      trusted.  See Section 6.1.1 of [RFC5280].  Trust anchors are
      sometimes configured as self-signed certificates.

   Certification path:  An ordered list of X.509 certificates starting
      with the target certificate.  Each certificate is issued by the
      next certificate, except the last, which is issued by a trust
      anchor.

3.  Trust Anchor Identifiers

   This section defines trust anchor IDs, which are short, unique
   identifiers for a trust anchor.  To simplify allocation, trust anchor
   IDs are defined with object identifiers (OIDs) [X680] and IANA-
   registered Private Enterprise Numbers (PENs) [RFC9371]:






Beck, et al.              Expires 19 March 2026                 [Page 5]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   A trust anchor ID is defined with an OID under the OID arc of some
   PEN.  For compactness, they are represented as relative object
   identifiers (see Section 33 of [X680]), relative to the OID prefix
   1.3.6.1.4.1.  For example, an organization with PEN 32473 might
   define a trust anchor ID with the OID 1.3.6.1.4.1.32473.1.  As a
   relative object identifier, it would be the OID 32473.1.

   Depending on the protocol, trust anchor IDs may be represented in one
   of three ways:

   *  For use in ASN.1-based protocols, a trust anchor ID's ASN.1
      representation is the relative object identifier described above.
      This may be encoded in DER [X690], or some other ASN.1 encoding.
      The example ID's DER encoding is the six-octet sequence {0x0d,
      0x04, 0x81, 0xfd, 0x59, 0x01}.

   *  For use in binary protocols such as TLS, a trust anchor ID's
      binary representation consists of the contents octets of the
      relative object identifier's DER encoding, as described in
      Section 8.20 of [X690].  Note this omits the tag and length
      portion of the encoding.  The example ID's binary representation
      is the four-octet sequence {0x81, 0xfd, 0x59, 0x01}.

   *  For use in ASCII-compatible text protocols, a trust anchor ID's
      ASCII representation is the relative object identifier in dotted
      decimal notation.  The example ID's ASCII representation is
      32473.1.

   Trust anchor IDs SHOULD be allocated by the CA operator and common
   among relying parties that trust the CA.  They MAY be allocated by
   another party, e.g. when bootstrapping an existing ecosystem, if all
   parties agree on the ID.  In particular, the protocol requires
   authenticating and relying parties to agree, and the authenticating
   party's configuration typically comes from the CA.

   The length of a trust anchor ID's binary representation MUST NOT
   exceed 255 bytes.  It SHOULD be significantly shorter, for bandwidth
   efficiency.

3.1.  Relying Party Configuration

   Relying parties are configured with one or more supported trust
   anchors.  Each trust anchor that participates in this protocol must
   have an associated trust anchor ID.

   When trust anchors are represented as X.509 certificates, the X.509
   trust anchor ID extension MAY be used to carry this ID.  The trust
   anchor ID extension has an extnID of id-pe-trustAnchorID and an



Beck, et al.              Expires 19 March 2026                 [Page 6]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   extnValue containing a DER-encoded TrustAnchorID structure, defined
   below.  The TrustAnchorID is the trust anchor ID's ASN.1
   representation, described in Section 3.  This extension MUST be non-
   critical.

   id-pe-trustAnchorID OBJECT IDENTIFIER ::=
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-pe(1) TBD }

   TrustAnchorID ::= RELATIVE-OID

   Relying parties MAY instead or additionally configure trust anchor
   IDs via some application-specific out-of-band information.

   Relying parties MAY support trust anchors without associated trust
   anchor IDs, but such trust anchors will not participate in this
   protocol.  Those trust anchors MAY participate in other trust anchor
   negotiation protocols, such as the certificate_authorities extension.

3.2.  Authenticating Party Configuration

   Authenticating parties are configured with one or more candidate
   certification paths to present in TLS, in some preference order.
   This preference order is used when multiple candidate paths are
   usable for a connection.  For example, the authenticating party may
   prefer candidates that minimize message size or have more performant
   private keys.

   Each candidate path which participates in this protocol must be
   configured with the trust anchor ID for its corresponding trust
   anchor.  It is RECOMMENDED, though not required, that this
   information come from the CA.  Section 6 defines a RECOMMENDED format
   for this information, along with an optional ACME [RFC8555] extension
   for CAs to send it.

   Authenticating parties MAY have candidate certification paths without
   associated trust anchor IDs, but such paths will not participate in
   this protocol.  Those paths MAY participate in other trust anchor
   negotiation protocols, such as the certificate_authorities extension.

4.  TLS Extension

   This section defines the trust_anchors extension, which is sent in
   the ClientHello, EncryptedExtensions, CertificateRequest, and
   Certificate messages in TLS 1.3 or later.






Beck, et al.              Expires 19 March 2026                 [Page 7]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


4.1.  Overview

   The trust_anchors extension is defined using the structures below:

   enum { trust_anchors(TBD), (2^16-1) } ExtensionType;

   opaque TrustAnchorID<1..2^8-1>;

   TrustAnchorID TrustAnchorIDList<0..2^16-1>;

   When the extension is sent in the ClientHello or CertificateRequest
   messages, the extension_data is a TrustAnchorIDList and indicates
   that the sender supports the specified trust anchors.  The list is
   unordered, and MAY be empty.  Each TrustAnchorID uses the binary
   representation, as described in Section 3.

   When the extension is sent in EncryptedExtensions, the extension_data
   is a TrustAnchorIDList containing the list of trust anchors that
   server has available, in the server's preference order, and MUST NOT
   be empty.

   When the extension is sent in Certificate, the extension_data MUST be
   empty and indicates that the sender sent the certificate because the
   certificate matched a trust anchor ID sent by the peer.  When used in
   this form, the extension may only be sent in the first
   CertificateEntry.  It MUST NOT be sent in subsequent ones.

4.2.  Certificate Selection

   A trust_anchors extension in the ClientHello or CertificateRequest is
   processed similarly to the certificate_authorities extension.  The
   relying party indicates some set of supported trust anchors in the
   ClientHello or CertificateRequest trust_anchors extension.  The
   authenticating party then selects a certificate from its candidate
   certification paths (see Section 3.2), as described in
   Section 4.4.2.2 of [RFC8446] and Section 4.4.2.3 of [RFC8446].  This
   process is extended as follows:

   If the ClientHello or CertificateRequest contains a trust_anchors
   extension, the authenticating party SHOULD send a certification path
   whose trust anchor ID appears in the relying party's trust_anchors
   extension.

   If the ClientHello or CertificateRequest contains both trust_anchors
   and certificate_authorities, certification paths that satisfy either
   extension's criteria may be used.  This additionally applies to
   future extensions which play a similar role.




Beck, et al.              Expires 19 March 2026                 [Page 8]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   If no certification paths satisfy either extension, the
   authenticating party MAY return a handshake_failure alert, or choose
   among fallback certification paths without considering trust_anchors
   or certification_authorities.  See Section 4.3 for additional
   guidance on selecting a fallback when the ClientHello contains
   trust_anchors.

   Sending a fallback allows the authenticating party to retain support
   for relying parties that do not implement any form of trust anchor
   negotiation.  In this case, the authenticating party must find a
   sufficiently ubiquitous trust anchor, if one exists.  However, only
   those relying parties need to be considered in this ubiquity
   determination.  Updated relying parties may continue to evolve
   without restricting fallback certificate selection.

   If the authenticating party sends a certification path that matches
   the relying party's trust_anchors extension, as described in
   Section 4.2, the authenticating party MUST send an empty
   trust_anchors extension in the first CertificateEntry of the
   Certificate message.  In this case, the certificate_list flexibility
   described in Section 4.4.2 of [RFC8446] no longer applies.  The
   certificate_list MUST contain a complete certification path, issued
   by the matching trust anchor, correctly ordered and with no
   extraneous certificates.  That is, each certificate MUST certify the
   one immediately preceding it, and the trust anchor MUST certify the
   final certificate.  The authenticating party MUST NOT send the
   trust_anchors extension in the Certificate message in other
   situations.

   If a relying party receives this extension in the Certificate
   message, it MAY choose to disable path building [RFC4158] and
   validate the peer's certificate list as pre-built certification path.
   Doing so avoids the unpredictable behavior of path-building, and
   helps ensure CAs and authenticating parties do not inadvertently
   provision incorrect paths.

4.3.  Retry Mechanism

   When the relying party is a client, it may choose not to send its
   full trust anchor ID list due to fingerprinting risks (see
   Section 8), or because the list is too large.  The client MAY send a
   subset of supported trust anchors, or an empty list.  This subset may
   be determined by, possibly outdated, prior knowledge about the
   server, such as Section 5 or past connections.

   To accommodate this, when receiving a ClientHello with trust_anchors,
   the server collects all candidate certification paths which:




Beck, et al.              Expires 19 March 2026                 [Page 9]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   *  Have a trust anchor ID, and

   *  Satisfy the conditions in Section 4.4.2.2 of [RFC8446], with the
      exception of certification_authorities, and any future extensions
      that play a similar role

   If this collection is non-empty, the server sends a trust_anchors
   extension in EncryptedExtensions, containing the corresponding trust
   anchor IDs in preference order.

   When a client sends a subset or empty list in trust_anchors, it
   SHOULD implement the following retry mechanism:

   If the client receives either a connection error or an untrusted
   certificate, the client looks in server's EncryptedExtensions for a
   trust anchor ID that it trusts.  If there are multiple, it selects an
   option based on the server's preference order and its local
   preferences.  It then makes a new connection to the same endpoint,
   sending only the selected trust anchor ID in the ClientHello
   trust_anchors extension.  If the EncryptedExtensions had no
   trust_anchor extension, or no match was found, the client returns the
   error to the application.

   Clients SHOULD retry at most once per connection attempt.

   [[TODO: Retrying in a new connection is expensive and cannot be done
   from within the TLS stack in most implementations.  Consider
   handshake modifications to instead retry within the same connection.
   https://github.com/tlswg/tls-trust-anchor-ids/issues/53 ]]

   This mechanism allows the connection to recover from a certificate
   selection failure, e.g. due to the client not revealing its full
   preference list, at additional latency cost.  Section 5 describes an
   optimization which can avoid this cost.

   This mechanism also allows servers to safely send fallback
   certificates that may not be as ubiquitously acceptable.  Without
   some form of trust anchor negotiation, servers are limited to
   selecting certification paths that are ubiquitously trusted in all
   supported clients.  This often means sending extra cross-certificates
   to target the lowest common denominator at a bandwidth cost.  If the
   ClientHello contains trust_anchors, the server MAY opportunistically
   send a less ubiquitous, more bandwidth-efficient path based on local
   heuristics, with the expectation that the client will retry when the
   heuristics fail.






Beck, et al.              Expires 19 March 2026                [Page 10]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


5.  DNS Service Parameter

   This section defines the tls-trust-anchors SvcParamKey [RFC9460].
   TLS servers can use this to advertise their available trust anchors
   in DNS, and aid the client in formulating its trust_anchors extension
   (see Section 4.3).  This allows TLS deployments to support clients
   with many trust anchors without incurring the overhead of a
   reconnect.

5.1.  Syntax

   The tls-trust-anchors parameter contains an ordered list of one or
   more trust anchor IDs, in server preference order.

   The presentation value of the SvcParamValue is a non-empty comma-
   separated list (Appendix A.1 of [RFC9460]).  Each element of the list
   is a trust anchor ID in the ASCII representation defined in
   Section 3.  Any other value is a syntax error.  To enable simpler
   parsing, this SvcParam MUST NOT contain escape sequences.

   The wire format of the SvcParamValue is determined by prefixing each
   trust anchor ID with its length as a single octet, then concatenating
   each of these length-value pairs to form the SvcParamValue.  These
   pairs MUST exactly fill the SvcParamValue; otherwise, the
   SvcParamValue is malformed.

   For example, if a TLS server has three available certification paths
   issued by 32473.1, 32473.2.1, and 32473.2.2, respectively, the DNS
   record in presentation syntax may be:

   example.net.  7200  IN SVCB 3 server.example.net. (
       tls-trust-anchors=32473.1,32473.2.1,32473.2.2 )

   The wire format of the SvcParamValue would be the 17 octets below.
   In the example, the octets comprising each trust anchor ID are placed
   on separate lines for clarity

   0x04, 0x81, 0xfd, 0x59, 0x01,
   0x05, 0x81, 0xfd, 0x59, 0x02, 0x01,
   0x05, 0x81, 0xfd, 0x59, 0x02, 0x02,











Beck, et al.              Expires 19 March 2026                [Page 11]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


5.2.  Configuring Services

   Services SHOULD include the trust anchor ID for each of their
   available certification paths, in preference order, in the tls-trust-
   anchors of their HTTPS or SVCB endpoints.  As TLS configuration is
   updated, services SHOULD update the DNS record to match.  The
   mechanism for this is out of scope for this document, but services
   are RECOMMENDED to automate this process.

   Services MAY have certification paths without trust anchor IDs, but
   those paths will not participate in this mechanism.

5.3.  Client Behavior

   When connecting to a service endpoint whose HTTPS or SVCB record
   contains the tls-trust-anchors parameter, the client first computes
   the intersection between its configured trust anchors and the
   server's provided list.  If this intersection is non-empty, the
   client MAY use it to determine the trust_anchors extension in the
   ClientHello (see Section 4.3).

   If doing so, the client MAY send a subset of this intersection to
   meet size constraints, but SHOULD offer multiple options.  This
   reduces the chance of a reconnection if, for example, the first
   option in the intersection uses a signature algorithm that the client
   doesn't support, or if the TLS server and DNS configuration are out
   of sync.

   Although this service parameter is intended to reduce trust anchor
   mismatches, mismatches may still occur in some scenarios.  Clients
   and servers MUST continue to implement the provisions described in
   Section 4.3, even when using this service parameter.

6.  Certificate Properties

   As described in Section 3.2, certification paths participating in
   this mechanism must be configured with a trust anchor ID.  This
   section introduces a RECOMMENDED extensible CertificatePropertyList
   structure for representing this and other additional properties of a
   certification path.  CertificatePropertyLists may be used as part of
   authenticating party configuration, and for CAs to communicate
   additional properties during certificate issuance.

   The extensibility aims to simplify application deployment as PKI
   mechanisms evolve.  When certificate issuance and application
   software is updated to pass this structure to the underlying TLS
   implementation, new properties may be transparently defined without
   changes to certificate and configuration management.



Beck, et al.              Expires 19 March 2026                [Page 12]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   A CertificatePropertyList is defined using the TLS presentation
   language (Section 3 of [RFC8446]) below:

   enum { trust_anchor_id(0), (2^16-1) } CertificatePropertyType;

   struct {
       CertificatePropertyType type;
       opaque data<0..2^16-1>;
   } CertificateProperty;

   CertificateProperty CertificatePropertyList<0..2^16-1>;

   The entries in a CertificatePropertyList MUST be sorted numerically
   by type and MUST NOT contain values with a duplicate type.  Inputs
   that do not satisfy these invariants are syntax errors and MUST be
   rejected by parsers.

   This document defines a single property, trust_anchor_id.  The data
   field of the property contains the binary representation of the trust
   anchor ID of the certification path's trust anchor, as described in
   Section 3.2.  Future documents may define other properties for use
   with other mechanisms.

   Authenticating parties MUST ignore properties with unrecognized
   CertificatePropertyType values.

6.1.  Media Type

   A certification path with its associated CertificatePropertyList may
   be represented in a PEM [RFC7468] structure in a file of type
   "application/pem-certificate-chain-with-properties".  Files of this
   type MUST use the strict encoding and MUST NOT include explanatory
   text.  The ABNF [RFC5234] for this format is as follows, where
   "stricttextualmsg" and "eol" are as defined in Section 3 of
   [RFC7468]:

   certchainwithproperties = stricttextualmsg eol stricttextualmsg
                             *(eol stricttextualmsg)

   The first element MUST be the encoded CertificatePropertyList.  The
   second element MUST be an end-entity certificate.  Each following
   certificate MUST directly certify the one preceding it.  The
   certificate representing the trust anchor MUST be omitted from the
   path.

   CertificatePropertyLists are encoded using the "CERTIFICATE
   PROPERTIES" label.  The encoded data is a serialized
   CertificatePropertyList, defined in Section 6.



Beck, et al.              Expires 19 March 2026                [Page 13]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   Certificates are encoded as in Section 5.1 of [RFC7468], except DER
   [X690] MUST be used.

   The following is an example file with a certification path containing
   an end-entity certificate and an intermediate certificate.

   -----BEGIN CERTIFICATE PROPERTIES-----
   TODO fill in an example
   -----END CERTIFICATE PROPERTIES-----
   -----BEGIN CERTIFICATE-----
   TODO fill in an example
   -----END CERTIFICATE-----
   -----BEGIN CERTIFICATE-----
   TODO fill in an example
   -----END CERTIFICATE-----

   The IANA registration for this media type is described in
   Section 10.2.

6.2.  ACME Extension

   The format defined in Section 6.1 can be used with ACME's alternate
   format mechanism (see Section 7.4.2 of [RFC8555]) as follows.  When
   downloading certificates, a supporting client SHOULD include
   "application/pem-certificate-chain-with-properties" in its HTTP
   Accept header (Section 12.5.1 of [RFC9110]).  When a supporting
   server sees such a header, it MAY then respond with that format to
   include a CertificatePropertyList with the certification path.  This
   CertificatePropertyList MAY include a trust_anchor_id property for
   use with this protocol, or other properties defined in another
   document.

   When used with ACME's alternate certificate chain mechanism (see
   Section 7.4.2 of [RFC8555]), this protocol removes the need for
   heuristics in determining which path to serve to which relying party.

   The authenticating party MAY combine the resulting certification
   paths with those from other ACME orders, or other sources, for a
   complete set of candidate paths to serve.

7.  Use Cases

   trust_anchors, like certificate_authorities, implements trust anchor
   negotiation.  That is, it allows an authenticating party to
   incorporate relying party trust anchors into certificate selection.
   trust_anchors allows a wider range of TLS applications to use trust
   anchor negotiation, notably those that would be unable to use
   certificate_authorities due to size or privacy limitations.



Beck, et al.              Expires 19 March 2026                [Page 14]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   Without trust anchor negotiation, authenticating parties are limited
   to CAs in the intersection of all supported relying parties.
   However, trust anchors can vary significantly between different
   relying party implementations and different versions of a single
   relying party implementation, particularly as PKIs evolve to meet
   user security needs.

   As security-positive PKI changes increase variance, this intersection
   shrinks.  This leads to a conflict between user security and service
   availability.  When the authenticating party cannot serve a
   certificate in the intersection, either the relying party must risk
   user security by not changing the PKI, or the authenticating party
   must degrade service availability by dropping support for some
   relying parties.

   The rest of this section discusses uses cases for trust anchor
   negotiation.

7.1.  Making Use of Newly-Trusted CAs

   When one relying party trusts a new CA, other relying parties, such
   as older ones, may not yet trust it.  Trust anchor negotiation allows
   an authenticating party to negotiate a certificate from the newer CA
   with relying parties that do trust it, while continuing to negotiate
   another certificate with relying parties that do not.  This allows
   PKI transitions to progress smoothly.  Connections can make use of,
   for example, a new CA's stronger signature algorithms, stronger
   validation practices, better automation, or more efficient
   certificate sizes, without interruptions to other connections.

   Without negotiation, the authenticating party is limited to its
   relying parties' intersection and must wait for every supported
   relying party to be updated before the transition even begins.  This
   wait could often take many years.  In some cases, such as with IoT
   devices, relying parties may never receive updates.

   In some contexts, other fields can provide a partial signal.  For
   example, post-quantum-capable relying parties may be detected with
   the signature_algorithms and signature_algorithms_cert extensions.
   However, this relies on all post-quantum CAs being added at roughly
   the same time and that they are sufficiently interchangeable to be
   negotiated with these extensions.  Trust anchor negotiation directly
   addresses this problem and allows for both gradual and possibly
   heterogeneous deployment of post-quantum CAs across relying parties.







Beck, et al.              Expires 19 March 2026                [Page 15]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


7.2.  Removing Untrustworthy CAs

   When CAs are determined to be untrustworthy, relying parties must
   remove them to mitigate the risk to user security.  Over time, this
   shrinks their intersection with older relying parties.  Without
   negotiation, the result is authenticating parties have fewer and
   fewer CA choices available.  Even determining the intersecting CAs
   can be difficult.  Often, the only option is to try the new
   certificate and monitor errors.  For authenticating parties that
   serve many diverse relying parties, this is a disruptive and risky
   process.

   Trust anchor negotiation removes this constraint.  If an
   authenticating party's CA is distrusted, it can use a new CA in
   addition to the existing one.  The addition does not risk outages for
   older relying parties and may be chosen from a wider set of CAs, as
   it only needs to be compatible with the relying parties that
   distrusted the other CA.

   Over time, the authenticating party can monitor which certificates it
   serves, and re-evaluate which CA or CAs to use.  For example, it may
   find the new CA was sufficient, or that older relying parties have
   since all been updated.  However, user security depends on the
   relying party's trust anchors, not the authenticating party's choice
   of CA, so this can occur asynchronously, based on serving needs and
   costs, rather than delay the response to a security incident.

7.3.  Key Rotation

   Despite the severity of root CA private key compromise and the
   benefits of routinely rotating cryptographic key material, such
   rotation in PKIs is often very rare.  In 2023, the oldest root in
   [CHROME-ROOTS] and [MOZILLA-ROOTS] was 25 years old, dating to 1998.

   Key rotation in PKIs used in TLS is challenging, as it combines the
   challenges described in both Section 7.1 and Section 7.2.  Without
   trust anchor negotiation, authenticating parties cannot switch to the
   new root as long as any supported older relying party requires the
   old root.  That, in turn, means relying parties cannot distrust the
   old root, leaving them vulnerable.

   Trust anchor negotiation offers a smooth transition for CA key
   rotation.  The CA can provide certification paths for the old and new
   roots.  The authenticating party can then serve both paths without
   impacting older relying parties.  New relying parties can then
   distrust the old root.





Beck, et al.              Expires 19 March 2026                [Page 16]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


7.4.  Other Root Transitions

   The mechanisms in this document can aid PKI transitions beyond key
   rotation.  For example, a CA operator may generate a postquantum root
   CA and issue from the classical and postquantum roots concurrently.
   The authenticating party will then, transparently and with no
   configuration change, serve both.  As in Section 7.3, newer relying
   parties can then remove the classical roots, while older relying
   parties continue to function.

   This same procedure may also be used to transition between newer,
   more size-efficient signature algorithms, as they are developed.

7.5.  Intermediate Elision

   In my PKIs, root CAs issue shorter-lived intermediate certificates
   which, in turn, issue end-entity certificates.  This comes at a
   bandwidth cost: the TLS handshake includes an extra certificate,
   which includes a public key, signature, and X.509 metadata.  Post-
   quantum signature algorithms will dramatically increase this cost.
   ML-DSA-65 [FIPS204], for example, has a total public key and
   signature size of 5,261 bytes.

   [I-D.ietf-tls-cert-abridge] predistributes a specific set of
   intermediate CA certificates to relying parties so that these
   certificates can be omitted from TLS connections, as a compression
   scheme.  Negotiating intermediate CAs as short-lived trust anchors
   also achieves this effect, but is usable by more relying parties than
   the specific intermediate set accommodates.

   In this model, a CA operator provides authenticating parties with two
   certification paths: a longer path ending at a long-lived root and
   shorter path the other ending at a short-lived root.  Relying parties
   trust both the long-lived root and the most recent short-lived root.
   The authenticating party sends the shorter path when possible,
   falling back to the longer path when the relying party’s short-lived
   root is stale.

   This achieves the same effect with a simpler and more flexible,
   general-purpose mechanism.











Beck, et al.              Expires 19 March 2026                [Page 17]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


7.6.  Conflicting Relying Party Requirements

   An authenticating party may need to support relying parties with
   different, potentially conflicting requirements.  For example, in
   contexts where online revocation checks are expensive, unreliable, or
   privacy-sensitive, user security is best served by short-lived
   certificates.  In other contexts, long-lived certificates may be more
   appropriate for, e.g., systems that are offline for long periods of
   time or have unreliable clocks.

   Trust anchor negotiation allows these conflicts to be resolved by
   different trust anchors where necessary.  This avoids the need to
   compromise on user security or service availability.

7.7.  Backup Certificates

   An authenticating party may obtain certificate paths from multiple
   CAs for redundancy.  If one CA is compromised and removed from newer
   relying parties, the TLS server software will be able to gracefully
   serve a backup certificate path, avoiding the immediate breakage that
   would otherwise be caused by this removal.

7.8.  Public Key Pinning

   To reduce security risk from misissued certificates, relying parties
   sometimes employ public key pinning [RFC7469].  Pinning effectively
   reduces a relying party's trust anchor list to a subset of the
   original set.

   As other relying parties in the PKI evolve, the pinning relying party
   limits the authenticating party to satisfy both the pinning
   constraint and newer constraints in the PKI.  This can lead to
   conflicts if, for example, the pinned CA is distrusted by a newer
   relying party.  The authenticating party is then forced to either
   break the pinning relying party, or break the newer ones.

   Trust anchor negotiation reduces this conflict, provided the pinning
   relying party negotiates with its reduced trust anchor list.  The
   authenticating party can then use a certificate from the pinned CA
   with the pinning relying party, and another CA with other relying
   parties.

8.  Privacy Considerations








Beck, et al.              Expires 19 March 2026                [Page 18]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


8.1.  Relying Parties

   The trust_anchors extension is analogous to the
   certificate_authorities extension (Section 4.2.4 of [RFC8446]), but
   more size-efficient.  Like certificate_authorities, trust_anchors
   reveals some information about the relying party's trust anchors.
   However, unlike certificate_authorities, trust_anchors allows a
   relying party to only reveal a trust anchor in response to the
   authenticating party's list, which reduces the fingerprinting
   exposure.  This section provides guidance for a relying party to
   configure this mechanism, based on its privacy goals.

   When using this extension, a relying party's trust anchors may be
   divided into three categories:

   1.  Trust anchors whose IDs the relying party never sends, but still
       trusts.  These are trust anchors that do not participate in this
       mechanism.

   2.  Trust anchors whose IDs the relying party sends _conditionally_,
       i.e. only if the server offers them.  For example, the relying
       party may indicate support for a trust anchor if its ID is listed
       in the server's HTTPS/SVCB record or trust anchor list in
       EncryptedExtensions.

   3.  Trust anchors whose IDs the relying party sends
       _unconditionally_, i.e. independently of the authenticating
       party's behavior.

   Each of these categories carries a different fingerprinting exposure:

   Trust anchors that do not participate are not revealed by this
   extension.  However, they have some fingerprinting exposure due to
   being trusted.  Given a certification path, an authenticating party
   can probe whether the relying party trusts the trust anchor by seeing
   if the relying party accepts it.

   Trust anchor IDs sent in response to the authenticating party can
   only be observed actively.  That is, the authenticating party could
   vary its list and observe how the client responds, in order to probe
   for the client's trust anchor list.  This is similar to the exposure
   of trust anchors not participating in this extension, except that the
   trust anchor can be probed by only knowing the trust anchor ID.

   Trust anchor IDs sent unconditionally can be observed passively.
   This mode is analogous to the certificate_authorities extension.
   Relying parties SHOULD NOT unconditionally advertise trust anchor
   lists that are unique to an individual user.  Rather,



Beck, et al.              Expires 19 March 2026                [Page 19]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   unconditionally-advertised lists SHOULD be empty or computed only
   from the trust anchors common to the relying party's anonymity set
   (Section 3.3 of [RFC6973]).

   Relying parties SHOULD determine which trust anchors participate in
   this mechanism, and whether to advertise them unconditionally or
   conditionally, based on their privacy goals.  PKIs that reliably use
   the DNS service parameter (Section 5) can rely on conditional
   advertisement for stronger privacy properties without a round-trip
   penalty.

   Additionally, a relying party that computes the trust_anchors
   extension based on prior state may allow observers to correlate
   across connections.  Relying parties SHOULD NOT maintain such state
   across connections that are intended to be uncorrelated.  As above,
   implementing the DNS service parameter can avoid a round-trip penalty
   without such state.

8.2.  Authenticating Parties

   If the authenticating party is a server, the mechanisms in Section 5
   and Section 4.3 enumerate the trust anchors for the server's
   available certification paths.  This mechanism assumes they are not
   sensitive.  Servers SHOULD NOT use this mechanism to negotiate
   certification paths with sensitive trust anchors.

   In servers that host multiple services, this protocol only enumerates
   certification paths for the requested service.  If, for example, a
   server uses the server_name extension to select services, the
   addition to EncryptedExtensions in Section 4.3 is expected to be
   filtered by server_name.  Likewise, the DNS parameter in Section 5
   only contains information for the corresponding service.  In both
   cases, co-located services are not revealed.

   The above does not apply if the authenticating party is a client.
   This protocol does not enumerate the available certification paths
   for a client.

9.  Security Considerations

9.1.  Incorrect Selection Metadata

   If the authenticating party has provisioned certification paths with
   incorrect trust anchor IDs, it may negotiate inaccurately and send an
   untrusted path to the relying party when another candidate would have
   been trusted.  This will not result in the untrusted path becoming
   trusted, but the connection will fail.




Beck, et al.              Expires 19 March 2026                [Page 20]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


9.2.  Trust Anchor Negotiation

   Both the trust_anchors and certificate_authorities (Section 4.2.4 of
   [RFC8446]) extensions implement trust anchor negotiation, so security
   considerations are largely unchanged from certificate_authorities.
   This section discusses security considerations for trust anchor
   negotiation in general.

9.2.1.  Relying Party Policies

   PKI-based TLS authentication depends on the relying party's
   certificate policies.  If the relying party trusts an untrustworthy
   CA, that CA can intercept TLS connections made by that relying party
   by issuing certificates associating the target name with the wrong
   TLS key.

   This attack vector is available with or without trust anchor
   negotiation.  The negotiation mechanism described in this document
   allows certificate selection to reflect a relying party's certificate
   policies.  It does not determine the certificate policies themselves.
   Relying parties remain responsible for trusting only trustworthy CAs,
   and untrustworthy CAs remain a security risk when trusted.

9.2.2.  Agility

   As with other TLS parameters, negotiation reduces a conflict between
   availability and security, which allows PKIs to better mitigate
   security risks to users.  When relying parties in an existing TLS
   ecosystem improve their certificate policies, trust anchor
   negotiation helps authenticating parties navigate differences between
   those relying parties and existing relying parties.  Each set of
   requirements may be satisfied without compatibility risk to the
   other.  Section 7 discusses such scenarios in more detail.

   Negotiation also reduces pressures on relying parties to sacrifice
   user security for compatibility.  If a relying party does not trust
   an authenticating party's current CA, connections between the two
   will fail until either the relying party trusts the CA or the
   authenticating party uses an already trusted CA.  Without trust
   anchor negotiation, the authenticating party is limited to one
   certificate, and therefore switching CAs risks compatibility problems
   with other relying parties.  The relying party then faces
   compatibility pressure to add this CA, even if it deems the CA a
   security risk.  With trust anchor negotiation, the authenticating
   party can use its existing CA _in addition to_ another CA trusted by
   the relying party.  This allows the ecosystem to improve
   interoperability without sacrificing user security.




Beck, et al.              Expires 19 March 2026                [Page 21]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


9.2.3.  Serving Multiple Certificates

   Trust anchor negotiation reduces compatibility pressures against
   authenticating parties serving certificates from a less common CA, as
   they can be served with other certificates.  In some cases, the CA
   may have been distrusted, but still used to support older relying
   parties.  As discussed in Section 7 and Section 9.2.2, this
   capability aids PKI transitions that mitigate security risks to
   users.

   Even if the CA is untrustworthy, these certificates do not enable the
   CA to decrypt or intercept the connection.  If a certificate asserts
   the correct information about the authenticating party, notably the
   correct public key, the authenticating party can safely present it.
   Issuing a certificate for the authenticating party's public key does
   not grant the CA access to the corresponding private key.
   Conversely, if the attacker already has access to the authenticating
   party's private key, they do not need to be in control of a CA to
   intercept a connection.

   Rather, it is the relying party's choice of trusted CAs that
   determines susceptibility to interception.  If the relying party
   trusts a misbehaving or attacker-controlled CA, the attacker can
   intercept the connection with a public key certified by that CA,
   regardless of which CA is used by the intended authenticating party.
   Conversely, if the relying party does not trust the attacker's CA,
   the attacker cannot successfully intercept the connection using a
   public key certified by this CA.

   Choosing trusted CAs is a complex, security-critical process, the
   full considerations of which are outside the scope of this document.
   Relying parties thus SHOULD NOT interpret the authenticating party's
   choice of CA as an endorsement of the CA.  Trusting a CA means
   trusting _all_ certificates issued by that CA, so it is not enough to
   observe correct certificates from an authenticating party.  An
   untrustworthy CA may sign one correct certificate, but also sign
   incorrect certificates, possibly in the future, that can attack the
   relying party.

9.2.4.  Targeting TLS Interception

   A network attacker in possession of a misissued certificate could use
   trust anchor negotiation to differentiate clients and only enable TLS
   interception with clients that accept the certificate.  The network
   attacker may wish to do this to reduce the odds of detection.






Beck, et al.              Expires 19 March 2026                [Page 22]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   However, trust anchor negotiation only impacts detection where this
   differentiation was not already possible.  In TLS, the client offers
   all its available TLS features, including cipher suites and other
   extensions, in the TLS ClientHello.  Any variation in client TLS
   policies, related or unrelated to trust anchors, may be used as a
   fingerprint.  Transport properties, such as IP geolocation, may also
   be used.  While fingerprinting's heuristic nature makes broad,
   legitimate use difficult, a network attacker's single interception
   service can easily use it for targeted attacks.

   If the attacker targets any clients that enforce Certificate
   Transparency [RFC6962], the misissued certificates will need to be
   publicly logged.  In this case, detection is more robust, and client
   differentiation, with or without trust anchor negotiation, has no
   significant impact.

10.  IANA Considerations

10.1.  TLS ExtensionType Updates

   IANA is requested to create the following entry in the TLS
   ExtensionType Values registry, defined by [RFC8446]:

   +=======+===============+===+===========+=============+============+
   | Value | Extension     |TLS| DTLS-Only | Recommended | Reference  |
   |       | Name          |1.3|           |             |            |
   +=======+===============+===+===========+=============+============+
   | TBD   | trust_anchors |CH,| N         | Y           | [this-RFC] |
   |       |               |EE,|           |             |            |
   |       |               |CR,|           |             |            |
   |       |               |CT |           |             |            |
   +-------+---------------+---+-----------+-------------+------------+

                                 Table 1

10.2.  Media Type Updates

   IANA is requested to create the following entry in the "Media Types"
   registry, defined in [RFC6838]:

   Type name:  application

   Subtype name:  pem-certificate-chain-with-properties

   Required parameters:  None

   Optional parameters:  None




Beck, et al.              Expires 19 March 2026                [Page 23]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   Encoding considerations:  7bit

   Security considerations:  Carries a cryptographic certificate and its
      associated certificate chain and additional properties.  This
      media type carries no active content.

   Interoperability considerations:  None

   Published specification:  [this-RFC, Section 6.1]

   Applications that use this media type:  ACME clients and servers,
      HTTP servers, other applications that need to be configured with a
      certificate chain

   Additional information:  Deprecated alias names for this type:  n/a
                            Magic number(s):  n/a
                            File extension(s):  .pem
                            Macintosh file type code(s):  n/a

   Person & email address to contact for further information:  See
      Authors' Addresses section.

   Intended usage:  COMMON

   Restrictions on usage:  n/a

   Author:  See Authors' Addresses section.

   Change controller:  IETF

10.3.  PKIX Registry Updates

   IANA is requested to create the following entry in the SMI Security
   for PKIX Module Identifier registry, defined by [RFC7299]:

           +=========+============================+============+
           | Decimal | Description                | References |
           +=========+============================+============+
           | TBD     | id-mod-trustAnchorIDs-2025 | [this-RFC] |
           +---------+----------------------------+------------+

                                  Table 2

   IANA is requested to create the following entry in the SMI Security
   for PKIX Certificate Extension registry, defined by [RFC7299]:






Beck, et al.              Expires 19 March 2026                [Page 24]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


              +=========+=====================+============+
              | Decimal | Description         | References |
              +=========+=====================+============+
              | TBD     | id-pe-trustAnchorID | [this-RFC] |
              +---------+---------------------+------------+

                                 Table 3

10.4.  CertificatePropertyType Registry

   [[TODO: Establish a CertificatePropertyType registry.]]

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
              Nicholas, "Internet X.509 Public Key Infrastructure:
              Certification Path Building", RFC 4158,
              DOI 10.17487/RFC4158, September 2005,
              <https://www.rfc-editor.org/rfc/rfc4158>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/rfc/rfc5234>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/rfc/rfc5280>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/rfc/rfc6838>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://www.rfc-editor.org/rfc/rfc6973>.



Beck, et al.              Expires 19 March 2026                [Page 25]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   [RFC7299]  Housley, R., "Object Identifier Registry for the PKIX
              Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014,
              <https://www.rfc-editor.org/rfc/rfc7299>.

   [RFC7468]  Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
              PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
              April 2015, <https://www.rfc-editor.org/rfc/rfc7468>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/rfc/rfc8555>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [RFC9371]  Baber, A. and P. Hoffman, "Registration Procedures for
              Private Enterprise Numbers (PENs)", RFC 9371,
              DOI 10.17487/RFC9371, March 2023,
              <https://www.rfc-editor.org/rfc/rfc9371>.

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

   [X680]     ITU-T, "Information technology - Abstract Syntax Notation
              One (ASN.1): Specification of basic notation", ISO/
              IEC 8824-1:2021, 2021.

   [X690]     ITU-T, "Information technology - ASN.1 encoding Rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ISO/IEC 8825-1:2021, 2021.

11.2.  Informative References





Beck, et al.              Expires 19 March 2026                [Page 26]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   [CHROME-ROOTS]
              Chromium, "Chrome Root Store", 30 August 2023, <https://ch
              romium.googlesource.com/chromium/src/+/main/net/data/ssl/
              chrome_root_store>.

   [FIPS204]  National Institute of Standards and Technology (NIST),
              "Module-Lattice-based Digital Signature Standard", FIPS
              PUB 204, August 2023, <https://csrc.nist.gov/projects/
              post-quantum-cryptography>.

   [I-D.ietf-tls-cert-abridge]
              Jackson, D., "Abridged Compression for WebPKI
              Certificates", Work in Progress, Internet-Draft, draft-
              ietf-tls-cert-abridge-02, 16 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              cert-abridge-02>.

   [MOZILLA-ROOTS]
              Mozilla, "Mozilla Included CA Certificate List", 30 August
              2023, <https://wiki.mozilla.org/CA/Included_Certificates>.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <https://www.rfc-editor.org/rfc/rfc6962>.

   [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
              Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
              2015, <https://www.rfc-editor.org/rfc/rfc7469>.

Appendix A.  ASN.1 Module





















Beck, et al.              Expires 19 March 2026                [Page 27]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   TrustAnchorIDs-2025
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-trustAnchorIDs-2025(TBD) }

   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

   IMPORTS
       EXTENSION
       FROM PKIX-CommonTypes-2009 -- From [RFC5912]
       { iso(1) identified-organization(3) dod(6)
         internet(1) security(5) mechanisms(5) pkix(7)
         id-mod(0) id-mod-pkixCommon-02(57) };

   -- Trust Anchor IDs Certificate Extension

   ext-TrustAnchorID EXTENSION ::= {
       SYNTAX TrustAnchorID
       IDENTIFIED BY id-pe-trustAnchorID
       CRITICALITY { FALSE } }

   id-pe-trustAnchorID OBJECT IDENTIFIER ::=
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-pe(1) TBD }

   TrustAnchorID ::= RELATIVE-OID

   END

Acknowledgements

   The authors thank Nick Harper, and Emily Stark for many valuable
   discussions and insights which led to this document.  Thanks also to
   Aaron Gable for providing feedback on ACME extensions.

Authors' Addresses

   Bob Beck
   OpenSSL
   Email: beck@openssl.org


   David Benjamin
   Google LLC
   Email: davidben@google.com





Beck, et al.              Expires 19 March 2026                [Page 28]

Internet-Draft        TLS Trust Anchor Identifiers        September 2025


   Devon O'Brien
   Email: devon.obrien@gmail.com


   Kyle Nekritz
   Meta
   Email: knekritz@meta.com












































Beck, et al.              Expires 19 March 2026                [Page 29]
