Skip to main content

TLS Trust Expressions

Document Type Active Internet-Draft (individual)
Authors David Benjamin , Devon O'Brien , Bob Beck
Last updated 2023-10-23
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Transport Layer Security                                     D. Benjamin
Internet-Draft                                                D. O'Brien
Intended status: Standards Track                                 B. Beck
Expires: 25 April 2024                                        Google LLC
                                                         23 October 2023

                         TLS Trust Expressions


   This document defines TLS trust expressions, a mechanism for relying
   parties to succinctly convey trusted certification authorities to
   subscribers by referencing named and versioned trust stores.  It also
   defines supporting mechanisms for subscribers to evaluate these trust
   expressions, and select one of several available certification paths
   to present.  This enables a multi-certificate deployment model, for a
   more agile and flexible PKI that can better meet security

About This Document

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

   The latest revision of this draft can be found at
   trust-expr.html.  Status information for this document may be found

   Discussion of this document takes place on the Transport Layer
   Security Working Group mailing list (, which is
   archived at  Subscribe

   Source for this draft and an issue tracker can be found at

Status of This Memo

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

   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

Benjamin, et al.          Expires 25 April 2024                 [Page 1]
Internet-Draft            TLS Trust Expressions             October 2023

   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 25 April 2024.

Copyright Notice

   Copyright (c) 2023 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 (
   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 . . . . . . . . . . . . . . . . .   4
     2.1.  Time  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Terminology and Roles . . . . . . . . . . . . . . . . . .   5
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Trust Store Manifests . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Trust Store Entry Expiration  . . . . . . . . . . . . . .   8
     4.2.  Labels  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Certificate Properties  . . . . . . . . . . . . . . . . . . .   9
     5.1.  Trust Store Inclusion . . . . . . . . . . . . . . . . . .  10
     5.2.  Computing Trust Store Inclusions  . . . . . . . . . . . .  12
     5.3.  Media Type  . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  TLS Certificate Negotiation . . . . . . . . . . . . . . . . .  13
     6.1.  Trust Expressions . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Subscriber Acknowledgement  . . . . . . . . . . . . . . .  14
     6.3.  Evaluating Trust Expressions  . . . . . . . . . . . . . .  15
     6.4.  Subscriber Behavior . . . . . . . . . . . . . . . . . . .  16
     6.5.  Constructing Trust Expressions  . . . . . . . . . . . . .  17
   7.  Issuing Certificates  . . . . . . . . . . . . . . . . . . . .  18
     7.1.  ACME Extension  . . . . . . . . . . . . . . . . . . . . .  18
   8.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  24
     9.1.  Key Rotation  . . . . . . . . . . . . . . . . . . . . . .  24
     9.2.  Adding CAs  . . . . . . . . . . . . . . . . . . . . . . .  25
     9.3.  Removing CAs  . . . . . . . . . . . . . . . . . . . . . .  26

Benjamin, et al.          Expires 25 April 2024                 [Page 2]
Internet-Draft            TLS Trust Expressions             October 2023

     9.4.  Intermediate Elision  . . . . . . . . . . . . . . . . . .  27
     9.5.  Conflicting Relying Party Requirements  . . . . . . . . .  28
     9.6.  Backup Certificates . . . . . . . . . . . . . . . . . . .  28
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  28
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  29
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
     12.1.  TLS ExtensionType Updates  . . . . . . . . . . . . . . .  30
     12.2.  Media Type Updates . . . . . . . . . . . . . . . . . . .  30
     12.3.  ACME Order Object Fields Updates . . . . . . . . . . . .  31
     12.4.  CertificatePropertyType Registry . . . . . . . . . . . .  31
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  31
     13.2.  Informative References . . . . . . . . . . . . . . . . .  33
   Appendix A.  CDDL Schema  . . . . . . . . . . . . . . . . . . . .  34
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  34
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35

1.  Introduction

   TLS [RFC8446] endpoints typically authenticate using X.509
   certificates [RFC5280].  These certificates are issued by a
   certification authority (CA) and associate the TLS public key with
   some application identifier, such as a DNS name.  If the CA is among
   those trusted by the peer, it will accept this association.  The
   authenticating party is known as the subscriber and the peer is the
   relying party.

   Subscribers typically provision a single certificate for all
   supported relying parties, because relying parties do not communicate
   which CAs are trusted.  The certificate must then meet all relying
   party requirements simultaneously.  This constraint imposes
   significant costs on CAs, subscribers, and relying parties:

   *  It is difficult for newer CAs to enter the ecosystem if they are
      not trusted by all relying parties, including older ones.
      Existing CAs face similar challenges when rotating or deploying
      new keys.

   *  Single-certificate deployments on subscribers are fragile,
      particularly in the face of distrusts or other changes to what a
      relying party accepts.

   *  When a relying party must update its policies to meet new security
      requirements, it must choose between compromising on user security
      or imposing a significant burden on subscribers.

Benjamin, et al.          Expires 25 April 2024                 [Page 3]
Internet-Draft            TLS Trust Expressions             October 2023

   Deploying multiple certification paths would avoid these issues.
   However, relying parties and subscribers must then negotiate which to
   send in each connection.  Section 4.2.4 of [RFC8446] defines the
   certificate_authorities extension, but it is often impractical.  Some
   trust stores are large, and the X.509 Name structure is inefficient.
   For example, as of August 2023, the Mozilla CA Certificate Program
   [MOZILLA-ROOTS] would encode 144 names totaling 14,457 bytes.

   This document defines a TLS extension and supporting mechanisms that
   allow relying parties and subscribers to succinctly communicate
   supported trust anchors to subscribers, using pre-shared information
   provisioned by root programs and CAs, respectively.  This enables a
   multi-certificate deployment model, which supports a more flexible,
   robust Public Key Infrastructure (PKI).  Section 9 discusses several
   deployment use cases that are directly improved by this model.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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].

2.1.  Time

   Times in this document are represented by POSIX timestamps, which are
   integers containing a number of seconds since the Epoch, defined in
   Section 4.16 of [POSIX].  That is, the number of seconds after
   1970-01-01 00:00:00 UTC, excluding leap seconds.  A UTC time is
   converted to a POSIX timestamp as described in [POSIX].

   Durations of time are integers, representing a number of seconds not
   including leap seconds.  They can be added to POSIX timestamps to
   produce other POSIX timestamps.

   The current time is a POSIX timestamp determined by converting the
   current UTC time to seconds since the Epoch as per Section 4.16 of
   [POSIX].  One POSIX timestamp is said to be before (respectively,
   after) another POSIX timestamp if it is less than (respectively,
   greater than) the other value.

Benjamin, et al.          Expires 25 April 2024                 [Page 4]
Internet-Draft            TLS Trust Expressions             October 2023

2.2.  Terminology and Roles

   This document discusses four roles:

   Subscriber:  The party whose identity is being validated in the
      protocol.  In TLS, this is the side sending the Certificate and
      CertificateVerify message.

   Relying party:  The party that authenticates the subscriber.  In TLS,
      this is the side that validates a Certificate and
      CertificateVerify message.

   Certification authority (CA):  The service that issues certificates
      to the subscriber.

   Root program:  An entity that manages a set of common trusted CAs for
      a set of relying parties.

   While the first three roles are common to most X.509 deployments,
   this document discusses the role of a root program as distinct from
   the relying party.  Trust decisions are often common between related
   relying parties, such as multiple clients running the same
   application.  The root program is the entity making those common
   decisions, such as the software vendor for the application or
   operating system.

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

   Trust anchor:  A pre-distributed public key or certificate that
      relying parties use to determine whether a certification path is

   Trust store:  A collection of trust anchors managed by the root

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

   Trust store manifest:  A structure describing a series of versioned
      trust stores.

   Trust expression:  A compact description of a relying party's trust
      store contents, referencing named, versioned trust stores.

   CertificatePropertyList:  A structure associated with a certification

Benjamin, et al.          Expires 25 April 2024                 [Page 5]
Internet-Draft            TLS Trust Expressions             October 2023

      path, containing additional information from the CA, for use by
      the subscriber when presenting the certification path.

   TrustStoreInclusionList:  A property in the CertificatePropertyList
      which describes the corresponding trust anchor's inclusion in
      trust stores.  This is used by the subscriber when evaluating
      trust expressions.

3.  Overview

   In the TLS handshake, a client (respectively, server) relying party
   sends trust expressions, which reference named, versioned trust
   stores to describe a list of trust anchors.  The subscriber uses this
   information to select a certification path to return.

   These structures are intended to be provisioned by root programs and
   CAs as follows:

   *  Root programs maintain versions of a trust store over time in a
      trust store manifest, which is published to a well-known location.
      (See Section 4.)

   *  CAs regularly fetch trust store manifests.  CAs use these
      manifests to associate TrustStoreInclusionList structures with
      issued certification paths.  This communicates the trust anchor's
      inclusion status to subscribers.  (See Section 5.1.)

   *  The CA issues multiple certification paths to subscribers, which
      together cover all supported relying parties.  The provisioning
      process is expected to be automated.  (See Section 7).

   *  When updating a relying party's list of supported trust anchors,
      root programs also send a compact description as a
      TrustExpressionList.  (See Section 6.5.)

   *  During a TLS handshake, relying parties send their
      TrustExpressionList to subscribers.  (See Section 6.1.)

   *  Subscribers select certification paths by evaluating the
      TrustExpressionList with each path's TrustStoreInclusionList.
      Subscribers are then assured that all supported relying parties
      will be satisfied by some available path.  (See Section 6.4.)

   By providing accurate trust anchor negotiation, this process avoids
   the need for relying parties to perform path-building [RFC4158].
   Certification paths can be pre-constructed to end at one of the
   relying party's supported anchors.

Benjamin, et al.          Expires 25 April 2024                 [Page 6]
Internet-Draft            TLS Trust Expressions             October 2023

4.  Trust Store Manifests

   This section defines a trust store manifest, which is a structure
   published by the root program to some well-known location.  These
   manifests are used to compute certificate properties for the
   subscriber (Section 5) and trust expressions for the relying party
   (Section 6).

   Trust store manifests are identified by a short, unique trust store
   name and define a list of trust store versions.  A trust store
   version contains a set of trust anchors, and is identified by a name
   (from the manifest) and a version number.

   [[TODO: Trust store names need to be unique, or at least unique among
   relying parties and subscribers that talk to each other, but also
   short.  How do we allocate them?  Registry?  Just pick values?

   A trust store manifest is a JSON object [RFC8259] containing:

   name:  A string containing a short, unique name that identifies the
      collection of trust stores

   max_age:  A non-negative integer containing the number of seconds
      that this document may be cached.

   trust_anchors:  A non-empty object describing a set of trust anchors.
      Each member's name is a short identifier for the trust anchor,
      used in entries below.  Each member's value is an object
      describing the trust anchor, containing:

      type:  A string describing the type of trust anchor.

      In this document, the value of type is always "x509".  In this
      case, the object additionally contains a member data whose value
      is a string containing a base64-encoded [RFC4648], DER-encoded
      [X690] X.509 certificate.

      Future documents may extend this format with other trust anchor
      types.  Recipients MUST ignore trust anchors with unrecognized

   versions:  A non-empty array describing versions of the trust store.
      Each element of the array is a JSON object containing:

      timestamp:  An integer, which is the time at which this trust
         store version was defined, as a POSIX timestamp (see
         Section 2.1).

Benjamin, et al.          Expires 25 April 2024                 [Page 7]
Internet-Draft            TLS Trust Expressions             October 2023

      entries:  A non-empty array describing the contents of this
         version of the trust store.  These are known as trust store
         entries.  Each element is an object containing:

         id:  A string containing the name of some member of the
            trust_anchors object.

         labels:  A non-empty array of non-negative, 24-bit integer
            labels associated with the trust anchor.  See Section 4.2
            for how this field is interpreted.

         max_lifetime:  A non-negative integer containing the maximum
            lifetime, in seconds, of certification paths that this trust
            anchor is expected to issue.

   Versions in versions are identified by their zero-indexed position in
   the array.  That is, the first entry is version 0, the second is
   version 1, and so on.

   Recipients MUST ignore JSON object members with unrecognized names in
   each of the objects defined above.  Future documents MAY extend these
   formats with new names.  Appendix A contains a CDDL [RFC8610]
   describing the above structure.

   When updating a trust store manifest, root programs append a new
   object to the versions array to represent the new trust store
   version.  When the new object references a trust anchor, the root
   program uses the existing members of trust_anchors, or adds new
   members as required.  Updates MUST NOT modify or remove existing
   entries in the versions array.

4.1.  Trust Store Entry Expiration

   The max_age and max_lifetime fields define an expiration time for
   trust store entries in versions other than the latest version.  For a
   trust store entry in version V, the expiration time is the sum of:

   *  The timestamp of the subsequent version, i.e. version V+1

   *  The max_age of the manifest

   *  The max_lifetime of the trust store entry

   Expiration times for entries in the latest version are not defined.
   They are determined once the root store appends a new version.

Benjamin, et al.          Expires 25 April 2024                 [Page 8]
Internet-Draft            TLS Trust Expressions             October 2023

   Trust store entries are not removed from their containing version
   after they expire.  Rather, the expiration time is the point at which
   all unexpired certificates have incorporated information about
   subsequent trust store versions, per Section 5.2.  This ensures the
   negotiation procedures in Section 6.3 and Section 6.5 interoperate.

4.2.  Labels

   Trust store entries reference labels, which are 24-bit integers that
   identify subsets of a trust store version.  These integers are
   defined relative to the trust store manifest and are not globally
   unique.  Root programs allocate labels when defining versions of a
   trust store.

   Labels are used in trust expressions (Section 6.1) to exclude trust
   anchor entries from the expression.  A label may identify an
   individual trust anchor if it is the only one with that label, or
   multiple trust anchors if they share the label.

   The root program's label allocation scheme determines which sets may
   be efficiently represented.  In particular, when trust anchors are
   removed in a later version of a trust store, trust expressions must
   express the removed set with labels as described in Section 6.5.
   Root programs SHOULD allocate individual labels for each trust
   anchor, and shared labels for trust anchors that will likely be
   removed together.  For example, the root program may allocate shared
   labels for trust anchors with the same operator, or trust anchors
   that use some signature algorithm if it expects some relying parties
   to exclude by algorithm.

   When allocating labels, root programs MAY repurpose a previously
   allocated label value after all previous entries referencing it have
   expired (Section 4.1).

5.  Certificate Properties

   In order to evaluate references to trust stores, e.g. in Section 6.1,
   subscribers require information about which trust stores contain each
   candidate certification path's trust anchor.  This document
   introduces an extensible CertificatePropertyList structure to carry
   this information.

   CertificatePropertyLists are constructed by CAs and sent to
   subscribers, alongside the certification path itself.  They contain a
   list of properties the subscriber may use when presenting the
   certificate, e.g. as an input to certificate negotiation
   (Section 6.4).

Benjamin, et al.          Expires 25 April 2024                 [Page 9]
Internet-Draft            TLS Trust Expressions             October 2023

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

   enum { trust_stores(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_stores, which
   describes trust store inclusion.  Future documents may define other
   properties for use with other mechanisms.

   Subscribers MUST ignore unrecognized properties with
   CertificatePropertyType values.  If ignoring a property would cause
   such subscribers to misinterpret the structure, the document defining
   the CertificatePropertyType SHOULD include a mechanism for CAs to
   negotiate the new property with the subscriber in certificate
   management protocols such as ACME [RFC8555].  For example,
   Section 7.1 defines a "trustExpressions" ACME order field.

5.1.  Trust Store Inclusion

   The trust_stores property specifies which trust stores contain the
   certification path's trust anchor.  Its data field contains a
   TrustStoreInclusionList, defined below:

Benjamin, et al.          Expires 25 April 2024                [Page 10]
Internet-Draft            TLS Trust Expressions             October 2023

   enum {
   } TrustStoreStatus;

   struct {
       opaque name<1..2^8-1>;
       uint24 version;
   } TrustStore;

   struct {
       TrustStore trust_store;
       TrustStoreStatus status;
       uint24 labels<1..2^16-1>;
   } TrustStoreInclusion;

   TrustStoreInclusion TrustStoreInclusionList<1..2^16-1>;

   Each TrustStoreInclusion describes a trust store version which
   contains this certification path's trust anchor. trust_store
   specifies a version of the trust store, and labels specifies the
   trust anchor's labels within that trust store.

   If status is latest_version_at_issuance, trust_store was the latest
   trust store of its name at the time the certificate was issued.  In
   this case, the trust expression evaluation algorithm (Section 6.3)
   predicts this information additionally applies to all versions
   greater than trust_store's version, up to the expiration of the
   certification path.

   A TrustStoreInclusionList MUST satisfy the following invariants:

   *  Each TrustStoreInclusion has a unique trust_store value.

   *  The TrustStoreInclusion structures are sorted, first by length of
      trust_store's name, then by trust_store's name lexicographically,
      then by trust_store's version.

   *  If status is latest_version_at_issuance in some
      TrustStoreInclusion, no trust_store with the same name but higher
      version appears in the list.

Benjamin, et al.          Expires 25 April 2024                [Page 11]
Internet-Draft            TLS Trust Expressions             October 2023

5.2.  Computing Trust Store Inclusions

   Each CA regularly fetches trust store manifests from root programs in
   which it participates, caching the most recently fetched manifest
   from each root program.  When issuing a certification path to a
   subscriber, it runs the following procedure on each root program's
   trust store manifest, to compute a list of TrustStoreInclusions:

   1.  If the cached manifest was fetched more than max_age seconds ago,
       fetch and cache a new copy.

   2.  For each trust store version in the cached manifest's versions:

       a.  Look for a trust store entry whose id, when indexed into
           trust_anchors, matches the certification path's trust anchor.

       b.  If found, output a TrustStoreInclusion structure:

           *  Set trust_store to the manifest's name, encoded in UTF-8
              [RFC3629], and the version's version number.

           *  Set status to latest_version_at_issuance if the trust
              store version is currently the latest version.  Otherwise,
              set it to previous_version.

           *  Set labels to the trust store entry's labels.

   If the above procedure outputs a TrustStoreInclusion with status of
   latest_version_at_issuance, the certification path's lifetime MUST
   NOT exceed the corresponding trust store entry's max_lifetime field.
   This ensures the procedures in Section 6.3 and Section 6.5
   interoperate correctly.

   The CA combines the outputs of this procedure for each known manifest
   to form the final TrustStoreInclusionList.  To aid the CA in
   collecting manifests, repositories such as [CCADB] can publish a
   directory of trust store manifests from participating root programs.

5.3.  Media Type

   A certification path with its associated CertificationPropertyList
   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

Benjamin, et al.          Expires 25 April 2024                [Page 12]
Internet-Draft            TLS Trust Expressions             October 2023

   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 that represents the trust anchor MUST be omitted from the

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

   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.

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

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

6.  TLS Certificate Negotiation

   This section defines the trust_expressions extension, which is sent
   in the ClientHello, CertificateRequest, and Certificate messages.

6.1.  Trust Expressions

   When the trust_expressions extension is sent in ClientHello and
   CertificateRequest, the extension_data field is a
   TrustExpressionList, defined below:

Benjamin, et al.          Expires 25 April 2024                [Page 13]
Internet-Draft            TLS Trust Expressions             October 2023

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

   struct {
       TrustStore trust_store;
       uint24 excluded_labels<0..2^16-1>;
   } TrustExpression;

   TrustExpression TrustExpressionList<1..2^16-1>;

   A TrustExpressionList is an unordered set of TrustExpression objects.
   When a relying party sends a TrustExpressionList, it indicates
   support for all trust anchors specified by any TrustExpression
   contained in the list.  A TrustExpression specifies a list of trust
   anchors in two parts:

   First, trust_store specifies a trust store by name and version (see
   Section 4).  Any trust anchors contained in the specified trust store
   are included.

   Second, excluded_labels specifies a set of labels, each of which
   identify one or more trust anchors in a trust store manifest.  Any
   trust anchors identified by any label in excluded_labels are
   excluded.  Section 6.5 discusses this set in more detail.

   excluded_labels MUST be sorted in ascending order and contain no
   duplicate values to be valid.  If invalid, receivers MUST terminate
   the connection with an illegal_parameter alert.

   Together, a TrustExpression indicates that the relying party accepts
   all trust anchors in the referenced trust store version, except for
   any that were excluded via excluded_labels.

6.2.  Subscriber Acknowledgement

   When the trust_expressions extension is sent in a Certificate
   message, the extension MUST be in the first CertificateEntry and the
   extension_data field MUST be empty.  This extension indicates the
   subscriber selected a certification path using trust expressions.

   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, 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.

Benjamin, et al.          Expires 25 April 2024                [Page 14]
Internet-Draft            TLS Trust Expressions             October 2023

   If a relying party receives this extension in the Certificate
   message, it SHOULD NOT use path building [RFC4158] to validate the

6.3.  Evaluating Trust Expressions

   Given a certification path with a trust_store certificate property
   (Section 5.1), a subscriber can evaluate a TrustExpressionList to
   determine whether the certification path matches.

   A TrustExpression is said to match a TrustStoreInclusionList if there
   is at least one TrustStoreInclusion in the TrustStoreInclusionList
   such that all of the following are true:

   *  The name fields of two structures' trust_store fields are equal.

   *  Either the version fields of the two structures' trust_store
      fields are equal, or the TrustStoreInclusion's status is
      latest_version_at_issuance and the version field of
      TrustExpression's trust_store is greater than that of the
      TrustStoreInclusion's trust_store.

   *  There is no value in common between the TrustStoreInclusion's
      labels field and the TrustExpression's excluded_labels field.

   The invariants in Section 5.1 imply that at most one
   TrustStoreInclusion will satisfy the first two properties.
   Implementations may evaluate this efficiently by performing a binary
   search over the TrustStoreInclusionList, and then checking the third

   A TrustExpressionList is said to match a TrustStoreInclusionList if
   any TrustExpression in the TrustExpressionList matches the

   When a TrustStoreInclusion's status is latest_version_at_issuance,
   the above criteria predicts that trust anchors in the latest version
   will continue to be present in later versions.  This allows relying
   parties using later trust store versions to continue to interoperate
   with certification paths that predate the later version.  If this
   prediction is incorrect and the trust anchor has been removed from
   the later version, Section 6.5 requires that the TrustExpression
   include appropriate excluded_labels values to mitigate this.

Benjamin, et al.          Expires 25 April 2024                [Page 15]
Internet-Draft            TLS Trust Expressions             October 2023

6.4.  Subscriber Behavior

   Subscribers using this negotiation scheme are configured with a list
   of certification paths, with corresponding CertificatePropertyList
   (Section 5) structures, in some preference order.  When responding to
   a ClientHello (as a server) or CertificateRequest (as a client)
   containing the trust_expressions extension, the subscriber collects
   all candidate certification paths such that all of the following are

   *  The certification path has not expired.

   *  The CertificatePropertyList has a trust_store property with a

   *  The matching algorithm described in Section 6.3 returns true.

   *  The certification path is suitable for use based on other TLS
      criteria.  For example, the TLS signature_algorithms
      (Section 4.2.3 of [RFC8446]) extension constrains the types of
      keys which may be used.

   *  The certification path satisfies any other application-specific
      constraints which may apply.  For example, TLS servers often
      select certificates based on the server_name (Section 3 of
      [RFC6066]) extension.

   Once all candidate paths are determined, the subscriber picks one to
   present to the relying party.  The subscriber MUST include an empty
   trust_expressions extension in the first CertificateEntry.  If
   multiple candidates match, the subscriber picks its most preferred
   option.  For example, it may try to minimize message size, or prefer
   options with more performant private keys.

   If no candidates match, or if the peer did not send a
   trust_expressions extension, the subscriber falls back to preexisting
   behavior outside the scope of this document, without including a
   trust_expressions extension.  For example, the subscriber may have a
   default certificate configured, or select a certificate using the
   certificate_authorities extension.

Benjamin, et al.          Expires 25 April 2024                [Page 16]
Internet-Draft            TLS Trust Expressions             October 2023

6.5.  Constructing Trust Expressions

   Relying parties send the trust_expressions extension to advertise a
   set of accepted trust anchors.  Each trust expression to be sent
   advertises a subset of some trust store version.  Relying parties MAY
   send multiple trust expressions, each referencing a different trust
   store, if it wishes to communicate a set of trust anchors that span
   multiple trust stores.

   For each referenced trust store version, the following procedure
   constructs a trust expression.  This procedure is expected to be run
   by the root program, as part of defining new trust store versions and
   provisioning supported trust anchors in relying parties.

   [[TODO: This is written as a procedure, but we expect root programs
   to fill in the expected exclusions when they define a new trust store
   version, and then trim the compatibility exclusions as they expire.
   Also the root programs know their label allocation scheme and are the
   ones deciding on removals, so they're best situated to pick a set of
   excluded_labels.  Perhaps this should get moved to the manifest?]]

   1.  Let include_entries and exclude_entries be two empty sets of
       trust anchor entries.

   2.  For each trust store entry in the trust store version:

       a.  If the trust store entry's id references a trust anchor that
           is in the desired subset, add it to include_entries.

       b.  Otherwise, add it to exclude_entries.

   3.  For all trust store entries in trust store versions before the
       specified version:

       a.  If the current time is before the entry's expiration time
           (Section 4.1) and if the entry's id references a trust anchor
           that is not in the desired subset, add the entry to

   4.  Compute a set of labels, excluded_labels such that:

       a.  No label appears in any entry in include_entries.

       b.  For each entry in exclude_entries, there is some label in
           common between excluded_labels and the labels in the entry.

Benjamin, et al.          Expires 25 April 2024                [Page 17]
Internet-Draft            TLS Trust Expressions             October 2023

       How to compute this set depends on the root program's label
       allocation scheme (Section 4.2).  If the root program allocates a
       label for each trust anchor, this set is always computable,
       though more efficient sets may be possible depending on the
       allocation scheme.

   5.  Output a TrustExpression such that trust_store is the referenced
       trust store version, and excluded_labels is the computed
       excluded_labels value.

   This procedure uses excluded_labels for two kinds of exclusions:

   First, if the trust store version includes undesired trust anchors,
   the trust expression should exclude them.  This may occur if, for
   example, the trust store is used by all versions of the relying
   party's software, but some trust anchors are gated by software

   Second, trust expressions exclude unexpired entries from previous
   versions.  This is because the matching criteria described in
   Section 6.3 predictively applies TrustStoreInclusion values with
   status of latest_version_at_issuance to all future versions of a
   trust store.  This allows relying parties to interoperate with
   subscribers with stale information.  Unexpired entries are those for
   which such an unexpired certification path may still exist.  Where
   this prediction is incorrect, trust expressions MUST mitigate this by
   excluding the past entries.

7.  Issuing Certificates

   Subscribers SHOULD use an automated issuance process where the CA
   transparently provisions multiple certification paths, without
   changes to subscriber configuration.  As relying party requirements
   evolve, the CA adjusts its output to ensure its subscribers continue
   to interoperate with all supported relying parties.  This results in
   a more flexible and agile PKI that can better respond to security
   incidents and changes in requirements.  (See Section 9 for details.)

   Subscribers MAY additionally combine the outputs from multiple CAs.
   This may be used, for example, to maintain backup certificates as
   described in Section 9.6.

7.1.  ACME Extension

   This section extends ACME [RFC8555] to be able to issue certificate
   paths, each with an associated CertificatePropertyList by defining a
   new media type in Section 5.3.  It extends the ACME order object with
   a configurable boolean field, "trustExpressions".

Benjamin, et al.          Expires 25 April 2024                [Page 18]
Internet-Draft            TLS Trust Expressions             October 2023

   First, ACME clients indicate they support certification paths
   selected by trust expressions by setting "trustExpressions" to "true"
   in the ACME newOrder request (Section 7.4 of [RFC8555]).  If the
   server accepts the request, it MUST reflect the field in the
   resulting order object.

   When an ACME server processes an order object with the
   "trustExpressions" field set to "true", it MAY issue multiple
   certification paths, each with an associated TrustStoreInclusionList,
   computed as in Section 5.2.  These paths MAY share an end-entity
   certificate but end at different trust anchors, or they MAY be
   completely distinct.  If the latter, the "trustExpressions" order
   field allows the ACME server to skip issuing unnecessary end-entity
   certificates for ACME clients that would be unable to use them.  The
   ACME server encodes each certification path using the application/
   pem-certificate-chain-with-properties format, defined in
   Section 5.3).  Note this format is required to form a complete
   certification path.  The CA MUST return a result that may be verified
   by relying parties without path building [RFC4158].

   The ACME server provides additional results to the client with the
   link relation header fields described in Section 7.4.2 of [RFC8555].
   When fetching certificates, the ACME client includes application/pem-
   certificate-chain-with-properties in its Accept header to indicate it
   supports the new format.  Unlike the original mechanism described in
   [RFC8555], these certification paths do not require heuristics to be
   used.  Instead, the ACME client uses the associated
   TrustStoreInclusionLists to select a path as described in
   Section 6.4.

   When the ACME client wishes to renew any of the certification paths
   issued in this order, it repeats this process to renew each path
   concurrently.  Thus this extension is suitable when the CA is willing
   to issue and renew all paths together.  It may not be appropriate if
   the paths have significantly different processing times or lifetimes.
   Future enhancements to ACME may be defined to address these cases,
   e.g. by allowing the ACME client to make independent orders.

8.  Example

   Suppose A1, A2, B1, B2, C1, and C2 are X.509 root certificates, such
   that A1 and A2 share an operator, B1 and B2 share an operator, and C1
   and C2 share an operator.

Benjamin, et al.          Expires 25 April 2024                [Page 19]
Internet-Draft            TLS Trust Expressions             October 2023

   On January 1st, 2023, the root program includes A1, A2, B1, and B2.
   It allocates labels 0 through 3 for each individual CA and then 100
   and 101 for the two CA operators.  The CAs issue 90 day certificates
   and are permitted to use manifests stale by 10 days.  The root store
   manifest may then be:

     "name": "example",
     "max_age": 864000,
     "trust_anchors": {
       "A1": {"type": "x509", "data": "..."},
       "A2": {"type": "x509", "data": "..."},
       "B1": {"type": "x509", "data": "..."},
       "B2": {"type": "x509", "data": "..."}
     "versions": [
         "timestamp": 1672531200,
         "entries": [
           {"id": "A1", "labels": [0, 100],
            "max_lifetime": 7776000},
           {"id": "A2", "labels": [1, 100],
            "max_lifetime": 7776000},
           {"id": "B1", "labels": [2, 101],
            "max_lifetime": 7776000},
           {"id": "B2", "labels": [3, 101],
            "max_lifetime": 7776000}

   A certification path, A1_old, issued by A1, would have a

   * is "example"

   *  trust_store.version is 0

   *  status is latest_version_at_issuance

   *  labels is 0, 100

   A certification path, B1_old, issued by B1, would have a

   * is "example"

Benjamin, et al.          Expires 25 April 2024                [Page 20]
Internet-Draft            TLS Trust Expressions             October 2023

   *  trust_store.version is 0

   *  status is latest_version_at_issuance

   *  labels is 2, 101

   A certification path, C1_old, issued by C1, would have no
   TrustStoreInclusions that reference "example".

   On February 1st, 2023, the root program added CAs C1 and C2 but
   removed CAs B1 and B2.  It continues the previous label allocation
   scheme, but now wishes to allocate label 200 for CAs A1 and C1.  The
   manifest may then be:

Benjamin, et al.          Expires 25 April 2024                [Page 21]
Internet-Draft            TLS Trust Expressions             October 2023

     "name": "example",
     "max_age": 864000,
     "trust_anchors": {
       "A1": {"type": "x509", "data": "..."},
       "A2": {"type": "x509", "data": "..."},
       "B1": {"type": "x509", "data": "..."},
       "B2": {"type": "x509", "data": "..."},
       "C1": {"type": "x509", "data": "..."},
       "C2": {"type": "x509", "data": "..."}
     "versions": [
         "timestamp": 1672531200,
         "entries": [
           {"id": "A1", "labels": [0, 100],
            "max_lifetime": 7776000},
           {"id": "A2", "labels": [1, 100],
            "max_lifetime": 7776000},
           {"id": "B1", "labels": [2, 101],
            "max_lifetime": 7776000},
           {"id": "B2", "labels": [3, 101],
            "max_lifetime": 7776000}
         "timestamp": 1675209600,
         "entries": [
           {"id": "A1", "labels": [0, 100, 200],
            "max_lifetime": 7776000},
           {"id": "A2", "labels": [1, 100],
            "max_lifetime": 7776000},
           {"id": "C1", "labels": [4, 102, 200],
            "max_lifetime": 7776000},
           {"id": "C2", "labels": [5, 102],
            "max_lifetime": 7776000}

   A certification path, A1_new, newly issued by A1, would have two
   TrustStoreInclusions.  The first:

   * is "example"

   *  trust_store.version is 0

Benjamin, et al.          Expires 25 April 2024                [Page 22]
Internet-Draft            TLS Trust Expressions             October 2023

   *  status is previous_version

   *  labels is 0, 100

   And the second:

   * is "example"

   *  trust_store.version is 1

   *  status is latest_version_at_issuance

   *  labels is 0, 100, 200

   A certification path, B1_new, newly issued by B1, would have a

   * is "example"

   *  trust_store.version is 0

   *  status is previous_version

   *  labels contains 2, 101

   A certification path, C1_new, newly issued by C1, would have a

   * is "example"

   *  trust_store.version is 1

   *  status is previous_version

   *  labels contains 2, 101, 200

   A relying party which trusts trust anchors A1, A2, B1, and B2 might
   send a TrustExpression referencing trust store "example", version 0,
   with empty excluded_labels.  This would match A1_old, A1_new, B1_old,
   and B1_new by the corresponding TrustStoreInclusion.  It would not
   match C1_old or C1_new.

   A relying party which trusts trust anchors A2, B1, and B2, but not
   A1, might send a TrustExpression referencing trust store "example",
   version 0, with excluded_labels of 0.  This would match B1_old and
   B1_new, but not A1_old or A1_new because the TrustExpression excludes

Benjamin, et al.          Expires 25 April 2024                [Page 23]
Internet-Draft            TLS Trust Expressions             October 2023

   A relying party which trusts trust anchors A1, A2, C1, and C2 might
   send a TrustExpression referencing trust store "example", version 1,
   with excluded_labels of 101.  Although B1 and B2 are not contained in
   version 1 of the trust store, the relying party must exclude them,
   per Section 6.5.  This TrustExpression matches the above
   certification paths as follows:

   *  A1_old matches.  Although it has no version 1 TrustStoreInclusion,
      the version 0 TrustStoreInclusion has a status of

   *  A1_new matches via its version 1 TrustStoreInclusion.

   *  B1_old does not match.  Although its version 0 TrustStoreInclusion
      has a status of latest_version_at_issuance and thus applies,
      excluded_labels exclude it.

   *  B1_new does not match.  Its version 0 TrustStoreInclusion has a
      status of previous_version and does not apply.  It has no version
      1 TrustStoreInclusion.

   *  C1_old does not match.  Although the relying party trusts C1,
      C1_old was issued before C1 was able to communicate this to the

   *  C1_new matches via its version 1 TrustStoreInclusion.

   The relying party could equivalently have sent a TrustExpression
   referencing trust store "example", version 1, with excluded_labels of
   2 and 3.  This pair of labels excludes the same CAs as 101.

   Of the above examples, B1_old depends on the exclusion to avoid a
   false positive match. 100 days after February 1st, B1 and B2's trust
   store entries from version 0 will expire (see Section 4.1), and the
   relying party no longer needs to exclude them.  By this point, B1_old
   will have expired.  B1_new may still be valid, but it does not
   require the exclusion.

9.  Use Cases

9.1.  Key Rotation

   In most X.509 deployments a compromise of _any_ root CA's private key
   would compromise the entire PKI.  Despite this, X.509 deployments
   often do not rotate root keys.  The oldest certificate in
   [CHROME-ROOTS] and [MOZILLA-ROOTS] was issued in 1998, 25 years old
   as of writing in 2023.  A single-certificate deployment model makes
   rotating root keys challenging due to the need for that certificate

Benjamin, et al.          Expires 25 April 2024                [Page 24]
Internet-Draft            TLS Trust Expressions             October 2023

   to be trusted by a wide range of relying parties.  Not all relying
   parties may be quickly updated with the new root CA, either due to
   being offline or simply lacking an update mechanism.  This means
   subscribers cannot switch to serving the new root, which in turn
   means relying parties cannot distrust the old root to complete the

   A multi-certificate deployment model avoids these transition
   problems.  Key rotation may proceed as follows:

   1.  The CA operator generates a new root CA with a separate key, but
       continues operating the old root CA.

   2.  Root programs begin trusting the new root CA alongside the old
       one.  They update their root store manifests.

   3.  When subscribers request certificates, the CA issues certificates
       from both roots and provisions the subscriber with both

   4.  Relying parties send trust expressions that evaluate to either
       the old or new root, and are served the appropriate option.

   5.  Once subscribers have been provisioned with new certificates,
       root programs can safely distrust the old root in new relying
       parties.  The CA operator continues to operate the old root CA
       for as long as it wishes to serve subscribers that, in turn, wish
       to serve older relying parties.

   Moreover, this process can complete with no configuration changes to
   the subscriber, given an automated, multi-certificate-aware
   certificate issuance process.  The subscriber does not need to know
   why it received two certificates, only how to select between them for
   each relying party.

9.2.  Adding CAs

   In the single-certificate X.509 model widely deployed today,
   subscribers cannot use TLS certificates issued from a new root CA
   until all supported relying parties have been updated to trust the
   new root CA.  In practice, it can take several years for a new root
   CA to become trusted in browsers.  Some relying parties, such as IoT
   devices, may never receive trust store updates at all.

   As a result, it is very difficult for subscribers that serve a wide
   variety of relying parties to use a newly-trusted root CA.  When
   trust stores diverge too far, subscribers often must partition their
   services into multiple TLS endpoints (i.e. different DNS names) and

Benjamin, et al.          Expires 25 April 2024                [Page 25]
Internet-Draft            TLS Trust Expressions             October 2023

   direct different relying parties to different endpoints.  Subscribers
   sometimes resort to TLS fingerprinting, to detect particular relying
   parties.  But, as this repurposes other TLS fields for unintended
   purposes, this is unreliable and usually requires writing custom
   service-specific logic.

   In a multi-certificate deployment model, subscribers can begin
   serving certificates from new root CAs without interrupting relying
   parties that depend on existing ones.

   In some contexts, it may be possible to use other fields to select
   the new CA.  For example, post-quantum-capable clients may be
   detected with the signature_algorithms and signature_algorithms_cert
   extensions.  However, this assumes all post-quantum CAs are added at
   the same time.  A multi-certificate model avoids this problem and
   allows for a more gradual deployment of post-quantum CAs.

9.3.  Removing CAs

   To serve certificates that will validate in all supported relying
   parties, subscribers in a single-certificate model only serve
   certificates from CAs in the intersection of multiple relying party
   trust stores.  As relying parties remove untrusted CAs over time,
   this intersection may shrink, reducing the set of CAs available to
   subscribers that can issue widely-trusted certificates.  Two relying
   parties may each support many CAs, but may have no common CA in

   This is exacerbated by relying parties that either have not or cannot
   take updates, and so cannot trust newer CAs.  Moreover, as relying
   parties do not currently report their trust stores, the subscriber
   may not even know which CAs are in the intersection.  Often, the only
   option is to try the new certificate and monitor errors.  For
   subscribers that serve many diverse relying parties, switching CAs is
   a disruptive and risky process.

   In a multi-certificate model, there is no need for subscribers to
   limit themselves to this intersection.  In a multi-certificate model,
   a subscriber can obtain certificates from multiple CAs, such that
   each supported relying party is covered by some certificate in the

Benjamin, et al.          Expires 25 April 2024                [Page 26]
Internet-Draft            TLS Trust Expressions             October 2023

   For example, suppose a subscriber uses certificates from some CA,
   CA1.  However, some relying party no longer trusts CA1.  The
   subscriber can obtain certificates from another CA that is trusted by
   that relying party, CA2, while continuing to also use CA1.  The
   relying party that no longer trusts CA1 will be served the CA2's
   certificate, while relying parties that still trust CA1 can be served
   the original one.

9.4.  Intermediate Elision

   In many PKIs today, root CAs issue certificates to intermediate CAs
   which, in turn, issue end-entity certificates.  This gives some
   operational and security improvements over issuing end-entity
   certificates directly from a root CA.  The root certificate's private
   key is less exposed to attack and it allows for different issuance
   and ownership models.  While the intermediate CA often inherits all
   the authority of the root CA, it can be replaced without changes to
   relying parties.  Thus it can be more easily revoked and/or have a
   shorter lifetime.

   However, this comes at a size cost: the certification path, sent in
   the TLS handshake, includes an extra certificate.  This is an extra
   public key and signature, as well as extra copies of X.509 metadata.
   (An average X.509 name in the Chrome Root Store [CHROME-ROOTS] or
   Mozilla CA Certificate Program [MOZILLA-ROOTS] is around 100 bytes,
   despite largely being an opaque identifier in modern usage.)  Post-
   quantum signature algorithms shift this tradeoff dramatically.
   Dilithium3 [Dilithium], for example, has a total public key and
   signature size of 5,245 bytes.

   [I-D.ietf-tls-cert-abridge] proposes to predistribute known
   intermediate certificates to relying parties, as a compression
   scheme.  A multi-certificate deployment model provides another way to
   achieve this effect.  To relying parties, a predistributed
   intermediate certificate is functionally equivalent to a root
   certificate.  PKIs use intermediate certificates because changing
   root certificates requires updating relying parties, but
   predistributed intermediates already presume updated relying parties.

   A CA operator could provide subscribers with two certification paths:
   a longer path ending at a long-lived trust anchor and shorter path
   the other ending at a short-lived, revocable root.  Relying parties
   would be configured to trust both the long-lived root and the most
   recent short-lived root.  The negotiation mechanism in Section 6
   would then send the shorter path to up-to-date relying parties, and
   the longer path to older relying parties.

Benjamin, et al.          Expires 25 April 2024                [Page 27]
Internet-Draft            TLS Trust Expressions             October 2023

   This achieves the same effect with a more general-purpose multi-
   certificate mechanism.  It is also more flexible, as the two paths
   need not be related.  For example, root CA public keys are not
   distributed in each TLS connection, so a post-quantum signature
   algorithm that optimizes for signature size may be preferable.  In
   this model, both the long-lived and short-lived root may use such an
   algorithm.  In a compression-based model, the same intermediate must
   optimize both its compressed and uncompressed size, so such an
   algorithm may not be suitable.

9.5.  Conflicting Relying Party Requirements

   A subscriber may need to support relying parties with different
   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.

   A single-certificate deployment model forces subscribers to find a
   single certificate that meets all requirements.  User security then
   suffers in all contexts, as the PKI may not quite meet anyone's
   needs.  In a multi-certificate deployment model, different contexts
   may use different trust anchors.  A subscriber that supports multiple
   contexts would provision certificates for each, with certificate
   negotiation logic directing the right one to each relying party.

9.6.  Backup Certificates

   A subscriber desiring to offer a robust service to relying parties in
   the face of a potential future CA compromise or distrust may obtain
   certification paths from multiple CAs.  This provides redundancy in
   the event that some relying party no longer supports one of the two
   CAs.  As long as the subscriber continues to have at least one
   trusted certification path, it will continue to be trusted by the
   relying parties.

   In order to support this, TLS serving software SHOULD permit users to
   configure multiple ACME endpoints and select from the the union of
   the certificate paths returned by each ACME server.

10.  Privacy Considerations

   The negotiation mechanism described in this document presumes the
   relying party's trust anchor list is not sensitive.  While an
   attacker may already query this list by probing which certification
   paths are accepted by the relying party, this extension introduces a
   faster and more reliable method.

Benjamin, et al.          Expires 25 April 2024                [Page 28]
Internet-Draft            TLS Trust Expressions             October 2023

   Thus, this mechanism SHOULD NOT be used in contexts where the list
   reveals information about an individual user.  For example, a web
   browser may support both a common set of trust anchors configured by
   the browser vendor, and a set of user-specified trust anchors.  The
   common trust anchors would only reveal which browser is used, while
   the user-specified trust anchors may reveal identifying information
   about the user.  In this case, the trust anchor list SHOULD be
   limited to the common trust anchors.  This limits the benefits of
   trust anchor agility to subscribers that use one of the advertised
   trust anchors.  However, deployments that rely on an unadvertised
   trust anchor will fall back to the default behavior, as if this
   extension were not used.

   Likewise, a client that allows user-specified distrusts of common
   trust anchors will reveal user-specific information if distrusts are
   reflected in transmitted trust expressions.  Trust expressions SHOULD
   be constructed as if those trust anchors were trusted.  This may
   result in servers selecting a distrusted certificate, despite a
   trusted one being available.

   Additionally, two relying parties may express the same trust anchor
   list with different trust expressions.  Doing so may also reveal
   information about an individual user.  Relying parties within an
   anonymity set (Section 3.3 of [RFC6973]) SHOULD send the same trust
   expression.  To achieve this, the trust expressions SHOULD be
   assembled by the root program and configured in relying parties
   alongside trust store updates.

11.  Security Considerations

   The certificate negotiation mechanism described in this document
   facilitates which certification path is served to relying parties,
   but has no impact on the relying party's trust preferences

   As a result, this allows for a more flexible and agile PKI, which can
   better mitigate security risks to users.  Section 9 discusses some
   scenarios which benefit from the multi-certificate deployment this
   document enables.  In general, robust certificate negotiation helps
   subscribers navigate differences in relying party requirements.  This
   means security improvements for one set of relying parties can be
   deployed without needing to risk incompatibility or breakage for

   If either the subscriber's TrustStoreInclusionList or the relying
   party's TrustExpressionList are incorrect, the matching algorithm
   described in Section 6.4 may incorrectly identify an untrusted
   certification path.  This mechanism will not result in that path

Benjamin, et al.          Expires 25 April 2024                [Page 29]
Internet-Draft            TLS Trust Expressions             October 2023

   being trusted, but does present the possibility of a denial of
   service.  These structures are provisioned by the CA and root
   program, respectively, who are already expected to provide accurate

12.  IANA Considerations

12.1.  TLS ExtensionType Updates

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

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

                                 Table 1

12.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

   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 5.3]

   Applications that use this media type:  ACME clients and servers,

Benjamin, et al.          Expires 25 April 2024                [Page 30]
Internet-Draft            TLS Trust Expressions             October 2023

      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:  IESG

12.3.  ACME Order Object Fields Updates

   IANA is requested to create the following entry in the ACME Order
   Object Fields registry, defined by [RFC8555]:

       | Field Name       | Field Type | Configurable | Reference  |
       | trustExpressions | boolean    | true         | [this-RFC] |

                                  Table 2

12.4.  CertificatePropertyType Registry

   [[TODO: Establish a CertificatePropertyType registry.]]

13.  References

13.1.  Normative References

   [POSIX]    "IEEE Standard for Information Technology--Portable
              Operating System Interface (POSIX(TM)) Base
              Specifications, Issue 7", IEEE,
              DOI 10.1109/ieeestd.2018.8277153, ISBN ["9781504445429"],
              January 2018,

Benjamin, et al.          Expires 25 April 2024                [Page 31]
Internet-Draft            TLS Trust Expressions             October 2023

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <>.

   [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,

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,

   [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,

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,

   [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,

   [RFC7468]  Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
              PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
              April 2015, <>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

Benjamin, et al.          Expires 25 April 2024                [Page 32]
Internet-Draft            TLS Trust Expressions             October 2023

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,

   [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:2002, 2002.

13.2.  Informative References

   [CCADB]    Mozilla, Microsoft, Google, Apple, and Cisco, "Common CA
              Database", 9 October 2023, <>.

              Chromium, "Chrome Root Store", 30 August 2023, <https://ch

              Bai, S., Ducas, L., Kiltz, E., Lepoint, T., Lyubashevsky,
              V., Schwabe, P., Seiler, G., and D. Stehlé, "CRYSTALS-
              Dilithium Algorithm Specifications and Supporting
              Documentation", 8 February 2021, <https://pq-

              Jackson, D., "Abridged Compression for WebPKI
              Certificates", Work in Progress, Internet-Draft, draft-
              ietf-tls-cert-abridge-00, 6 September 2023,

              Mozilla, "Mozilla Included CA Certificate List", 30 August
              2023, <>.

Benjamin, et al.          Expires 25 April 2024                [Page 33]
Internet-Draft            TLS Trust Expressions             October 2023

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <>.

Appendix A.  CDDL Schema

   The following is a non-normative CDDL [RFC8610] schema which
   describes a trust store manifest structure (Section 4):

   trust-anchor = {
       type: text,
       * text => any,

   trust-store-entry = {
       id: text,
       labels: [+ uint],
       max_lifetime: uint,
       * text => any,

   trust-store-version = {
       timestamp: int,
       entries: [+ trust-store-entry],
       * text => any,

   trust-store-manifest = {
       name: text,
       max_age: uint,
       trust_anchors: {+ text => trust-anchor},
       versions: [+ trust-store-version],
       * text => any,


   The authors thank Nick Harper, Sophie Schmieg, and Emily Stark for
   many valuable discussions and insights which led to this document, as
   well as review of early iterations.

Benjamin, et al.          Expires 25 April 2024                [Page 34]
Internet-Draft            TLS Trust Expressions             October 2023

Authors' Addresses

   David Benjamin
   Google LLC

   Devon O'Brien
   Google LLC

   Bob Beck
   Google LLC

Benjamin, et al.          Expires 25 April 2024                [Page 35]