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 public key or certificate that relying parties use to determine whether a certification path is trusted.¶

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

CertificatePropertyList:

A structure associated with a certification path, containing additional information from the CA, for use by the authenticating party when presenting the certification path.¶

3.1. Certificate Properties

This document introduces an extensible CertificatePropertyList structure for CAs to communicate additional information to authenticating parties, such as associated trust anchor identifiers. A CertificatePropertyList is defined using the TLS presentation language (Section 3 of [RFC8446]) below:¶

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

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

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

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

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

Authenticating parties MUST ignore properties with unrecognized CertificatePropertyType values.¶

3.2. Relying Party Configuration

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

When trust anchors are self-signed X.509 certificates, the X.509 trust anchor identifier extension MAY be used to carry this identifier. The trust anchor identifier extension has an extnID of id-trustAnchorIdentifier and an extnValue containing a DER-encoded TrustAnchorIdentifier structure, defined below. The TrustAnchorIdentifier is the trust anchor identifier's ASN.1 representation, described in Section 3. This extension MUST be non-critical.¶

id-trustAnchorIdentifier OBJECT IDENTIFIER ::= { TBD }

TrustAnchorIdentifier ::= RELATIVE-OID

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

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

3.3. Authenticating Party Configuration

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

Each candidate path which participates in this protocol must be provisioned with the trust anchor identifier for its corresponding trust anchor in the CertificatePropertlyList.¶

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

4.1. Overview

The trust_anchors extension is defined using the structures below:¶

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

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

TrustAnchorIdentifier TrustAnchorIdentifierList<0..2^16-1>;

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

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

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

4.2. Certificate Selection

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

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

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

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

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

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

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

4.3. Retry Mechanism

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

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

• Have a trust anchor identifier, and¶

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

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

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

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

Clients SHOULD retry at most once per connection attempt.¶

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

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

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

5.1. Syntax

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

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

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

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

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

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

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

5.2. Configuring Services

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

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

5.3. Client Behavior

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

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

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

8.1. Key Rotation

In most X.509 deployments, a compromise of any root CA's private key compromises the entire PKI. Yet key rotation in PKIs is rare. In 2023, the oldest root in [CHROME-ROOTS] and [MOZILLA-ROOTS] was 25 years old, dating to 1998. Key rotation is challenging in a single-certificate deployment model. As long as any older relying party requires the old root, authenticating parties cannot switch to the new root, which in turn means relying parties cannot distrust the old root, leaving them vulnerable.¶

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, as a transition state. Both root CAs are configured to participate in trust anchor negotiation.¶

3. When authenticating parties request certificates, the CA operator issues certificates from both roots and provisions the authenticating party with both certificates.¶

4. Trust anchor negotiation selects the old root for relying parties that only trust the old root, and the new root for relying parties that only trust the new root. In transition, relying parties that trust both may be served either, but prioritizing the new root helps monitor the transition.¶

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

This process requires no configuration changes to the authenticating party, given an automated, multi-certificate-aware certificate issuance process. The authenticating party does not need to know why it received two certificates, only how to select between them for each relying party.¶

8.2. Adding CAs

In the single-certificate model, authenticating parties cannot use TLS certificates issued from a new root CA until all supported relying parties have been updated to trust the new root CA. This can take years or more. Some relying parties, such as IoT devices, may never receive trust store updates at all.¶

As a result, it is very difficult for authenticating parties that serve a wide variety of relying parties to use a newly-trusted root CA. When trust stores diverge too far, authenticating parties often must partition their services into multiple TLS endpoints (i.e. different DNS names) and direct different relying parties to different endpoints. Authenticating parties 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, authenticating parties 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.¶

8.3. Removing CAs

Authenticating parties in a single-certificate model are limited to CAs in the intersection of their supported relying parties. As newer relying parties remove untrusted CAs over time,the intersection with older relying parties shrinks. Moreover, the authenticating party may not even know which CAs are in the intersection. 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.¶

The multi-certificate model removes this constraint. If an authenticating party's CA is distrusted, it can continue to use that CA, in addition to a newer one. This removes the risk that some older relying party required that CA and was incompatible with the new one. The mechanisms in this document will select an appropriate certificate for each relying party.¶

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 use the mechanism in Section 6 to 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.1, 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.¶

[[TODO: There's one missing piece, which is that some servers may attempt to parse the signature algorithms out of the certificate chain. See https://github.com/davidben/tls-trust-expressions/issues/9 ]]¶

8.5. Intermediate Elision

Today, root CAs typically issue shorter-lived intermediate certificates which, in turn, issue end-entity certificates. The long-lived root key is less exposed to attack, while the short-lived intermediate key can be more easily replaced without changes to relying parties.¶

This operational improvement comes at a bandwidth cost: the TLS handshake includes an extra certificate, which includes a public key, signature, and 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 alone. Post-quantum signature algorithms will dramatically shift this tradeoff. 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 authenticating parties 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. A server that prioritizes the shorter path would then send the shorter path to up-to-date relying parties and the longer path to older relying parties.¶

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

8.6. Conflicting Relying Party Requirements

An authenticating party 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 authenticating parties 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. An authenticating party that supports multiple contexts would provision certificates for each, with certificate negotiation logic directing the right one to each relying party.¶

8.7. Backup Certificates

An authenticating party may obtain certificate paths from multiple CAs for redundancy in the face of future CA compromises. If one CA is compromised and removed from newer relying parties, the TLS server software will transparently serve the other one.¶

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

8.8. Public Key Pinning

To reduce the risk of attacks from misissued certificates, relying parties sometimes employ public key pinning [RFC7469]. This enforces that one of some set of public keys appear in the final certificate path. This 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.¶

This protocol reduces this conflict if the pinning relying party uses its effective, reduced trust anchor list. The authenticating party can then, as needed, use a certificate from the pinned CA with the pinning relying party, and another CA with newer relying parties.¶

9.1. Relying Parties

The negotiation mechanism described in this document is analogous to the certificate_authorities extension (Section 4.2.4 of [RFC8446]), but more size-efficient. Like that extension, it presumes the requested trust anchor list is not sensitive.¶

The privacy implications of this are determined by how a relying party uses this extension. Trust anchors supported by a relying party may be divided into three categories:¶

1. Trust anchors whose identifiers the relying party sends unconditionally, i.e. not in response to the server's HTTPS/SVCB record, trust anchor list in EncryptedExtensions, etc.¶

2. Trust anchors whose identifiers 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 identifier is listed in the server's HTTPS/SVCB record or trust anchor list in EncryptedExtensions.¶

3. Trust anchors whose identifiers the relying party never sends, but still trusts. These are trust anchors which do not participate in this mechanism.¶

Each of these categories carries a different fingerprinting exposure:¶

Trust anchor identifiers sent unconditionally can be observed passively. Thus, relying parties SHOULD NOT unconditionally advertise trust anchor lists which are unique to an individual user. Rather, such lists SHOULD be either empty or computed only from the trust anchors common to the relying party's anonymity set (Section 3.3 of [RFC6973]).¶

Trust anchor identifiers 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 baseline exposure for trust anchors that do not participate in negotiation. An authenticating party in possession of a certificate can send it and determine if the relying party accepts or rejects it. Unlike this baseline exposure, trust anchors that participate in this protocol can be probed by only knowing the trust anchor identifier.¶

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

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

9.2. Authenticating Parties

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

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

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

10.1. Relying Party Policies

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

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

10.2. Agility

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

Negotiation also reduces pressures on relying parties to sacrifice user security for compatibility. Suppose an authenticating party currently uses some CA, but a relying party deems trusting that CA to pose an unacceptable security risk to its users. In a single-certificate deployment, those authenticating parties may be unwilling to adopt a CA trusted by the relying party, as switching CAs risks compatibility problems elsewhere. The relying party then faces compatibility pressure and adds this CA, sacrificing user security. However, in a multi-certificate deployment, the authenticating party can use its existing CA in addition to another CA trusted by relying party B. This allows the ecosystem to improve interoperability, while still meeting relying party B's user-security goals.¶

10.3. Incorrect Selection Metadata

If the authenticating party has incorrect information about trust anchor identifiers, it may send an untrusted certification path. This will not result in that path being trusted, but does present the possibility of a degradation of service. However, this information is provisioned by the CA, which is already expected to provide accurate information.¶

10.4. Serving Multiple Certificates

Negotiation reduces compatibility pressures against authenticating parties choosing to serve certificates from a less common CA, as the authenticating party can serve it in addition to other CAs that, together, satisfy all supported relying parties. The CA may even have been distrusted by some relying parties, e.g. if it is needed for older, unupdated relying parties that are still important for the authenticating party to support. As discussed in Section 8 and Section 10.2, this deployment model avoids compatibility risks during PKI transitions which mitigate security risks to users.¶

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

While the choice of CA is a security-critical decision in a PKI, it is the relying party's choice of trusted CAs that determines interceptibility, not the authenticating party's choice of certificates to present. If the relying party trusts an attacker-controlled CA, the attacker can intercept the connection independent of whether the authenticating party uses that CA or another CA. In both cases, the attacker would need to present a different certificate, with a different public key. Conversely, if the relying party does not trust the attacker's CA, the authenticating party's correct but untrusted attacker-issued certificate will not enable the attacker to substitute in a different public key. The ability to intercept a connection via the PKI is determined solely by relying party trust decisions.¶

Relying parties thus SHOULD NOT interpret the authenticating party's choice of CA list as an endorsement of the CA. The authenticating party's role is to present a certificate which will demonstrate its name and TLS key to the relying party. Authenticating parties do not vet CAs for trustworthiness, only the correctness of their specific, configured certificates and the CA's ability to meet the authenticating party's requirements, such as availability, compatibility, and performance. It is the responsibility of the relying party, and its corresponding root program, to determine the set of trusted CAs. Trusting a CA means trusting all certificates issued by that CA, so it is not enough to observe authenticating parties serving correct certificates. An untrustworthy CA may sign one correct certificate, but also sign incorrect certificates, possibly in the future, that can attack the relying party. Root program management is a complex, security-critical process, the full considerations of which are outside the scope of this document.¶

10.5. Targeting TLS Interception

Trust Anchor Identifiers, like certificate_authorities, enables a TLS server to differentiate between clients that do and do not trust some CA. If this CA mis-issued a certificate, this could be used by a network attacker to only enable TLS interception with clients that trust the CA. The network attacker may wish to do this reduce the odds of detection. Clients which do not trust the CA will not accept the mis-issued certificate, which may be user-visible.¶

However, the attacker could also use any existing mechanism for differentiating clients. In TLS parameter negotiation, the client offers all its available TLS features, including cipher suites and other extensions, in the TLS ClientHello. This means any variation in any client TLS policies, related or unrelated to trust anchors, may be used as an implementation fingerprint to differentiate clients. While fingerprinting's heuristic nature makes it not viable for a broad, diverse set of TLS servers, it is viable for a network attacker's single interception service. Trust Anchor Identifiers only impacts detection where this differentiation was not already possible.¶

If the attacker targets any clients that enforce Certificate Transparency [RFC6962], the mis-issued certificates will need to be publicly logged. In this case, detection is more robust, and client differentiation, with or without Trust Anchor Identifiers, has no significant impact.¶

11.1. TLS ExtensionType Updates

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

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

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

[[TODO: Establish a CertificatePropertyType registry.]]¶

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

[RFC8174]

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

[RFC8446]

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

[RFC8555]

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

[RFC9371]

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

[RFC9460]

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

[X680]

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

[X690]

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

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

[Dilithium]

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-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf>.

[I-D.davidben-tls-trust-expr]

Benjamin, D., O'Brien, D., and B. Beck, "TLS Trust Expressions", Work in Progress, Internet-Draft, draft-davidben-tls-trust-expr-04, 28 June 2024, <https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr-04>.

[I-D.ietf-tls-cert-abridge]

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

[I-D.ietf-tls-wkech]

Farrell, S., Salz, R., and B. M. Schwartz, "A well-known URI for publishing service parameters", Work in Progress, Internet-Draft, draft-ietf-tls-wkech-06, 1 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-wkech-06>.

[MOZILLA-ROOTS]

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

[RFC6962]

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

[RFC7469]

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