TLS Trust Anchor Identifiers

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

5.1. Extension Syntax

The trust_anchors extension is defined using the structures below:¶

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

/* Syntax when sent in ClientHello or CertificateRequest: */
TrustAnchorID RequestedTrustAnchorList<0..2^16-1>;

/* Syntax when sent in Certificate: */
struct {} Empty;

/* Syntax when sent in EncryptedExtensions: */
TrustAnchorID AvailableTrustAnchorList<1..2^16-1>;

A TrustAnchorID structure contains the binary representation of some trust anchor ID, as described in Section 4.¶

When the trust_anchors extension is sent in ClientHello or CertificateRequest, the extension_data is a RequestedTrustAnchorList. It indicates that the sender supports the specified trust anchors or trust anchor groups. The list is unordered, and MAY be empty. Section 5.2 describes how the relying party determines this value. Section 5.3 describes how the authenticating party evaluates this value.¶

When the trust_anchors extension is sent in Certificate, the extension_data MUST be empty. The extension MUST only be sent in the first CertificateEntry. It indicates that the sender sent the certificate because the certificate matched a trust anchor ID sent by the peer. Section 5.5 describes this in detail.¶

When the trust_anchors extension is sent in EncryptedExtensions, the extension_data is an AvailableTrustAnchorList. It indicates individual trust anchors for which the server has a candidate path, in order of most to least preferred by the server. This list MUST NOT be empty. If the server has no available trust anchors to present, it MUST omit the extension. Section 5.6 describes this in detail.¶

5.2. Relying Party Configuration

Relying parties are configured with:¶

1. An associated trust anchor ID for each supported trust anchor that participates in this protocol¶

2. A list of requested trust anchor IDs which, together, describe supported trust anchors¶

A trust anchor's associated ID MUST be the trust anchor ID which represents it. In this document, the ID is expected to be configured separately from the trust anchor for compatibility with existing PKIs. Future certificate profiles MAY define representations where the trust anchor ID is encoded directly in the trust anchor.¶

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

In a TLS connection, the relying party sends its requested trust anchor IDs in the ClientHello message (if a client) or CertificateRequest message (if a server). This communicates a set of supported trust anchors to the authenticating party.¶

The requested trust anchor IDs MAY be determined by collecting the associated IDs of each supported trust anchor. Alternatively, a relying party MAY configure a requested list of IDs for individual trust anchors and IDs for trust anchor groups. Using groups can further reduce the size of messages sent by the relying party, but requires that authenticating parties be configured to recognize them. See also Section 5.3.¶

If the relying party is a client, it is not necessary for the requested trust anchor IDs to be fully accurate. A client MAY omit trust anchors that it trusts or signal trust anchors which it does not trust. This can be useful in several scenarios:¶

• The client MAY try to reduce size with a common trust anchor group, but the group contains some untrusted trust anchors. Sending the group would signal the full contents of the group.¶

• The client MAY send a (possibly empty) subset of its trust anchors due to fingerprinting risks (see Section 9) or size concerns.¶

• The client MAY send trust anchors it does not trust. This can reduce fingerprinting if, e.g., default instances of the client send this value, but an individual user has configured their software to distrust the CA.¶

If the client list is inaccurate, it is possible the server will select an untrusted certificate. The connection will then fail. Clients that send potentially inaccurate lists SHOULD implement the recovery mechanism described in Section 5.6. The associated IDs of individual trust anchors are used in recovery. Recovery requires a round-trip, so clients SHOULD send as accurate a list as feasible.¶

5.3. Authenticating Party Configuration

The authenticating party compares the requested trust anchor IDs with its candidate certification paths. To do this, each candidate certification path that participates in this protocol MUST be configured with:¶

• The trust anchor ID for the CA that issued this candidate path.¶

• The trust anchor groups known to contain the issuing CA. The CA can be contained in a family of related trust anchor groups, such as in Section 6.1. To accomodate this, the IDs of the containing groups are described with a list of trust anchor ID patterns, defined below in Section 5.3.1. Note these patterns specify the IDs of the groups, not their contents.¶

Section 7 defines a format to represent these properties. Section 7.5 defines how to obtain them from ACME [RFC8555].¶

The authenticating party intersects this information with the requested trust anchor IDs to determine if the relying party trusts the issuing CA. A candidate path is said to match the requested trust anchor IDs if either:¶

• One of the requested trust anchor IDs is equal to the path's trust anchor ID.¶

• One of the requested trust anchor IDs is contained in one of the path's trust anchor group patterns.¶

Authenticating parties MAY have candidate certification paths that do not participate in this protocol and lack these properties. These paths MAY participate in other trust anchor negotiation protocols, such as the certificate_authorities extension, or they MAY be used as a fallback when no matching issuer is found.¶

  // component[0].min = 32473
  0x81, 0xfd, 0x59,
  // component[0].max = 32473
  0x81, 0xfd, 0x59,
  // component[1].min = 123
  0x7b,
  // component[1].max = 456
  0x83, 0x48,
  // component[2].min = 789
  0x86, 0x15,
  // component[2].max = infinity
  0x80,

5.4. Certificate Selection

This document extends TLS certificate selection (Section 4.5.1.2 of [RFC9846]) as follows:¶

• If the ClientHello or CertificateRequest contains a trust_anchors extension, the authenticating party SHOULD send a certification path that matches the requested trust anchor IDs, as described in Section 5.3. See Section 5.5 for additional requirements in this case.¶

• 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.¶

• If no certification paths satisfy either extension, the authenticating party MAY return a handshake_failure alert, or send some fallback certificate, without considering trust_anchors or certificate_authorities.¶

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. Section 7.3 describes a RECOMMENDED mechanism for determining fallbacks.¶

When the authenticating party is a server, Section 5.6 describes an additional requirement for servers that implement this protocol.¶

5.5. Strict Certification Paths

If, and only if, the authenticating party sends a certification path that matches the relying party's trust_anchors extension, 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.5.1 of [RFC9846] 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 path's trust anchor MUST certify the final certificate.¶

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 a 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.¶

5.6. Recovery

If the relying party is a client, it MAY, as described in Section 5.2, request extra trust anchors or omit trusted ones. To accommodate this, this section defines a protocol for recovering from signaling failure in server certificate selection.¶

When receiving a ClientHello with trust_anchors, the server collects all candidate certification paths which:¶

• Have a trust anchor ID, and¶

• Satisfy the conditions in Section 4.5.1.2 of [RFC9846], with the exception of certificate_authorities, and any future extensions that play a similar role¶

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

If a client requests extra trust anchors or omits trusted ones, it SHOULD implement the following recovery mechanism:¶

If the client receives either a connection error or an untrusted certificate, the client looks in the 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, requesting only the selected trust anchor ID in the ClientHello trust_anchors extension. If the EncryptedExtensions had no trust_anchors extension, or no match was found, the client returns the error to the application.¶

Clients SHOULD retry at most once per connection attempt.¶

This mechanism allows the connection to recover from a certificate selection failure, at additional latency 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.¶

6.1. Versioned Groups

Over time, a group may become out-of-date, making it describe current relying parties less effectively. For example, a CA operator may deploy or turn down a CA instance, or a relying party may trust a new CA or distrust an existing CA. Existing trust anchor groups SHOULD NOT be redefined, but the following versioning scheme MAY be used to define updated groups:¶

A versioned sequence of trust anchor groups is identified by a OID arc. Each group has an ID of this OID arc, with a non-negative integer version number component appended. For example, versioned groups using the OID arc 32473.2 would have IDs 32473.2.0, 32473.2.1, 32473.2.2, and so on. When defining a new group version, the version component is incremented.¶

Each candidate path is then configured with the versioned groups that contain it. These groups are described by a trust anchor ID pattern (Section 5.3.1) as follows:¶

1. Let base be the OID arc that identifies the sequence. Let min be the first version that includes the trust anchor.¶

2. At issuance, if the trust anchor is no longer in the latest group version, let max be the last version that includes the trust anchor. The pattern is base.{min-max}.¶

3. At issuance, if the trust anchor is in the latest group version, the pattern is base.{min-}. That is, the last component has a max of 2⁶⁴-1.¶

In the second case, the range contains not-yet-defined group versions, so there is a potential signaling error. Suppose, after issuance, a new group version is defined without the trust anchor. The unlimited upper bound is now incorrect. A relying party might not trust this trust anchor, while sending this new group version. However, the authenticating party will misinterpret the certificate as compatible based on its stale information. Such signaling errors may result in the wrong certificate being selected.¶

This can be mitigated in one several ways:¶

• Only pre-existing certificates are impacted. Newly-issued certificates postdate this version and will have the correct upper bound. When the certificate is renewed, group inclusions will be corrected.¶

• [SCTNotAfter] describes a trust anchor removal strategy that only impacts newly-issued certificates. In this case, no renewal is needed. Pre-existing group inclusions remain accurate under this strategy.¶

• If the authenticating party's preferences place the correct candidate path (issued by a newer trust anchor) ahead of misinterpreted one (issued by the removed trust anchor), the correct candidate will still be chosen.¶

• When the relying party is a client, any remaining signaling errors can be corrected with the recovery mechanism described in Section 5.6.¶

7.1. Trust Anchor ID Property

The trust_anchor_id property's data field contains the binary representation of the trust anchor ID of the certification path's trust anchor, as described in Section 5.3. The binary representation is encoded directly into the data field with no additional length prefix.¶

7.2. Trust Anchor Groups Property

The trust_anchor_groups property's data field contains a TrustAnchorIDPatternList structure, defined below. Its value is the certification path's trust anchor group patterns, as described in Section 5.3 and Section 5.3.1.¶

opaque TrustAnchorIDPattern<0..2^8-1>;

TrustAnchorIDPattern TrustAnchorIDPatternList<1..2^16-1>;

7.3. Trust Anchor Negotiation Property

The trust_anchor_negotiation property's data field MUST be empty.¶

When a candidate certification path has this property, the authenticating party SHOULD NOT select it as a fallback when the path's issuer cannot be matched against the relying party. When a candidate path lacks this property, the authenticating party MAY use it as a fallback. See also Section 5.4.¶

A path without the trust_anchor_negotiation property MAY still participate in this protocol and include the trust_anchor_id and trust_anchor_groups properties. In particular, the authenticating party MAY still choose to condition the path on trust anchor negotiation if it is combining multiple sets of candidate paths, each with their separate determinations about suitable fallbacks. Section 7.5.1 gives an example scenario. This could be implemented either with separate local configuration or by modifying the CertificatePropertyList structures when combining the sets.¶

Section 7.5 discusses how an ACME server might set this property, as well as examples where the authenticating party might override this recommendation.¶

7.4. PEM Representation

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" is as defined in Section 3 of [RFC7468]:¶

certchainwithproperties = 2*stricttextualmsg

The first element MUST be the encoded CertificatePropertyList. The second element MUST be an end-entity certificate. Each following element MUST contain a certificate that directly certifies 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 7.¶

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. The example CertificatePropertyList encodes:¶

• A trust_anchor_id property of 32473.1¶

• A trust_anchor_groups property with two patterns:¶

  • 2187.2.{100-200}¶

  • 32473.3.{42-}.{100-200}¶

• A trust_anchor_negotiation property¶

-----BEGIN CERTIFICATE PROPERTIES-----
ACoAAAAEgf1ZAQABABoAGAmRC5ELAgJkgUgNgf1Zgf1ZAwMqgGSBSAACAAA=
-----END CERTIFICATE PROPERTIES-----
-----BEGIN CERTIFICATE-----
MIIBVzCB/6ADAgECAgkAh7Uv5X8pplkwCgYIKoZIzj0EAwIwGjEYMBYGA1UEAwwP
SW50ZXJtZWRpYXRlIENBMB4XDTI2MDUwNTIxMzg1NVoXDTI3MDUwNTIxMzg1NVow
FjEUMBIGA1UEAwwLZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
AAT5mg5z0464cE7rtEpTeSPFNlRUBjxqycdb4rvNkG3Fbd1R2IRo7zYOi5SP3S7L
C4r5Hw+IiDq5X2nQT1w5ympeozIwMDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIHgDAW
BgNVHREEDzANggtleGFtcGxlLmNvbTAKBggqhkjOPQQDAgNHADBEAiBRdPrVpQtJ
s+J9DFhT1Db6QmIZFfjFFKQ88B0gFezyfAIgSwIxntwrPFYagfK6vPcRpDxG2oLV
LkfnP5v1SPjOsMY=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIBRTCB7KADAgECAgkAkaBeQj6ZErAwCgYIKoZIzj0EAwIwEjEQMA4GA1UEAwwH
Um9vdCBDQTAeFw0yNjA1MDUyMTM4MzJaFw0zMTA1MDQyMTM4MzJaMBoxGDAWBgNV
BAMMD0ludGVybWVkaWF0ZSBDQTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJEH
0D77iyFv01I/4sEqUaoUel50BBwsWSYrH/LtO6cdGI28NyzMyFuYrE6UCRusgAKo
XBmWjHEGJmoDPoAy2t+jIzAhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQD
AgEGMAoGCCqGSM49BAMCA0gAMEUCIBWtPiDwXXEvbgy2+nu/w4MRBNsQ3hbVWyJT
ITN+1R6WAiEA2AfGBy3Hz8oYY5wPldIndrXjntCzzSEduB6pEvYQZWo=
-----END CERTIFICATE-----

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

7.5. ACME Extension

The format defined in Section 7.4 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 trust_anchor_id and trust_anchor_groups properties for use with this protocol, or other properties defined in another document.¶

When the ACME server provides multiple paths, e.g. with ACME's alternate certificate chain mechanism (see Section 7.4.2 of [RFC8555]), the ACME server SHOULD include the trust_anchor_negotiation property on any paths it expects to gate on trust anchor negotiation. It SHOULD omit the property on any paths which are possible fallbacks when no trust anchors match.¶

The authenticating party MAY override this recommendation. In particular, if the authenticating party combines certification paths from two ACME orders, it might only consider some orders as a source for fallback paths.¶

When a path is gated on trust anchor negotiation, this protocol removes the need for heuristics in determining which path to serve to which relying party.¶

7.6. Representing Multiple Paths

While ACME represents each certification path separately, applications might combine multiple certification paths in one file as part of local configuration. For example:¶

• An ACME client might serialize all paths returned from a single order in a file. The TLS server might then be configured to load certificates from the files from each order.¶

• A deployment might combine the paths from all ACME orders in a single file. The TLS server might then be configured to load its full certificate configuration from the file.¶

This section extends the PEM representation defined in Section 7.4 for such cases.¶

A list of certification paths is represented in PEM by concatenating their corresponding PEM representations. Each path MUST begin with a CertificatePropertyList, which signals a new path to the decoder. If the path has no properties configured, the corresponding PEM-encoded CertificatePropertyList is as follows:¶

-----BEGIN CERTIFICATE PROPERTIES-----
AAA=
-----END CERTIFICATE PROPERTIES-----

Paths are ordered by the encoder's preference, with the most preferred encoded first. Depending on the application, the decoder might use this preference order, or it might override it with another ordering.¶

This format does not directly represent private keys. However, applications MAY combine this format with private keys in one of several ways:¶

• If the application represents paths with the same private key, it can associate all decoded paths with the corresponding private key.¶

• If the application represents paths with different private keys, it can first load all available private keys, then match each decoded path with the private key that matches the end-entity certificate's subjectPublicKeyInfo.¶

The following example file contains two certification paths:¶

-----BEGIN CERTIFICATE PROPERTIES-----
ACoAAAAEgf1ZAQABABoAGAmRC5ELAgJkgUgNgf1Zgf1ZAwMqgGSBSAACAAA=
-----END CERTIFICATE PROPERTIES-----
-----BEGIN CERTIFICATE-----
MIIBVzCB/6ADAgECAgkAh7Uv5X8pplkwCgYIKoZIzj0EAwIwGjEYMBYGA1UEAwwP
SW50ZXJtZWRpYXRlIENBMB4XDTI2MDUwNTIxMzg1NVoXDTI3MDUwNTIxMzg1NVow
FjEUMBIGA1UEAwwLZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
AAT5mg5z0464cE7rtEpTeSPFNlRUBjxqycdb4rvNkG3Fbd1R2IRo7zYOi5SP3S7L
C4r5Hw+IiDq5X2nQT1w5ympeozIwMDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIHgDAW
BgNVHREEDzANggtleGFtcGxlLmNvbTAKBggqhkjOPQQDAgNHADBEAiBRdPrVpQtJ
s+J9DFhT1Db6QmIZFfjFFKQ88B0gFezyfAIgSwIxntwrPFYagfK6vPcRpDxG2oLV
LkfnP5v1SPjOsMY=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIBRTCB7KADAgECAgkAkaBeQj6ZErAwCgYIKoZIzj0EAwIwEjEQMA4GA1UEAwwH
Um9vdCBDQTAeFw0yNjA1MDUyMTM4MzJaFw0zMTA1MDQyMTM4MzJaMBoxGDAWBgNV
BAMMD0ludGVybWVkaWF0ZSBDQTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJEH
0D77iyFv01I/4sEqUaoUel50BBwsWSYrH/LtO6cdGI28NyzMyFuYrE6UCRusgAKo
XBmWjHEGJmoDPoAy2t+jIzAhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQD
AgEGMAoGCCqGSM49BAMCA0gAMEUCIBWtPiDwXXEvbgy2+nu/w4MRBNsQ3hbVWyJT
ITN+1R6WAiEA2AfGBy3Hz8oYY5wPldIndrXjntCzzSEduB6pEvYQZWo=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE PROPERTIES-----
AAA=
-----END CERTIFICATE PROPERTIES-----
-----BEGIN CERTIFICATE-----
MIIBojCCAUigAwIBAgIBAjAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBFJbnRlcm1l
ZGlhdGUgQ0EgMjAeFw0yNjA5MTEyMjA3MzJaFw0yNzA5MTEyMjA3MzJaMBYxFDAS
BgNVBAMMC2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAErvaU
F7iXvurpBgeG5eCx8cMmcOKb11Nvlk/dCdcAelIcvAAHABGc8cVSkjGlNGQhgeCm
MBKQipIiDskIhIZoRaOBgDB+MB0GA1UdDgQWBBTw8ysZe1gMI/OX0Jx9Y/0yq4Q6
zjAfBgNVHSMEGDAWgBT9JPmvVv2aTEDF/R+XTZzy9iMRWjAPBgNVHRMBAf8EBTAD
AQH/MBYGA1UdEQQPMA2CC2V4YW1wbGUuY29tMBMGA1UdJQQMMAoGCCsGAQUFBwMB
MAoGCCqGSM49BAMCA0gAMEUCIQCAbiJcNrPnAr0N9oBJ70ikytGQxTQLEfdMF3Id
dRHp/QIgNFQIR4pV/CxvnbJnqUYySx7NgynEBj4v9fndOj8+Mvw=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIBhDCCASugAwIBAgIBATAKBggqhkjOPQQDAjAUMRIwEAYDVQQDDAlSb290IENB
IDIwHhcNMjYwOTExMjIwNzMyWhcNMzEwOTEwMjIwNzMyWjAcMRowGAYDVQQDDBFJ
bnRlcm1lZGlhdGUgQ0EgMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABAqUU6fc
WctyRGFMz3CGQwUCb5pPhi7imSamipwIrQopqOOUqTr27RLa0CSQwL/87OH/Yxc8
1jp3cC3qdEp4sAmjZjBkMB0GA1UdDgQWBBT9JPmvVv2aTEDF/R+XTZzy9iMRWjAf
BgNVHSMEGDAWgBSQ1f8odAe5s7NU91kxX2mPDd8xezASBgNVHRMBAf8ECDAGAQH/
AgEAMA4GA1UdDwEB/wQEAwIBBjAKBggqhkjOPQQDAgNHADBEAiA1VrVfvq1QtS5v
gZYh1yEIL8wV863GEE2C6/zSB7TzaAIgTUBrpMo56XIb+Wez1CPWtqYFd2a6NvJx
IKzgi/++xTs=
-----END CERTIFICATE-----

8.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.¶

8.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.¶

8.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 8.1 and Section 8.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.¶

8.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 8.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.¶

8.5. Intermediate Elision

In many 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.¶

Trust anchor negotiation can avoid this size cost. Relying parties predistribute intermediate CAs and configure them as short-lived trust anchors. Authenticating parties can then send shorter paths to those relying parties.¶

More generally, 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.¶

8.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.¶

8.7. Backup Certificates

An authenticating party may obtain certification 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 certification path, avoiding the immediate breakage that would otherwise be caused by this removal.¶

8.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.¶

9.1. Relying Parties

The trust_anchors extension is analogous to the certificate_authorities extension (Section 4.3.4 of [RFC9846]), 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, 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.¶

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

9.2. Authenticating Parties

If the authenticating party is a server, the trust_anchors extension in EncryptedExtensions enumerates the trust anchors for the server's available certification paths. (See Section 5.6.) This assumes these trust anchors 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, this list is expected to be filtered by server_name. This ensures that 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.¶

10.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.¶

10.2. Trust Anchor Negotiation

Both the trust_anchors and certificate_authorities (Section 4.3.4 of [RFC9846]) 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.¶

11.1. TLS ExtensionType Updates

IANA is requested to create the following entry in the TLS ExtensionType Values registry, originally created in [RFC4366]:¶

11.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 7.4]¶

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¶

11.3. CertificatePropertyType Registry

IANA is requested to create the "CertificatePropertyType" registry within the "Transport Layer Security (TLS) Extensions" group. The initial entries in the registry are as follows:¶

New values are allocated according to the following process:¶

• Values in the range 0-65279 are assigned via Specification Required [RFC8126].¶

• Values in the range 65280-65535 are reserved for Private Use [RFC8126].¶

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

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

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

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

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

[RFC9846]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, <https://www.rfc-editor.org/rfc/rfc9846>.

[X680]

ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ISO/IEC 8824-1:2021, 2021, <https://www.itu.int/rec/T-REC-X.680>.

[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, <https://www.itu.int/rec/T-REC-X.690>.

12.2. Informative References

[CHROME-ROOTS]

Chromium, "Chrome Root Store", 30 August 2023, <https://chromium.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-plants-merkle-tree-certs]

Benjamin, D., O'Brien, D., Westerbaan, B., Valenta, L., and F. Valsorda, "Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-ietf-plants-merkle-tree-certs-05, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-plants-merkle-tree-certs-05>.

[MOZILLA-ROOTS]

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

[RFC4366]

Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, <https://www.rfc-editor.org/rfc/rfc4366>.

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

[SCTNotAfter]

Adrian, D., "How to distrust a CA without any certificate errors", March 2025, <https://dadrian.io/blog/posts/sct-not-after/>.