PLANTS N. Elkins
Internet-Draft Outside the Stacks, Inc.
Intended status: Informational M. Ackermann
Expires: 17 April 2027 Blue Cross Blue Shield of Michigan
14 October 2026
Enterprise Deployment Considerations for Standalone Merkle Tree
Certificates
draft-elkins-plants-enterprise-mtc-deployment-00
Abstract
The migration of public Web PKI authentication to post-quantum
mechanisms must fit enterprise certificate management and TLS
termination architectures. This document examines whether an urgent
need for post-quantum authentication would justify transitional
support for standalone ML-DSA certificates in browser root-store
policy while standalone MTC deployment capabilities mature. The
scope is limited to enterprise public websites accessed by unmanaged
clients using the public Web PKI. Note: a large enterprise may
operate many such sites. The document describes enterprise-managed,
third-party-hosted, and CDN-fronted deployments, identifies the
components needed to serve standalone Merkle Tree Certificates
(MTCs), and examines realistic authentication attack paths and
migration priorities. It distinguishes the browser-to-edge
connection from origin and internal connections, and server
authentication from identity-provider login. The document draws on
initial browser and TLS client testing of Trust Anchor ID signaling,
and proposes interoperability tests and deployment requirements
rather than changes to the MTC wire format. Relative priorities are
illustrative and not empirical attack probabilities.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Elkins & Ackermann Expires 17 April 2027 [Page 1]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
This Internet-Draft will expire on 17 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope: one enterprise use case . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Trust Anchor IDs in ClientHello . . . . . . . . . . . . . . . 6
3.1. Certificate-derived Trust Anchor IDs: an emerging
proposal . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Enterprise deployment architectures . . . . . . . . . . . . . 7
4.1. Enterprise-managed public TLS . . . . . . . . . . . . . . 7
4.2. Hosting-service-managed public TLS . . . . . . . . . . . 8
4.3. CDN-fronted enterprise or hosting-service origin . . . . 9
5. End-to-end certificate lifecycle . . . . . . . . . . . . . . 10
5.1. Issuance and installation . . . . . . . . . . . . . . . . 10
5.2. Renewal, revocation, and coexistence . . . . . . . . . . 10
5.3. Proposed deployment milestones . . . . . . . . . . . . . 12
5.4. Backend boundary . . . . . . . . . . . . . . . . . . . . 12
6. Browser, automation, and TLS terminator requirements . . . . 12
7. Authentication threat model . . . . . . . . . . . . . . . . . 13
7.1. Cryptographic forgery of classical Web PKI
authentication . . . . . . . . . . . . . . . . . . . . . 14
7.2. Concrete browser-facing attack paths . . . . . . . . . . 14
7.3. Identity-provider verification and authenticated
sessions . . . . . . . . . . . . . . . . . . . . . . . . 14
7.4. What a forged certificate does not do . . . . . . . . . . 14
8. Enterprise migration priorities under resource constraints . 15
9. Logging, retention, and incident response . . . . . . . . . . 17
10. Proposed interoperability test plan . . . . . . . . . . . . . 18
11. Questions for PLANTS and implementers . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
14. Evidence Status . . . . . . . . . . . . . . . . . . . . . . . 20
Elkins & Ackermann Expires 17 April 2027 [Page 2]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
15. Appendix A. Proposed Validation Matrix . . . . . . . . . . . 21
16. Appendix B. Selected TrustAsia Handshake Decodings . . . . . 21
16.1. Experimental context and status at the time of
testing . . . . . . . . . . . . . . . . . . . . . . . . 21
16.2. Selected decoded exchange . . . . . . . . . . . . . . . 22
16.3. ClientHello: requested Trust Anchor IDs . . . . . . . . 22
16.4. EncryptedExtensions: available Trust Anchor IDs . . . . 23
16.5. Certificate: standalone MTC and cosigners . . . . . . . 24
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
17.1. Normative References . . . . . . . . . . . . . . . . . . 25
17.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
Large enterprises transmit millions of public-facing transactions
while simultaneously migrating key establishment, internal
authentication, administrative access, and legacy TLS. Our initial
testing of MTC trust-anchor signaling also raised interoperability
questions discussed below. We are discussing standalone MTC in part
because Google's Chrome Quantum-resistant Root Program policy states
that Chrome will not add traditional X.509 certificates containing
post-quantum cryptography to the Chrome Root Store, and identifies
Merkle Tree Certificates as its intended post-quantum public-Web
authentication approach [CHROME-CQRP]. We expect other browser root-
store programs may take a similar approach, although their policies
must be evaluated independently. Thus an enterprise cannot assume
that obtaining a conventional ML-DSA certificate from a CA will make
it trusted by unmanaged browsers. This is a trust-store policy and
ecosystem question, not a claim that ML-DSA itself is unsuitable for
server authentication.
If immediate migration of public Web PKI server authentication were
necessary, enterprises might need a transitional path for
conventional ML-DSA certificates in browser root stores while MTC
deployment support is completed. We are not yet making that case.
Our concern is to establish the actual threat, the relative priority
among enterprise PQC workstreams, and the capabilities still needed
for standalone MTC. If the urgency does not justify a separate ML-
DSA transition, we should say so. If it does, the root-store policy
question deserves a concrete, time-bounded discussion.
Many of the enterprises affected by this transition operate in
heavily regulated sectors and are part of critical infrastructure.
They must meet government requirements, industry obligations,
supervisory expectations, and internal security mandates while
continuing to serve large numbers of unmanaged public clients. The
public also relies on these services for essential financial, health,
Elkins & Ackermann Expires 17 April 2027 [Page 3]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
and other activities. A failed transition or prolonged service
interruption could prevent people from accessing services they depend
on, cause serious distress, and undermine public confidence. These
consequences cannot be discounted when setting migration priorities
and schedules. (The exact requirements and deadlines vary by
jurisdiction and sector; this document does not assert a single
universal government deadline for public Web PKI authentication.)
These enterprises must allocate scarce budgets, obtain approvals,
procure supported products, train staff, and test changes without
interrupting essential services. An experimental implementation is
not a substitute for a commercially available, supported deployment
path.
We propose a practical planning target: by the end of 2027, the
standalone MTC ecosystem should have sufficiently mature,
interoperable, commercially obtainable components for meaningful
enterprise evaluation. This includes browser trust-anchor
distribution and selection, CA issuance, certificate automation,
managed hosting, CDN and TLS termination support, lifecycle
operations, and documented vendor support. Enterprises could then
undertake procurement, integration, pilot testing, operational
validation, and staged deployment, with the goal of production
deployment for the public Web PKI use case by the end of 2028 where
justified by their risk and regulatory requirements. This is not a
target for completion of enterprise-wide PQC migration. These are
proposed planning milestones, not commitments by implementers or
predictions that all necessary specifications, implementations, and
operational capabilities will be completed by those dates.
The same purchasing and integration test applies to conventional
standalone ML-DSA certificates: a cryptographic algorithm or test
endpoint is not enough. Enterprises need supported CA products,
certificate-management interfaces, TLS endpoints, and a browser
trust-store policy that permits unmanaged clients to validate the
certificates. If the full standalone MTC ecosystem cannot be ready
in time for an enterprise's required transition, a time-bounded path
for standalone ML-DSA in the public Web PKI may be needed. That
option would require an explicit browser root-program policy decision
and its own deployment and interoperability testing. We should
establish realistic readiness dates and compare both paths rather
than assume either will be ready.
The availability of a post-quantum public certificate format does not
by itself establish deployability in certificate automation
platforms, third-party hosting TLS termination services, load
balancers, TLS inspection proxies, or browsers. Standalone MTC may
reduce dependencies associated with landmark-relative presentations,
but requires an MTC-aware trust-anchor and serving ecosystem.
Elkins & Ackermann Expires 17 April 2027 [Page 4]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
1.1. Scope: one enterprise use case
This document considers only one use case in the broader enterprise
post-quantum cryptography (PQC) migration: public websites accessed
by unmanaged clients using the public Web PKI. These clients cannot
reasonably be expected to import enterprise-specific trust anchors or
change their browser configuration. Even this narrowly defined use
case can be complex. An enterprise may operate many separate public
websites, potentially reflecting acquisitions, divestitures,
different business units, brands, and legacy systems. Multinational
enterprises may also operate internationalized domain names (IDNs),
which must be included in discovery, certificate inventory, issuance,
validation, and migration testing.
Public-facing websites are only the tip of the iceberg. Enterprise
PQC migration also encompasses connections to business partners and
government agencies, backend processing, internal applications,
thousands of servers, administrative access, private PKI, and legacy
systems. Those environments have different owners, trust models,
contractual dependencies, and upgrade schedules. For some large
organizations, an end-to-end PQC migration may require five to ten
years, or possibly longer. This is a planning estimate based on the
complexity of enterprise environments, not a forecast applicable to
every organization. The narrower public Web PKI deployment
objectives discussed here must not be mistaken for completion of
enterprise-wide PQC migration.
The operating models are illustrative, not a claim that every
enterprise uses the same architecture. API, SSH, private PKI,
partner connections, and internal traffic are included only to
explain risk prioritization and architectural boundaries; their
detailed migration requirements are outside this document's scope.
2. Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this
document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals. This
informational document does not define new protocol requirements.
This document uses the terms relying party, authenticating party,
standalone certificate, landmark-relative certificate, and CA ID as
defined in [I-D.ietf-plants-merkle-tree-certs]. Trust Anchor ID,
trust anchor group, and the trust_anchors extension are defined in
[I-D.ietf-tls-trust-anchor-ids]. We use public TLS endpoint for the
server, load balancer, CDN edge, or proxy that terminates the
browser-facing TLS connection, and origin for the application-facing
Elkins & Ackermann Expires 17 April 2027 [Page 5]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
endpoint behind an intermediary. Certificate manager denotes
software or a managed service that handles enrollment, provisioning,
renewal, and retirement. These last three terms describe deployment
roles, not new protocol elements.
Certificate ownership, key custody, and TLS termination are separate
decisions. Many enterprises choose hosting services such as AWS
precisely because the service can obtain, renew, and deploy
certificates. A CDN does not automatically take ownership of an
origin certificate. The discussion concerns large enterprises
serving unmanaged public Web PKI clients; it does not assume that
every enterprise has the same topology.
3. Trust Anchor IDs in ClientHello
The TLS Trust Anchor Identifiers specification
[I-D.ietf-tls-trust-anchor-ids] defines a new TLS trust_anchors
extension. In ClientHello, its RequestedTrustAnchorList advertises
the Trust Anchor IDs or groups the client supports. The server can
use this information to select an acceptable certificate path. The
extension is not itself a mechanism for installing a new trusted CA
or cosigner. The MTC draft [I-D.ietf-plants-merkle-tree-certs]
recommends this mechanism for standalone MTC selection: the
standalone certificate has the CA's Trust Anchor ID. Although the
MTC specification permits standalone presentation without an explicit
trust signal in some circumstances, we have not demonstrated this
behavior in our initial testing. Interoperable enterprise deployment
should test the actual ClientHello contents and separately test
whether a standalone MTC connection can succeed without the
extension, rather than assume that a browser has the required trust
state.
Initial Chrome Canary and Bouncy Castle testing illustrated how Trust
Anchor ID configuration affects certificate selection. The Chrome
configuration issue observed at that time has since been corrected.
The protocol and implementation work is moving quickly; observations
and unresolved questions reported here reflect the time of testing
and may have changed by the time this document is reviewed.
Appendix B provides the experimental context and selected packet
decodings.
The immediate question is how a browser or another relying party
discovers, installs, updates, removes, and verifies its Trust Anchor
IDs. A registry of the extension format does not supply a directory
of the actual anchor assignments or a cross-platform import
procedure. Enterprises cannot require millions of unmanaged clients
to perform manual imports of trust anchors. We need to test both the
distribution mechanism and what appears on the wire.
Elkins & Ackermann Expires 17 April 2027 [Page 6]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
3.1. Certificate-derived Trust Anchor IDs: an emerging proposal
On October 12, 2026, David Benjamin proposed moving the id-rdna-
trustAnchorID distinguished-name attribute definition from the MTC
specification to the general TLS Trust Anchor IDs specification (TLS
working group PR #133, following issue #132). The proposed text
would permit a relying party to extract a Trust Anchor ID from a
trust anchor whose PKIX distinguished name uses the specified form.
A separately configured association would remain possible, including
for compatibility with existing PKIs. The proposal was under review
at the time of writing and is not treated here as an adopted
requirement. See [TRUST-ANCHOR-ID-RDNA] and
[TRUST-ANCHOR-ID-RDNA-ISSUE].
This can simplify identifier acquisition when establishing a new CA
whose certificate is designed to carry its Trust Anchor ID. It does
not install that CA as trusted or authorize a relying party to trust
it. Nor does it retroactively add the attribute to already-deployed
roots. Existing public or enterprise roots generally require a
separately maintained association unless their trust-anchor
representation or CA identity is changed. The distinction raised in
review between CA-assigned identifiers and identifiers separately
agreed by relying parties and authenticating parties also matters for
interoperability.
For enterprise public websites, the remaining operational questions
are how browsers and other clients receive authorized roots, maintain
identifier and group configurations, handle rotation and distrust,
and advertise the resulting state in ClientHello. Certificate-
derived identifiers may remove one mapping step for newly designed
PKIs, but do not remove the cross-platform trust distribution and
lifecycle requirements examined in this document.
4. Enterprise deployment architectures
4.1. Enterprise-managed public TLS
An enterprise controls its public TLS termination point, which may be
a server, reverse proxy, application delivery controller, or load
balancer. A certificate management platform such as Keyfactor can
automate enrollment, approval, renewal, installation, and withdrawal.
The CA supplies the public credential; the leaf private key is
generated and held according to enterprise policy. The public TLS
terminator must serve the appropriate standalone MTC artifact and
select a credential compatible with the client's advertised trust
anchors.
Elkins & Ackermann Expires 17 April 2027 [Page 7]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
+----------------------------+
| Unmanaged public browser |
| ClientHello: trust_anchors |
+-------------+--------------+
| Public HTTPS
v
+----------------------------+ +------------------+
| Enterprise TLS endpoint |<------| Certificate |
| MTC-capable proxy / LB | | manager |
+-------------+--------------+ +---------^--------+
| Backend TLS |
v |
+----------------------------+ +---------+--------+
| Enterprise applications | | MTC issuer / CA |
+----------------------------+ +------------------+
Identity provider for MFA: separate login flow.
4.2. Hosting-service-managed public TLS
Enterprises frequently use hosting services such as AWS because those
services manage certificate issuance, renewal, and deployment. In
this model, the hosting service manages the public TLS certificate at
its managed termination point, while the enterprise may continue to
operate the application. We need to determine whether the hosting
service can obtain and serve standalone MTC, and whether its
certificate-management interfaces expose the necessary artifacts and
status. The separate origin connection, if any, has its own
authentication arrangements.
+----------------------------+
| Unmanaged public browser |
| ClientHello: trust_anchors |
+-------------+--------------+
| Public HTTPS
v
+----------------------------+ +------------------+
| Hosting-service TLS |<------| Hosting-service |
| termination; MTC served | | cert automation |
+-------------+--------------+ +---------^--------+
| Backend connection |
v |
+----------------------------+ +---------+--------+
| Hosted application/origin | | MTC issuer / CA |
+----------------------------+ +------------------+
Elkins & Ackermann Expires 17 April 2027 [Page 8]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
4.3. CDN-fronted enterprise or hosting-service origin
A CDN can terminate public TLS and open a second TLS connection to
the origin, or, in some architectures, pass traffic through. If it
terminates public TLS, the CDN edge needs a public-facing credential
regardless of whether the enterprise or CDN arranged issuance. The
origin may use an independently managed enterprise or hosting-service
certificate. The enterprise may supply the edge credential, or a
CDN-managed certificate service may do so; these are distinct
choices.
+----------------------------+
| Unmanaged public browser |
| ClientHello: trust_anchors |
+-------------+--------------+
| Public HTTPS
v
+----------------------------+ +------------------+
| CDN edge |<------| Edge credential |
| MTC if TLS terminates here | | CDN / enterprise |
+-------------+--------------+ +------------------+
| Separate origin TLS
v
+----------------------------+ +------------------+
| Enterprise / hosting- |<------| Origin credential|
| service origin | | (separately held)|
+-------------+--------------+ +------------------+
| Application connection
v
+----------------------------+
| Applications / services |
+----------------------------+
With TLS pass-through, the origin serves the public MTC.
Elkins & Ackermann Expires 17 April 2027 [Page 9]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
+=============+===============+============+=======================+
| Decision | Enterprise- | Hosting- | CDN-fronted |
| | managed | service- | |
| | | managed | |
+=============+===============+============+=======================+
| Public TLS | Enterprise | Selected | CDN edge if TLS |
| termination | proxy/LB/ | hosting | terminated; otherwise |
| | server | service | origin |
+-------------+---------------+------------+-----------------------+
| Who enrolls | Enterprise/ | Hosting | CDN or enterprise; |
| public | Keyfactor | service if | depends on edge model |
| certificate | | configured | |
+-------------+---------------+------------+-----------------------+
| Origin | Same endpoint | Service- | Enterprise/hosting- |
| credential | or separate | specific | service-managed, |
| | internal TLS | | separately from edge |
+-------------+---------------+------------+-----------------------+
| Primary MTC | Automation + | Hosting | CDN edge capability + |
| integration | TLS | service | optional enterprise |
| | terminator | capability | provisioning |
+-------------+---------------+------------+-----------------------+
Table 1
5. End-to-end certificate lifecycle
5.1. Issuance and installation
Identify the public TLS termination point, accountable certificate
owner, hostname authorization, CA, algorithm and trust configuration.
Enroll using the supported MTC issuance mechanism, retrieve the
complete standalone artifact, check the binding between credential
and leaf key, stage the artifact, and validate a live fresh handshake
from an independent MTC-capable client. Certificate-manager success
is not proof that the deployed endpoint actually presents a usable
MTC certificate.
5.2. Renewal, revocation, and coexistence
Standalone MTC does not mean that the entire certificate lifecycle is
ready for enterprise deployment. A number of operational behaviors
and interfaces still need to be specified clearly, implemented, and
tested across products. We should not assume that established X.509
practices automatically work for MTC, or that a successful standalone
handshake demonstrates readiness for routine operation.
At a minimum, the following questions need interoperable answers:
Elkins & Ackermann Expires 17 April 2027 [Page 10]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
* Renewal: How does a certificate automation product obtain a
replacement standalone MTC, retain the complete proof and
cosignature material, and deploy it -- without interrupting active
service? How is the transition coordinated across multiple load
balancers, proxies, or CDN edges?
* Revocation and emergency withdrawal: The MTC specification states
that existing certificate-level revocation mechanisms such as CRLs
and OCSP apply unchanged to MTCs
[I-D.ietf-plants-merkle-tree-certs]. The remaining enterprise
question is how these mechanisms interact with MTC deployment,
serving endpoints, automation platforms, and emergency credential
withdrawal. How promptly can relying parties learn of a change,
and what must the TLS operator do independently to remove the old
credential from all serving endpoints? Issuer status and removal
at a serving endpoint are distinct operations.
* Coexistence: How do classical Web PKI credentials and standalone
MTC credentials coexist for the same hostname while browsers and
intermediaries have different capabilities? What exactly happens
when a client does not advertise a matching Trust Anchor ID? An
implementation must not silently claim post-quantum authentication
when it has fallen back to classical authentication.
* Anchor and policy changes: How are Trust Anchor IDs distributed,
updated, withdrawn, and mapped to certificate selection? What
happens during a change of trusted CA or cosigner configuration?
* TLS resumption and existing connections: How are certificate
replacement, revocation, resumed sessions, and long-lived
connections handled? A resumed TLS connection may not present a
new certificate.
* Operational failure and rollback: What happens when issuance
succeeds but installation fails, when only some serving nodes have
the new credential, or when an emergency rollback is needed?
The readiness target is not simply a published specification. An
enterprise must be able to obtain supported products or services,
receive maintenance and security updates, and hold suppliers
accountable for operational failures. For both standalone MTC and
standalone ML-DSA, availability for purchase and support should be
recorded explicitly in an implementation matrix.
Some of these mechanisms are discussed in the evolving MTC
specifications. Others are product interfaces and operational
procedures rather than protocol gaps. This draft does not claim that
all of them are undefined in the protocol. It does claim that the
Elkins & Ackermann Expires 17 April 2027 [Page 11]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
complete, interoperable enterprise deployment profile has not yet
been demonstrated by the evidence cited here. We need to identify
which pieces are already specified, which require implementation
guidance, and which remain open before declaring standalone MTC
operationally ready.
5.3. Proposed deployment milestones
* By end of 2027 -- ecosystem readiness: identify at least one
commercially obtainable and supported path for CA issuance,
certificate automation, browser validation and Trust Anchor ID
updates, and each relevant TLS termination model. Publish
interoperability results, renewal and emergency-withdrawal
behavior, and known limitations. This is a proposed target for
implementer discussion, not an asserted commitment.
* During 2028 -- enterprise qualification: procure the required
components, test at realistic scale, validate monitoring and
rollback, train operators, and complete vendor and compliance
reviews.
* By end of 2028 -- deployment objective: where risk and mandates
require it, complete staged production deployment for the public
Web PKI use case, not the full enterprise PQC migration. If
standalone MTC cannot meet a necessary transition date, evaluate a
time-bounded standalone ML-DSA public Web PKI path with the
relevant browser root programs.
5.4. Backend boundary
After public TLS terminates, backend applications need not parse MTC
solely because the public edge uses MTC. The proxy may connect to
the origin using classical TLS, private ML-DSA, or other mutually
supported authentication. These backend choices have independent
migration schedules. However, if the backend itself terminates the
browser-facing TLS connection, it becomes the public MTC serving
endpoint and must be upgraded accordingly.
6. Browser, automation, and TLS terminator requirements
A browser that supports MTC validation needs the correct trust state
and, for negotiated certificate selection, needs to advertise the
corresponding Trust Anchor IDs in the new ClientHello trust_anchors
extension. The standalone MTC profile recommends this signaling. It
also describes presentation without an explicit trust signal when the
server assumes the CA is already trusted. However, this alternative
has not yet been demonstrated in our tests and must be validated
before being treated as a deployment option. Unlike landmark-
Elkins & Ackermann Expires 17 April 2027 [Page 12]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
relative MTC, standalone presentations should not require the client
to have previously acquired landmark-specific state. The server
still must avoid selecting an MTC credential that the client cannot
validate. Product support for these functions is not presumed.
+=============+==============================+======================+
| Component | Minimum capability | Open implementation |
| | | question |
+=============+==============================+======================+
| Browser | Advertise correct | How are anchor sets |
| | trust_anchors Trust | distributed, |
| | Anchor IDs; validate | updated, and tested |
| | standalone MTC and | across browsers? |
| | relevant status/policy | |
+-------------+------------------------------+----------------------+
| Certificate | Enroll/retrieve full | Can existing APIs |
| manager | standalone artifact; | treat the artifact |
| | preserve proof and | as opaque bytes |
| | cosignatures; renew and | without truncation |
| | provision | or rewriting? |
+-------------+------------------------------+----------------------+
| TLS LB / | Receive ClientHello; | Can generic anchor- |
| reverse | select and serve | aware certificate |
| proxy | compatible MTC | selection suffice |
| | credential; negotiate | without MTC-specific |
| | supported authentication | proof parsing? |
+-------------+------------------------------+----------------------+
| CA and log | Issue standalone MTC | What issuance and |
| ecosystem | with required log/ | availability SLAs |
| | cosigner material and | apply? |
| | status mechanisms | |
+-------------+------------------------------+----------------------+
| Third-party | Support chosen edge | Which concrete |
| hosting/CDN | credential mode and | products, regions |
| provider | complete rollout | and edge versions |
| | | support the feature? |
+-------------+------------------------------+----------------------+
Table 2
7. Authentication threat model
Elkins & Ackermann Expires 17 April 2027 [Page 13]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
7.1. Cryptographic forgery of classical Web PKI authentication
Assume a future cryptographically relevant quantum computer can
recover a classical TLS authentication private key or produce
signatures accepted under a classical CA public key. In the first
case an attacker can impersonate a server using its genuine
certificate while it remains accepted; in the second the attacker can
construct a fraudulent certificate subject to client hostname, trust,
validity, CT, and policy checks. Neither capability alone redirects
traffic or compromises the real origin. The attacker must
additionally attract, intercept, or redirect a browser connection.
7.2. Concrete browser-facing attack paths
Certificate Transparency can expose or constrain unauthorized
issuance but is not a substitute for quantum-resistant
authentication: an attacker who recovers the genuine server
authentication key may use the already logged certificate.
Historical CA misissuance incidents demonstrate certificate-assisted
interception but do not measure the future prevalence of quantum-
enabled signature forgery.
7.3. Identity-provider verification and authenticated sessions
In the representative identity-provider pattern, a user authenticates
through an identity provider for MFA, such as Okta, and may complete
MFA at login or at selected step-up events. After authentication the
application maintains a session, commonly through a bearer cookie.
The identity provider can protect initial identity verification
without authenticating each subsequent TLS connection. An impostor
public TLS endpoint may receive an existing cookie for the same
hostname if the browser accepts the impostor server, or may
manipulate post-login application traffic. Phishing-resistant MFA
reduces certain login attacks but does not itself authenticate the
public Web PKI TLS endpoint. Specific risks depend on redirect URI
validation, cookie scope, token binding, session lifetime, and
application design.
7.4. What a forged certificate does not do
* It does not, by itself, decrypt previously recorded sessions
protected by sound post-quantum key establishment.
* It does not automatically grant access to the legitimate origin,
database, or administrative systems.
* It does not, by itself, redirect DNS, BGP, or a browser to the
attacker.
Elkins & Ackermann Expires 17 April 2027 [Page 14]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
* It does not make identity-provider authentication or MFA
disappear; it can, however, expose sessions after login.
+================+=======================+======================+
| Attack path | Additional | Possible impact |
| | prerequisites | |
+================+=======================+======================+
| On-path | Attacker controls a | Read/modify a victim |
| interception | Wi-Fi, gateway, ISP, | session; steal |
| | or other traffic path | bearer cookies or |
| | and can impersonate | alter transactions |
| | server authentication | |
+----------------+-----------------------+----------------------+
| DNS or route | Attacker influences | Redirect client to |
| manipulation | destination selection | impostor endpoint; |
| | or packet routing | session and content |
| | | compromise |
+----------------+-----------------------+----------------------+
| Malicious | User or application | Capture credentials |
| endpoint | reaches an impostor | or session material; |
| redirection | endpoint for the | deliver manipulated |
| | intended hostname | content |
+----------------+-----------------------+----------------------+
| Existing | Browser sends valid | Account/session |
| session-cookie | cookie to an impostor | hijack without |
| capture | matching the | repeating MFA, |
| | legitimate hostname | subject to session |
| | | protections |
+----------------+-----------------------+----------------------+
| CA-level | Attacker can | Potential |
| signing | impersonate a trusted | impersonation across |
| compromise | CA signing authority | many hostnames, but |
| | | still needs client |
| | | traffic |
+----------------+-----------------------+----------------------+
Table 3
8. Enterprise migration priorities under resource constraints
Enterprises do not have unlimited time, money, personnel, or
maintenance windows. A post-quantum migration competes with ordinary
security work, aging infrastructure replacement, application
upgrades, and ongoing operations. We cannot treat every
cryptographic dependency as equally urgent or assume that deploying a
new public Web PKI certificate is the first task. We need to ask
what an attacker can do, when the exposure begins, how much damage
may follow, and what it takes to fix the problem. These risk-based
Elkins & Ackermann Expires 17 April 2027 [Page 15]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
priorities must also be balanced against applicable government
mandates and regulatory requirements, which are especially relevant
to the large enterprises and critical-infrastructure operators
considered here. Such mandates may impose deadlines or obligations
that differ from an enterprise's own technical risk ranking.
The following ordering is a proposed starting point for enterprise
planning, not a universal ranking or a numerical estimate of attack
probability. Enterprises should adjust it for their own inventories,
exposed services, and dependencies. Several workstreams must proceed
in parallel because they have long lead times.
1. Protect sensitive traffic against harvest-now-decrypt-later.
Deploy supported hybrid or post-quantum key establishment on TLS
1.3 connections that carry information requiring long-term
confidentiality. An adversary can collect vulnerable traffic
today, before a cryptographically relevant quantum computer
exists. This makes delay consequential now.
2. Find and address legacy TLS and systems that cannot migrate.
Inventory TLS 1.0, 1.1, and 1.2 dependencies, unsupported
appliances, and applications that cannot negotiate modern key
establishment. Some replacements will require procurement,
vendor changes, and lengthy testing. We need to begin this work
early, even when the immediate solution is not available. In
some cases, migration may not be possible within the enterprise's
control. Enterprises we have discussed this with have identified
legacy connections and systems that they cannot upgrade
unilaterally. This is an observed operational problem, not a
hypothetical one. Government agencies, such as criminal justice
agencies and departments of revenue, face similar challenges with
their own legacy systems and external dependencies. These are
separate examples of the same broader migration difficulty; the
enterprises consulted are not being described as connecting to
those agencies. An interim response may require fencing off or
isolating legacy connections, restricting access, and applying
compensating controls while maintaining necessary services.
Durable solutions may also require procurement decisions,
interagency coordination, contractual arrangements, or changes in
government policy. Those decisions extend beyond IETF protocol
specifications and may be outside the authority of the
organization responsible for a legacy connection.
3. Protect privileged administrative access, with SSH as an example.
SSH is included as an example of a competing migration priority,
not as part of the public Web PKI or MTC protocol scope. Review
SSH user authentication, authorized keys, access controls, and
exposure of administrative services. If an attacker can forge a
Elkins & Ackermann Expires 17 April 2027 [Page 16]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
signature for an authorized classical SSH user key, that may
enable a login with the privileges of that account, subject to
network reachability and other controls. Such access can lead to
server takeover and lateral movement. Forging an SSH host key is
different: it impersonates a server but does not, by itself,
grant administrative access. We need to distinguish these cases
and prioritize especially powerful accounts and reachable
systems.
4. Inventory and migrate other high-consequence signatures and
private PKI uses. Machine identities, software and firmware
signing, long-lived business signatures, and internal service
authentication have different consequences and verification
lifetimes. Work involving privileged systems, or evidence that
must remain trustworthy for years, may need an earlier transition
than ordinary public website authentication.
5. Prepare public Web PKI server authentication for MTC. We agree
that classical server authentication must eventually be replaced.
A future attacker who can forge a CA or server signature may
impersonate a public website, but generally must also intercept,
redirect, or attract the client's connection. This is serious,
especially for authenticated sessions, but it is not equivalent
to taking control of the enterprise server. We should implement
and test browser Trust Anchor IDs, certificate automation, and
TLS termination support for standalone MTC now, while assessing
when production migration is justified.
These priorities do not imply that public Web PKI authentication can
wait indefinitely. The transition must finish before classical
authentication becomes unsafe, and enterprise deployments take time.
They do imply that we need evidence before diverting scarce resources
from exposures that can already be exploited or from systems with
more direct paths to privileged control. If an immediate Web PKI
authentication transition proves necessary before standalone MTC is
deployable, then a temporary policy path for conventional ML-DSA
certificates deserves consideration. Otherwise, the better
investment may be to finish the standalone MTC deployment ecosystem.
9. Logging, retention, and incident response
The enterprises we consulted did not identify routine per-handshake
certificate logging as a requirement in their environments. We do
not know whether other enterprises have such a requirement, and
invite those that do to describe it. Those operators should bring
their requirements and evidence to the working group so that the
deployment discussion reflects their practices as well. A server
ordinarily need not archive every certificate presentation, and an
Elkins & Ackermann Expires 17 April 2027 [Page 17]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
application need not record the public TLS certificate for every
transaction. Certificate-manager enrollment history, deployment
inventory, edge activation records, incident records, and independent
endpoint observations are distinct from high-volume connection logs.
The availability and retention of these records should be verified
with each provider; the draft does not propose a new universal
certificate logging obligation.
MTC artifacts may be retained at issuance or deployment time to
support later investigations, but that is an operational
recommendation rather than a requirement to log every handshake.
Long-term legal proof of a business transaction is a separate problem
from ephemeral TLS server authentication.
10. Proposed interoperability test plan
Test 1. Enroll a standalone MTC certificate from a compatible CA;
preserve all artifact bytes and metadata in the certificate manager.
Test 2. Provision it to an enterprise TLS proxy/load balancer; test
a browser ClientHello containing the expected Trust Anchor IDs.
Test 3. Test a client that does not advertise the relevant Trust
Anchor ID. Determine whether a standalone MTC connection can succeed
without the trust_anchors ClientHello extension under the conditions
allowed by the specification, and document certificate selection,
validation, fallback, and rejection behavior. Our initial testing
did not establish this path.
Test 4. Test concurrent classical and standalone MTC credentials for
one hostname, including certificate selection.
Test 5. Renew and replace the MTC credential; confirm activation on
all serving nodes and retirement of the old credential.
Test 6. Test emergency revocation, expired credentials, untrusted
anchors, and policy changes.
Test 7. Verify commercially supported enrollment, renewal, rollback,
and help-desk escalation with actual CA, automation, hosting, CDN,
and TLS termination products; distinguish vendor roadmaps from
shipping functionality.
Test 8. Repeat applicable Tests 1 through 7 for both a hosting-
service-managed public TLS termination point and a CDN edge.
Distinguish the browser-facing TLS endpoint from the origin, and
document any tests that cannot be performed because the provider does
not expose the required interfaces.
Elkins & Ackermann Expires 17 April 2027 [Page 18]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
Test 9. Test login through an identity provider for MFA (such as
Okta), post-login cookies, session resumption, and backend origin TLS
independently of the public MTC validation.
Test 10. Establish a test CA whose distinguished name carries the
proposed id-rdna-trustAnchorID attribute. In two independent
relying-party implementations, compare certificate-derived IDs with
separately configured IDs, verify ClientHello signaling, and confirm
that extracting an identifier never authorizes an untrusted CA.
Repeat with an existing root lacking the attribute and document the
separate association and update procedure. This test depends on the
evolving proposal and is not an assertion of existing product
support.
For each of Tests 1 through 10, capture the applicable ClientHello/
ServerHello extension behavior, served certificate form, verification
result, fallback behavior, timing and packet sizes, and product/
version details. Record when an observation is not applicable or
cannot be obtained. A successful test should not depend on archiving
each transaction certificate.
11. Questions for PLANTS and implementers
* What capabilities must TLS libraries, load balancers, and reverse
proxies expose to read the Trust Anchor IDs advertised in
ClientHello and select an appropriate standalone MTC credential?
Can existing certificate-selection interfaces support this, or are
new interfaces required?
* Can standalone MTC be served as an opaque credential by existing
TLS proxies, or is additional library support unavoidable?
* Can existing enterprise ACME clients and certificate-lifecycle
platforms support the MTC ACME profile defined in
[I-D.ietf-plants-merkle-tree-certs], including the standalone
artifact, optional alternate certificate, CertificatePropertyList,
Trust Anchor ID information, and associated renewal and deployment
workflows? What implementation changes are required?
* How do third-party hosting/CDN products expose managed versus
customer-supplied MTC credentials?
* What is the required behavior when no advertised Trust Anchor ID
matches the available MTC credential?
* Which MTC issuance, status, renewal, and revocation tests can be
standardized as an interoperability profile?
Elkins & Ackermann Expires 17 April 2027 [Page 19]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
* Can implementers publish concrete support matrices, commercial
availability dates, and supported configurations against a
proposed end-of-2027 ecosystem-readiness target?
* Can large enterprises realistically complete procurement,
integration testing, and staged production deployment by the end
of 2028? What dependencies would prevent that, and what revised
readiness and deployment dates would follow?
* If standalone MTC cannot meet a required transition date, what
policy and product steps would be necessary for a time-bounded
standalone ML-DSA alternative?
* How do standalone MTC, classical certificate chains, and ML-DSA
certificate chains compare at real enterprise TLS endpoints in
transmitted bytes, handshake latency, processing time, and
verification cost? Which measurements show reductions or
increases?
12. Security Considerations
A post-quantum certificate alone does not prevent traffic
redirection, origin compromise, or misissued credentials. A TLS
endpoint must select only credentials compatible with the client's
authenticated trust policy, and avoid silent downgrade behavior that
undermines intended post-quantum authentication. Certificate
automation and provisioning interfaces are high-value targets. Edge-
to-origin TLS, private PKI, identity-provider flows, session cookies,
and administrative SSH require independent threat models. CRQC
arrival time and attacker access capabilities are uncertain; risk
estimates should not be presented as observed attack frequencies.
13. IANA Considerations
This document requests no IANA actions.
14. Evidence Status
The IAB PQWS workshop materials at
https://datatracker.ietf.org/group/pqws/materials/ (including S21 and
S46) provide background on deployment and performance questions. The
deployment architectures and operational questions in this document
are illustrative and do not establish commercial interoperability for
standalone MTC at Keyfactor, Zscaler, AWS, or any CDN. Quantitative
attack probabilities are intentionally omitted pending defensible
evidence.
Elkins & Ackermann Expires 17 April 2027 [Page 20]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
Proposed Validation Matrix
The following deployment configurations are proposed for validation.
All are to be tested; no product support is implied. For every row,
verify browser validation of standalone MTC using the correct Trust
Anchor IDs.
+=========================+=================+=====================+
| Environment | Certificate | Public TLS endpoint |
| | management | |
+=========================+=================+=====================+
| Enterprise-owned | Keyfactor or | F5, NGINX, HAProxy, |
| | equivalent | or equivalent |
+-------------------------+-----------------+---------------------+
| Hosting-service-managed | Hosting-service | Managed hosting TLS |
| | automation | termination |
+-------------------------+-----------------+---------------------+
| CDN-managed edge | CDN issuance | CDN TLS edge |
| | service | |
+-------------------------+-----------------+---------------------+
| Customer-supplied CDN | Enterprise | CDN TLS edge |
| edge | manager and CDN | |
| | API | |
+-------------------------+-----------------+---------------------+
Table 4
Selected TrustAsia Handshake Decodings
16.1. Experimental context and status at the time of testing
The following describes the configuration and observations at the
time of the experiments. MTC specifications, implementations,
browser metadata, and trust-anchor provisioning are evolving rapidly.
An issue unresolved in these tests may have been addressed by the
time this document is read. In particular, the Chrome Trust Anchor
ID configuration issue was subsequently corrected; it is not
presented as a current Chrome defect. The experiments do not
establish current behavior across other client implementations.
This issue arose in our initial testing. We enabled experimental MTC
support in Chrome Canary and attempted to connect to the TrustAsia
MTC endpoint at https://mtcdemo.trustasia.cn/. The browser sent a
trust_anchors extension, but the observed ClientHello did not contain
the TrustAsia anchor ID. The intended MTC connection was not
established. We then constructed a Bouncy Castle TLS client that
explicitly supplied the required ID, after which the server could
select and present the MTC path. The test demonstrated a
Elkins & Ackermann Expires 17 April 2027 [Page 21]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
configuration and discovery problem, not a proof that all Chrome
builds or MTC implementations have the same defect. We were not able
to complete the intended standalone MTC connection without
advertising the required Trust Anchor ID in ClientHello. Although
the specification describes circumstances in which a server can
present standalone MTC without explicit trust-anchor signaling, that
path remains untested in our environment and needs a separate
interoperability test. The Chrome Trust Anchor ID configuration
issue observed in those tests has since been corrected; the cross-
platform discovery and import questions remain.
The accompanying TrustAsia packet capture provides a concrete example
of the protocol elements involved. The decoded ClientHello
advertised two TrustAsia Trust Anchor IDs; EncryptedExtensions
carried a server-side list; and the Certificate message contained a
standalone MTC presentation with three cosignatures. Appendix B
reproduces selected fields from the Lua dissector output. The
earlier Chrome Canary test is described for context; its packet trace
is not included here. All packets reproduced in this appendix are
from our custom Bouncy Castle TLS client, configured to advertise the
TrustAsia Trust Anchor IDs. The decoded fields demonstrate what can
be observed on the wire, but do not establish that every browser,
certificate manager, or TLS terminator can import and maintain the
corresponding trust state.
16.2. Selected decoded exchange
This appendix reproduces selected fields decoded using a Wireshark
Lua dissector that we wrote specifically for these experiments
because a suitable dissector for the MTC and Trust Anchor ID
structures was not available in our testing environment. Transport
headers, repeated diagnostic lines, and signature byte dumps are
omitted for readability. The values shown are observations from this
captured exchange, not proposed assignments or a claim about all
implementations. The decoded ClientHello was sent to
mtcdemo.trustasia.cn using TLS 1.3 and the X25519MLKEM768 group. The
capture includes a server Certificate message decoded as a standalone
MTC. The excerpts are not, by themselves, proof of independent
cryptographic validation of every cosignature.
16.3. ClientHello: requested Trust Anchor IDs
Elkins & Ackermann Expires 17 April 2027 [Page 22]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
TLS trust_anchors (0xCA34)
Anchor list length: 14
List semantics: RequestedTrustAnchorList (ClientHello)
Trust Anchor ID #1: 44494.3.1.1
Anchor ID length: 6
Anchor ID raw: 82db4e030101
Anchor ID: 44494.3.1.1
Full OID: 1.3.6.1.4.1.44494.3.1.1
IANA PEN: 44494
IANA PEN owner: TrustAsia Technologies, Inc.
Enterprise-relative portion: 3.1.1
Trust Anchor ID #2: 44494.3.1.2
Anchor ID length: 6
Anchor ID raw: 82db4e030102
Anchor ID: 44494.3.1.2
Full OID: 1.3.6.1.4.1.44494.3.1.2
IANA PEN: 44494
IANA PEN owner: TrustAsia Technologies, Inc.
Enterprise-relative portion: 3.1.2
Anchor count: 2
The client advertised two TrustAsia identifiers, 44494.3.1.1 and
44494.3.1.2. The dissector expanded their enterprise-relative
identifiers under the private-enterprise OID prefix 1.3.6.1.4.1. The
IANA PEN association identifies the registered PEN owner, not the
meaning or trustworthiness of each subordinate identifier.
16.4. EncryptedExtensions: available Trust Anchor IDs
Elkins & Ackermann Expires 17 April 2027 [Page 23]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
TLS trust_anchors (0xCA34)
Anchor list length: 18
List semantics: AvailableTrustAnchorList (EncryptedExtensions)
Trust Anchor ID #1: 44494.3.1.1.1.1.496
Anchor ID length: 10
Anchor ID raw: 82db4e03010101018370
Anchor ID: 44494.3.1.1.1.1.496
Full OID: 1.3.6.1.4.1.44494.3.1.1.1.1.496
IANA PEN: 44494
IANA PEN owner: TrustAsia Technologies, Inc.
Enterprise-relative portion: 3.1.1.1.1.496
Trust Anchor ID #2: 44494.3.1.1
Anchor ID length: 6
Anchor ID raw: 82db4e030101
Anchor ID: 44494.3.1.1
Full OID: 1.3.6.1.4.1.44494.3.1.1
IANA PEN: 44494
IANA PEN owner: TrustAsia Technologies, Inc.
Enterprise-relative portion: 3.1.1
Anchor count: 2
The server's decoded AvailableTrustAnchorList contained
44494.3.1.1.1.1.496 and 44494.3.1.1. The lists are not identical:
the server advertised a more specific identifier as well as an
identifier also present in ClientHello. This demonstrates why an
implementation must record the exact identifiers on both sides rather
than infer trust state from the presence of the extension alone.
16.5. Certificate: standalone MTC and cosigners
Elkins & Ackermann Expires 17 April 2027 [Page 24]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
Merkle Tree Certificate (MTC)
MTC proof algorithm OID: 1.3.6.1.4.1.44363.47.0
Note: Certificate serial DER bytes: 0100000000276A
MTC log number: 1
MTC log entry index: 10090
Entry extensions vector length: 0
Subtree start: 10090
Subtree end: 10091
Inclusion proof length: 0
Signatures vector length: 7287
MTC Cosigner #1 - ID 44494.3.1.1 - Signature 2420 bytes
Cosigner ID raw: 82db4e030101
Cosigner full OID: 1.3.6.1.4.1.44494.3.1.1
MTC Cosigner #2 - ID 44494.3.2.1 - Signature 2420 bytes
Cosigner ID raw: 82db4e030201
Cosigner full OID: 1.3.6.1.4.1.44494.3.2.1
MTC Cosigner #3 - ID 66252.128.0 - Signature 2420 bytes
Cosigner ID raw: 84854c810000
Cosigner full OID: 1.3.6.1.4.1.66252.128.0
Cosignature count: 3
MTC profile: Standalone MTC proof
The decoded certificate contained three cosignature entries of 2,420
bytes each. Two identifiers were under PEN 44494 and one under PEN
66252. The capture's decoder labeled the presentation as a
standalone MTC proof. These cosigner identifiers are not
interchangeable with the client's list of trusted anchor IDs, and the
observed structure alone does not establish the client's
authorization policy or successful validation of every signature.
17. References
17.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/info/rfc2119>.
[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/info/rfc8174>.
Elkins & Ackermann Expires 17 April 2027 [Page 25]
Internet-Draft Enterprise Standalone MTC Deployment October 2026
[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-07, 7 October 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-plants-
merkle-tree-certs-07>.
[I-D.ietf-tls-trust-anchor-ids]
Beck, B., Benjamin, D., O'Brien, D., and K. Nekritz, "TLS
Trust Anchor Identifiers", Work in Progress, Internet-
Draft, draft-ietf-tls-trust-anchor-ids-06, 30 September
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
tls-trust-anchor-ids-06>.
17.2. Informative References
[CHROME-CQRP]
Google Chrome Root Program, "Chrome Quantum-resistant Root
Program Policy, draft v0.3.0", 14 August 2026,
<https://googlechrome.github.io/chromerootprogram/cqrp/
draft-policy/>.
[TRUST-ANCHOR-ID-RDNA]
Benjamin, D., "Move id-rdna-trustAnchorID to the Trust
Anchor IDs specification", 12 October 2026,
<https://github.com/tlswg/tls-trust-anchor-ids/pull/133>.
TLS Trust Anchor IDs pull request 133; proposal under
review at the time of writing
[TRUST-ANCHOR-ID-RDNA-ISSUE]
Benjamin, D., "Move id-rdna-trustAnchorID to Trust Anchor
IDs", October 2026, <https://github.com/tlswg/tls-trust-
anchor-ids/issues/132>. TLS Trust Anchor IDs issue 132;
discussion of certificate-derived identifiers
Authors' Addresses
Nalini Elkins
Outside the Stacks, Inc.
United States
Email: nalini.elkins@outsidethestacks.com
Michael Ackermann
Blue Cross Blue Shield of Michigan
United States
Email: mackermann@bcbsm.com
Elkins & Ackermann Expires 17 April 2027 [Page 26]