PLANTS N. Elkins Internet-Draft Outside the Stacks, Inc. Intended status: Informational M. Ackermann Expires: 22 April 2027 Blue Cross Blue Shield of Michigan 19 October 2026 Enterprise Deployment Considerations for Standalone Merkle Tree Certificates draft-elkins-plants-enterprise-mtc-deployment-01 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 22 April 2027 [Page 1] Internet-Draft Enterprise Standalone MTC Deployment October 2026 This Internet-Draft will expire on 22 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope: one enterprise use case . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Trust Anchor IDs in ClientHello . . . . . . . . . . . . . . . 7 3.1. Certificate-derived Trust Anchor IDs: an emerging proposal . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Recovery must not bypass certificate validation . . . . . 8 4. Enterprise deployment architectures . . . . . . . . . . . . . 9 4.1. Enterprise-managed public TLS . . . . . . . . . . . . . . 9 4.2. Hosting-service-managed public TLS . . . . . . . . . . . 9 4.3. CDN-fronted enterprise or hosting-service origin . . . . 10 5. End-to-end certificate lifecycle . . . . . . . . . . . . . . 12 5.1. Issuance and installation . . . . . . . . . . . . . . . . 12 5.2. Renewal, revocation, and coexistence . . . . . . . . . . 12 5.3. Proposed deployment milestones and critical path . . . . 13 5.3.1. 2026 Q4: Establish protocol and implementation dependencies . . . . . . . . . . . . . . . . . . . . 13 5.3.2. 2027 Q1: Inventory TLS termination interfaces . . . . 14 5.3.3. 2027 Q1-Q2: Establish client trust and issuance test paths . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3.4. 2027 Q2: Prototype interoperable certificate provisioning . . . . . . . . . . . . . . . . . . . . 14 5.3.5. 2027 Q2-Q3: Test lifecycle operations and recovery . 15 5.3.6. 2027 Q3: Demonstrate the three public TLS termination models . . . . . . . . . . . . . . . . . . . . . . . 15 5.3.7. 2027 Q3-Q4: Complete operational interoperability tests . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3.8. 2027 Q4: Establish commercially supported deployment paths . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3.9. 2028: Conduct enterprise qualification . . . . . . . 16 Elkins & Ackermann Expires 22 April 2027 [Page 2] Internet-Draft Enterprise Standalone MTC Deployment October 2026 5.3.10. 2028 Q4: Target staged production deployment . . . . 16 5.3.11. Vendor coverage and standards reality check . . . . . 16 5.4. Backend boundary . . . . . . . . . . . . . . . . . . . . 19 6. Browser, automation, and TLS terminator requirements . . . . 19 7. Trust-aware selection and certificate-management interfaces . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Client and server trust, and the reverse-proxy boundary . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. Credential selection and deployment security risks . . . 23 7.3. Independent orders, atomic updates, and failure recovery . . . . . . . . . . . . . . . . . . . . . . . . 23 7.4. Implementation readiness and deployment constraints . . . 24 7.5. Public and private trust-store boundaries . . . . . . . . 24 7.6. Additional implementation questions raised in review . . 25 8. Authentication threat model . . . . . . . . . . . . . . . . . 25 8.1. Cryptographic forgery of classical Web PKI authentication . . . . . . . . . . . . . . . . . . . . . 25 8.2. Concrete browser-facing attack paths . . . . . . . . . . 25 8.3. Identity-provider verification and authenticated sessions . . . . . . . . . . . . . . . . . . . . . . . . 26 8.4. What a forged certificate does not do . . . . . . . . . . 26 9. Enterprise migration priorities under resource constraints . 27 10. Logging, retention, and incident response . . . . . . . . . . 30 11. Proposed interoperability test plan . . . . . . . . . . . . . 30 11.1. Additional proxy and application interoperability tests . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Questions for PLANTS and implementers . . . . . . . . . . . . 32 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 16. Evidence Status . . . . . . . . . . . . . . . . . . . . . . . 34 17. Appendix A. Proposed Validation Matrix . . . . . . . . . . . 34 18. Appendix B. Selected TrustAsia Handshake Decodings . . . . . 35 18.1. Experimental context and status at the time of testing . . . . . . . . . . . . . . . . . . . . . . . . 35 18.2. Selected decoded exchange . . . . . . . . . . . . . . . 36 18.3. ClientHello: requested Trust Anchor IDs . . . . . . . . 37 18.4. EncryptedExtensions: available Trust Anchor IDs . . . . 38 18.5. Certificate: standalone MTC and cosigners . . . . . . . 39 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 19.1. Normative References . . . . . . . . . . . . . . . . . . 39 19.2. Informative References . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Elkins & Ackermann Expires 22 April 2027 [Page 3] Internet-Draft Enterprise Standalone MTC Deployment October 2026 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, 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. Elkins & Ackermann Expires 22 April 2027 [Page 4] Internet-Draft Enterprise Standalone MTC Deployment October 2026 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. 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, Elkins & Ackermann Expires 22 April 2027 [Page 5] Internet-Draft Enterprise Standalone MTC Deployment October 2026 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 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 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. Elkins & Ackermann Expires 22 April 2027 [Page 6] Internet-Draft Enterprise Standalone MTC Deployment October 2026 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. 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 Elkins & Ackermann Expires 22 April 2027 [Page 7] Internet-Draft Enterprise Standalone MTC Deployment October 2026 [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. 3.2. Recovery must not bypass certificate validation The Trust Anchor ID recovery mechanism addresses cases where the client and server did not initially agree on a usable trust anchor or certificate selection. It must not be treated as a second chance to accept a certificate that the relying party has already rejected on ordinary validation grounds. PR #135, merged into the Trust Anchor IDs repository on 17 October 2026, adds explicit guidance concerning certificates that are not trusted for reasons other than anchor selection [TAI-RECOVERY-PR135]. As of 19 October 2026, this clarification has been merged into the TLS Working Group source repository and appears in its continuously generated draft, but has not yet been incorporated into a numbered Internet-Draft published through the IETF Datatracker. A client that recognizes an issuer but rejects a certificate because of expiry, revocation, hostname mismatch, or local trust constraints should not retry merely by explicitly requesting the same Trust Anchor ID. Otherwise, a recovery attempt may conceal a validation failure as a negotiation problem. Tests should distinguish selection mismatch, validation failure, recovery attempted or suppressed, and final outcome. These are separate observables for external TLS measurements. Elkins & Ackermann Expires 22 April 2027 [Page 8] Internet-Draft Enterprise Standalone MTC Deployment October 2026 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. +----------------------------+ | 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. Elkins & Ackermann Expires 22 April 2027 [Page 9] Internet-Draft Enterprise Standalone MTC Deployment October 2026 +----------------------------+ | 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 | +----------------------------+ +------------------+ 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 22 April 2027 [Page 10] 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 Elkins & Ackermann Expires 22 April 2027 [Page 11] Internet-Draft Enterprise Standalone MTC Deployment October 2026 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: * 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. Elkins & Ackermann Expires 22 April 2027 [Page 12] Internet-Draft Enterprise Standalone MTC Deployment October 2026 * 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 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 and critical path The end-of-2027 target is a proposed ecosystem-readiness milestone. Enterprises would begin staged deployment in 2028, following qualification and subject to their individual readiness and approval processes. The following dates are planning checkpoints for discussion with implementers, not commitments by standards bodies, browser vendors, CAs, or product suppliers. Workstreams must overlap. Failure to complete a critical predecessor requires a revised schedule and documented contingency. 5.3.1. 2026 Q4: Establish protocol and implementation dependencies PLANTS, TLS, and ACME participants identify stable protocol dependencies, Trust Anchor ID codepoint status, and implementation gaps. Elkins & Ackermann Expires 22 April 2027 [Page 13] Internet-Draft Enterprise Standalone MTC Deployment October 2026 Completion criterion: Publish an issue and dependency register covering codepoint status, MTC specification maturity, Trust Anchor ID recovery semantics, and the relevant TLS, PLANTS, and ACME documents. For each document record its current stage, unresolved issues, likely next review step, and an implementer contact or an explicitly unassigned item. Do not equate a projected RFC publication date with product availability. Dependency: Current specifications and codepoint allocation. 5.3.2. 2027 Q1: Inventory TLS termination interfaces TLS library and reverse-proxy implementers inventory certificate- selection APIs and configuration models. Completion criterion: Publish a matrix covering SNI, algorithms, client-versus-server trust direction, trust-aware selection, property lists, default credentials, key references, proxy-to-library boundaries, and reload behavior. Inventory at least two independently maintained implementations in each applicable class and contact their maintainers; document which capabilities are shipping, experimental, planned, unsupported, or unknown. Dependency: Trust Anchor ID semantics. 5.3.3. 2027 Q1-Q2: Establish client trust and issuance test paths Browser/root-store and CA implementers document test trust-anchor distribution, MTC issuance, and validation paths. Completion criterion: Produce reproducible test profiles for two independent clients and a test issuer, documenting policy differences. Record which browser and CA/root-program participants have agreed to test, whether tooling is available today, and what must be built. Chrome's published test-root/cosigner program is a candidate test path, not evidence of general production availability. Dependency: MTC profile maturity and trust configuration. 5.3.4. 2027 Q2: Prototype interoperable certificate provisioning Certificate managers and reverse proxies prototype interoperable provisioning of certificates together with their properties. Completion criterion: Demonstrate an independent manager-to- terminator test, including separate default and negotiated lineages and a documented application/proxy boundary. Elkins & Ackermann Expires 22 April 2027 [Page 14] Internet-Draft Enterprise Standalone MTC Deployment October 2026 Dependency: Interface inventory and certificate artifact formats. 5.3.5. 2027 Q2-Q3: Test lifecycle operations and recovery Implementers test automatic addition and removal of alternates, independent orders, atomic changes, and recovery. Completion criterion: Publish repeatable positive and fault-injection tests, including rollback and least-privilege controls. Include Trust Anchor ID recovery after a certificate-selection mismatch, and a negative test ensuring that recovery is not used to re-request a trust anchor after the certificate was rejected for expiration, revocation, name mismatch, or another validation constraint. Dependency: Provisioning prototype. 5.3.6. 2027 Q3: Demonstrate the three public TLS termination models TLS termination vendors, hosting services, and CDNs demonstrate standalone MTC serving and fallback. Completion criterion: Publish test endpoints and results for enterprise-managed, hosting-managed, and CDN edge termination, identifying unsupported models. Contact representative operators in each category and record explicit participation, refusal, no response, and the product/version tested; do not infer support from generic PQC or TLS 1.3 marketing. Dependency: Client trust and credential selection. 5.3.7. 2027 Q3-Q4: Complete operational interoperability tests Independent interoperability testers exercise renewal, emergency withdrawal, multi-node rollout, and failure recovery. Completion criterion: Publish a matrix of product versions, outcomes, limitations, and unresolved blockers. Dependency: End-to-end implementations. 5.3.8. 2027 Q4: Establish commercially supported deployment paths Commercial suppliers document supported products, maintenance commitments, and integration procedures. Completion criterion: Identify at least one purchasable, supported end-to-end path for each claimed deployment model, recording gaps explicitly. Confirm the claim with suppliers, including release Elkins & Ackermann Expires 22 April 2027 [Page 15] Internet-Draft Enterprise Standalone MTC Deployment October 2026 version, support terms, geographic or product limits, and a repeatable installation and renewal procedure. A laboratory endpoint, experimental browser flag, or roadmap is not a commercially supported path. Dependency: Successful interoperability and operational tests. 5.3.9. 2028: Conduct enterprise qualification Enterprise operators conduct procurement, pilot, compliance, scale, and rollback qualification. Completion criterion: Document evidence from staged deployments without presuming universal production readiness. Dependency: 2027 ecosystem-readiness gate. 5.3.10. 2028 Q4: Target staged production deployment Where justified, enterprises target staged public-Web PKI deployment. Completion criterion: Document production rollout evidence and exceptions. Dependency: Enterprise-specific approval and qualification. 5.3.11. Vendor coverage and standards reality check The end-of-2027 ecosystem-readiness target should be evaluated against observed standards progress and actual implementations, not against a schedule that assumes every dependency will be completed on time. 5.3.11.1. TLS Trust Anchor Identifiers: standards and implementation history The first individual Trust Anchor Identifiers draft, draft-beck-tls- trust-anchor-ids-00, was published on 28 June 2024. The first TLS Working Group revision, draft-ietf-tls-trust-anchor-ids-00, was published on 25 February 2025. As of 19 October 2026, the latest numbered revision is draft-ietf-tls-trust-anchor-ids-06, published on 30 September 2026. The document remains an active Internet-Draft, not an RFC. Thus, the work has been underway for more than two years, including roughly twenty months as a Working Group draft. The dates and status are recorded in the IETF Datatracker: Elkins & Ackermann Expires 22 April 2027 [Page 16] Internet-Draft Enterprise Standalone MTC Deployment October 2026 https://datatracker.ietf.org/doc/draft-beck-tls-trust-anchor-ids/ https://datatracker.ietf.org/doc/draft-ietf-tls-trust-anchor-ids/ history/ General-purpose, released support for the complete Trust Anchor IDs extension in OpenSSL or Bouncy Castle has not been verified for this assessment. That is not a finding that neither project has experimental code. Likewise, author affiliation, prototype support, and a packet dissector do not demonstrate interoperable, supported deployments. An implementation inventory must verify client and server support, codepoint handling, certificate selection, recovery, API exposure, and released version numbers directly with maintainers. 5.3.11.2. ACME Profiles: a contrasting implementation history draft-ietf-acme-profiles-00 was published on 5 September 2025. As of 19 October 2026, draft-ietf-acme-profiles-02, dated 28 August 2026, has been submitted to the IESG for publication but is not yet an RFC. Its implementation-status section identifies at least two ACME servers, Boulder and Pebble, and seven ACME clients, including Certbot and Caddy. It also reports production use by Let's Encrypt. This demonstrates that implementations and deployments can precede RFC publication when operators and maintainers commit to the work. https://datatracker.ietf.org/doc/draft-ietf-acme-profiles/ ACME Profiles is a useful comparison for standards and adoption timing, not evidence that existing ACME implementations support standalone MTC issuance, independent certificate lineages, or trust- aware provisioning. Those capabilities require separate verification. 5.3.11.3. Vendor survey and follow-on PLANTS work A comprehensive survey of major browsers, root programs, CAs and MTC operators, ACME and certificate-management systems, TLS libraries, reverse proxies and load balancers, third-party hosting providers, and CDNs has not yet been completed. This work should determine whether and how each product supports standalone MTC and standalone ML-DSA, including current availability, versions, configuration requirements, dependencies, interoperability, and vendor implementation or support plans. Results should distinguish no known support, planned support, experimental or prototype support, tested interoperability, and commercially supported production deployment. The survey should contact maintainers and record verifiable evidence rather than infer support from cryptographic-library capabilities alone. The initial survey, led by the author with input from willing implementers, is targeted for presentation at the March 2027 IETF Elkins & Ackermann Expires 22 April 2027 [Page 17] Internet-Draft Enterprise Standalone MTC Deployment October 2026 meeting and should be documented in a separate follow-on PLANTS implementation and interoperability draft. This is a proposed target, not a commitment by the working group or vendors. A target of two independent implementations in each applicable category is a survey objective, not a claim that such implementations currently exist. 5.3.11.4. Schedule feasibility and alternative deployment path These two standards histories do not support assuming that all MTC, Trust Anchor ID, certificate automation, browser trust, and TLS termination dependencies will be standardized, implemented, integrated, and commercially supported by December 2027. The target remains useful, but is aggressive and carries substantial schedule risk. Quarterly readiness reviews should record verified implementations and unresolved critical-path dependencies, with explicit go/no-go criteria rather than compressing delayed work into the final quarter. Chrome's Post-Quantum HTTPS Authentication Roadmap (February 2026) describes staged adoption without committing to a date for Web-wide readiness. Its Quantum-resistant Root Program testing instructions (October 16, 2026) anticipate production inclusion in the default Chrome Quantum-resistant Root Store in 2027, before this document's 2028 enterprise deployment target. That is a browser/root-program milestone, not evidence that CAs, ACME clients, TLS libraries, proxies, CDNs, and enterprise tooling will be ready together by December 2027. Chrome also reports support for ML-DSA certificates in private PKI beginning with Chrome 150. For the public Web PKI, Chrome's current policy excludes traditional post-quantum X.509 certificates from the Chrome Root Store and instead favors MTC. Chrome has described such X.509 certificates as a possible last resort and reserves the right to revise its policies. This is not an irreversible decision, but neither is it a commitment to accept standalone ML-DSA for the public Web. Private-PKI support therefore cannot be treated as public-Web acceptance. We should investigate a parallel standalone ML-DSA deployment path now, rather than wait to see whether the MTC schedule slips in 2027. It may have a shorter implementation dependency chain because it does not require MTC issuance, cosigning, and proof handling. We need to determine what already works, what remains to be implemented, and what changes browser vendors and root-store operators would require before accepting standalone ML-DSA certificates for public websites. We should not assume that existing private-PKI support solves this problem. A separate PLANTS draft should document the implementation and operational requirements, trust-store policy obstacles, interoperability tests, and a realistic schedule for standalone ML- DSA, alongside the MTC work. This investigation should begin soon enough to inform enterprise deployment decisions for 2028. Elkins & Ackermann Expires 22 April 2027 [Page 18] Internet-Draft Enterprise Standalone MTC Deployment October 2026 Critical-path dependencies include: specification and codepoint stability; client trust-anchor distribution and validation; CA issuance; trust-aware selection and property-list transport; certificate-manager interoperability; operational failure handling; and supported product availability. A working handshake is necessary but not sufficient. If one of these is blocked, record the owner, impact, workaround, and earliest credible completion date. A transition using standalone ML-DSA is not presumed to solve the schedule problem. It requires client algorithm support, acceptable public trust anchors and root-program policy, plus its own issuance, serving, and operational testing. A classical default credential may preserve access without satisfying a particular relying-party or contractual policy. 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 Elkins & Ackermann Expires 22 April 2027 [Page 19] Internet-Draft Enterprise Standalone MTC Deployment October 2026 before being treated as a deployment option. Unlike landmark- 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 Elkins & Ackermann Expires 22 April 2027 [Page 20] Internet-Draft Enterprise Standalone MTC Deployment October 2026 7. Trust-aware selection and certificate-management interfaces Implementation feedback on the initial draft indicates that new interfaces are needed for trust-aware certificate selection. Typical selectors map SNI to a configured set of credentials and then choose by supported algorithm; that is insufficient when a credential is not assumed to be trusted by all clients. Selection may occur in the reverse proxy or inside its TLS library. The required information must reach the actual selection point. An implementation inventory should record, for each server or proxy: * Whether default credentials are configured explicitly per virtual host, selected from a ranked trust-anchor list, or chosen by another model. * Whether a directory of *negotiated-only* credentials can be configured, together with credential properties and references to private keys. * How standalone versus non-standalone credentials are distinguished in the certificate properties; a non-standalone credential must not be mistaken for an independently usable default. * How the client's advertised Trust Anchor IDs, credential property lists, and applicable algorithms reach the selector, including a reverse-proxy to TLS-library boundary where one exists. * How the configured default credential is selected if no compatible negotiated credential is available, and how local security policy constrains that fallback. * How an external certificate manager provisions or removes these credentials without overwriting unrelated configuration. These requirements apply beyond large enterprises: independently maintained ACME clients and web servers are common in smaller deployments too. A follow-on interoperability document could first inventory existing configuration models and knobs, before proposing any common interface behavior. No standardized cross-vendor API is asserted here. Elkins & Ackermann Expires 22 April 2027 [Page 21] Internet-Draft Enterprise Standalone MTC Deployment October 2026 7.1. Client and server trust, and the reverse-proxy boundary The TLS server's selection of its own certificate in response to the client's advertised Trust Anchor IDs is distinct from the server's validation of a client certificate. The ClientHello trust information expresses which server-authentication anchors the client recognizes; it does not itself establish which client-authentication anchors the server accepts. These directions must be documented separately. For example, a public TLS endpoint might hold an ECDSA certificate issued under one public CA and a standalone MTC issued under another. The endpoint must select a credential compatible with the client's advertised trust state and capabilities, or use the configured default subject to local policy. An advertised identifier is not proof that certificate validation will succeed, and the selector must still respect the TLS client's supported signature algorithms and other relevant protocol constraints. Where a reverse proxy terminates TLS, the application behind it ordinarily does not select or validate the browser-facing server certificate. The proxy and TLS library need an interface only to the extent that certificate selection is split across them. Whether the application needs to learn which server credential was presented is a separate operational and application-policy question, not a general MTC requirement. An authenticated proxy-to-application signal might be useful for applications that distinguish authentication assurances, but a client-supplied HTTP header must not be trusted for this purpose. RFC 9440 addresses forwarding client-certificate information; it does not by itself define forwarding of the proxy's selected server identity. Before proposing any analogous mechanism, implementations should establish an actual use case and existing product behavior. An implementation survey should therefore distinguish (1) the client- to-server Trust Anchor ID advertisement, (2) the server's selection and presentation of a compatible credential, (3) the server's independent policy for authenticating clients, if any, and (4) optional communication of the selected server credential to an application behind a trusted proxy. Elkins & Ackermann Expires 22 April 2027 [Page 22] Internet-Draft Enterprise Standalone MTC Deployment October 2026 7.2. Credential selection and deployment security risks Standalone MTC deployment must preserve TLS server authentication and certificate validation. A client's advertised Trust Anchor IDs do not establish trust in other credentials or anchors. Missing or unrecognized IDs must not lead to selection of an unauthorized credential. Where classical certificate fallback is supported, it must respect client capabilities and applicable authentication policy rather than silently bypassing a requirement for post-quantum authentication. Certificate issuance, provisioning, renewal, and withdrawal are security-sensitive operational activities. Compromised management credentials, private keys, or TLS-terminator interfaces could permit unauthorized credentials to be installed or retained. Deployments should authenticate configuration changes, protect management interfaces, and test rollback and emergency withdrawal. Trust Anchor ID recovery must not make a certificate acceptable after validation failed for expiration, revocation, name mismatch, or another validation constraint. Post-quantum authentication does not itself prevent traffic redirection, origin compromise, or session theft. Those threats are distinct from the certificate-authentication migration addressed here. 7.3. Independent orders, atomic updates, and failure recovery Certificate managers must keep separate orders and lineages separate, including those maintained by different ACME clients or provisioned manually. For default orders, selection may need to choose a configured default chain, avoiding non-standalone credentials where inappropriate. Optional alternate credentials must be addable and removable automatically without requiring an operator to track each alternate by hand. A non-standalone credential may have a lifetime independent of its parent order; the lifecycle model must account for this. Configuration updates should be atomic where possible, including the credential and its associated property list. An atomic file rename is one possible implementation technique, not a standardized interface. Tests must also cover failed temporary-file writes, incomplete publication, reverse-proxy state diverging from the manager's state, reload/restart behavior, and concurrent selection while credentials change. Least privilege and configuration ownership matter when independent automation systems touch the same virtual host. Elkins & Ackermann Expires 22 April 2027 [Page 23] Internet-Draft Enterprise Standalone MTC Deployment October 2026 An endpoint may serve browsers and constrained or IoT devices with incompatible trust stores and certificate expectations. Different certificate lineages or managers may be necessary for the same virtual host. Client identification and appropriate credential selection require explicit testing; blindly replacing a shared certificate can disrupt clients that cannot be upgraded. 7.4. Implementation readiness and deployment constraints Implementer feedback indicates that standalone ML-DSA is already supported in some mainline software, but that support in a TLS implementation is not equivalent to usable public-Web authentication. The relying party must support the algorithm, accept an appropriate trust anchor, and validate the certificate under its policy. The absence of a shared acceptable public trust anchor across relevant clients can defeat an otherwise working deployment. At the time of the October 2026 discussion, one implementer reported that Trust Anchor ID work was waiting on the TLS extension codepoint and that MTC implementation was waiting for further specification maturity. These are time-specific reports from one implementation, not a claim about the status of all software. After an issue is unblocked, design, scheduling, implementation, testing, and review still require time. The milestone table therefore separates standards unblocking from shipping interoperable products. Some requirements may be local compliance or contract decisions rather than gaps in the TLS protocol. An endpoint configured to fall back to classical authentication can remain reachable even when the relying party or a particular business relationship requires post- quantum authentication. The document does not presume that TLS 1.3 with hybrid post-quantum key establishment requires post-quantum server certificates to protect recorded traffic against future decryption. The authentication threat and the confidentiality threat must be assessed separately. 7.5. Public and private trust-store boundaries This draft concerns unmanaged clients using the public Web PKI. A private PKI can provision its own trust anchors and may use conventional ML-DSA certificates without requiring MTC. Public browser root-store policies must not be conflated with the capabilities of a browser using an enterprise-installed private root. Even if several root programs accept standalone ML-DSA, there may not be a common accepted trust anchor across all relevant relying parties. This makes a universal ML-DSA fallback unproven. Authentication policy and compliance obligations remain distinct from the confidentiality benefit of hybrid or post-quantum TLS 1.3 key Elkins & Ackermann Expires 22 April 2027 [Page 24] Internet-Draft Enterprise Standalone MTC Deployment October 2026 establishment. 7.6. Additional implementation questions raised in review * Which deployed reverse proxies already support an explicit default credential plus a directory of negotiated-only credentials and key references? Which support ranked default chains? * Is any application-facing indication of the server credential necessary? If so, what use case requires it, and how is it protected against spoofed HTTP headers? * Where is the selection boundary in each product: reverse proxy, TLS library, or both? Which existing APIs expose the ClientHello trust-anchor list and certificate properties? * Which codepoint and specification dependencies remain open, and how much implementation and test time follows their resolution? * How should client-authentication trust configuration be kept separate from client-advertised trust of server credentials? 8. Authentication threat model 8.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. 8.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. Elkins & Ackermann Expires 22 April 2027 [Page 25] Internet-Draft Enterprise Standalone MTC Deployment October 2026 8.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. 8.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. * It does not make identity-provider authentication or MFA disappear; it can, however, expose sessions after login. Elkins & Ackermann Expires 22 April 2027 [Page 26] Internet-Draft Enterprise Standalone MTC Deployment October 2026 +================+=======================+======================+ | 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 9. 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 priorities must also be balanced against applicable government mandates and regulatory requirements, which are especially relevant to the large enterprises and critical-infrastructure operators Elkins & Ackermann Expires 22 April 2027 [Page 27] Internet-Draft Enterprise Standalone MTC Deployment October 2026 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 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 Elkins & Ackermann Expires 22 April 2027 [Page 28] Internet-Draft Enterprise Standalone MTC Deployment October 2026 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. The migration workstreams described here have distinct security boundaries. Edge-to-origin TLS, private PKI, identity-provider flows, session management, and administrative SSH each require their own threat model; adopting MTC for a public website does not complete those other migrations. The arrival date of a cryptographically relevant quantum computer and future attacker capabilities remain uncertain. Planning estimates should not be presented as observed attack frequencies. Elkins & Ackermann Expires 22 April 2027 [Page 29] Internet-Draft Enterprise Standalone MTC Deployment October 2026 10. 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 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. 11. 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. Elkins & Ackermann Expires 22 April 2027 [Page 30] Internet-Draft Enterprise Standalone MTC Deployment October 2026 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. 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. Inventory existing TLS proxy/web-server certificate selection configuration and APIs; exercise negotiated-only credential directories, standalone flags, default selection, and property-list propagation to the actual selection point. Test 11. Use two independent certificate managers for one virtual host; keep orders isolated, mix manual and automated provisioning, add and remove alternates, and test non-standalone credential lifetime independently of its parent order. Test 12. Inject failures into atomic credential/property-list updates, temporary-file writes, reloads, and manager-to-proxy synchronization; verify least privilege, recovery, and rollback. Exercise a browser/IoT shared endpoint with distinct credential needs. Test 13. Distinguish a certificate-selection mismatch from certificate-validation rejection. For a client that trusts an issuer but rejects the presented certificate because it is expired, revoked, has the wrong hostname, or violates a local constraint, observe whether the client suppresses Trust Anchor ID recovery for that same issuer. Separately exercise a recoverable mismatch. Record the triggering alert, retry behavior, advertised IDs, final verification result, and implementation version. This test reflects the guidance merged in TLS Trust Anchor IDs PR #135 on 17 October 2026; check the current Internet-Draft before citing it as published specification text. Test 14. 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. Elkins & Ackermann Expires 22 April 2027 [Page 31] Internet-Draft Enterprise Standalone MTC Deployment October 2026 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 17, 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.1. Additional proxy and application interoperability tests Test 15. With one virtual host and both ECDSA and standalone MTC credentials, test client-advertised trust sets and signature- algorithm constraints independently; verify that the selected server credential matches the configured policy. Keep server validation of client certificates, if enabled, as a separate test. Test 16. Exercise reverse proxies with selection inside the proxy and inside a separate TLS library. Record which component sees Trust Anchor IDs, credential properties, private-key references, and default-chain configuration. Verify that the backend application is not assumed to need server-certificate details. Test 17. Where an application needs the identity of the credential presented by a trusted TLS terminator, test the product's existing trusted signaling and verify that a client-supplied HTTP header cannot spoof it. Do not treat RFC 9440 as an existing server- identity signal. 12. Questions for PLANTS and implementers The preceding sections identify technical and operational requirements for standalone MTC deployment. The remaining questions concern verified implementation support, interoperability, and whether the proposed schedule is achievable. 1. Which TLS libraries, reverse proxies, load balancers, and certificate- management systems currently support standalone MTC, including Trust Anchor ID-based credential selection, provisioning, renewal, and recovery? Which capabilities are missing, and which suppliers have committed to implementing them? Elkins & Ackermann Expires 22 April 2027 [Page 32] Internet-Draft Enterprise Standalone MTC Deployment October 2026 2. What standalone MTC support exists for enterprise-managed TLS termination, third-party hosting, and CDN edge termination? How do these products handle customer-supplied credentials, default and alternate certificate lineages, and the boundary between certificate management and TLS termination? 3. Can PLANTS and interested implementers agree on an interoperability test profile covering Trust Anchor ID negotiation and recovery, credential selection, issuance, renewal, withdrawal, atomic updates, fallback, and operational failure scenarios? Which implementations are available for independent testing? 4. The author proposes to undertake an initial vendor and implementation survey covering both standalone MTC and standalone ML-DSA, with input from interested implementers, and present the results at the March 2027 IETF meeting. The survey will document whether and how products support these mechanisms, current implementation status, dependencies, interoperability limitations, and commercial availability. The findings should be published as a separate follow-on PLANTS draft and updated as implementation work progresses. 5. Is the proposed end-of-2027 MTC ecosystem-readiness target achievable? The date is intended to focus implementation and interoperability work, not to imply commitments by standards bodies or vendors. Progress should be assessed against the quarterly milestones, especially critical dependencies and commercially supported products. If milestones are missed, what are the implications for staged enterprise deployment in 2028, and which alternative approaches should be evaluated? 6. Should PLANTS begin a parallel investigation of standalone ML-DSA for public Web PKI now, rather than wait for MTC deployment delays? The investigation should examine existing implementations, certificate- management requirements, performance, interoperability, browser and root-store policy, and changes required for public-Web acceptance. Chrome currently favors MTC and excludes conventional post-quantum X.509 certificates from its public root store, but has not declared that policy irreversible. A separate draft should evaluate whether standalone ML-DSA offers a credible alternative deployment path. Elkins & Ackermann Expires 22 April 2027 [Page 33] Internet-Draft Enterprise Standalone MTC Deployment October 2026 13. Security Considerations This document describes enterprise deployment considerations for existing and developing TLS authentication mechanisms. It does not define a new protocol, change certificate-validation rules, or modify the security properties of TLS or MTC. Security considerations for those mechanisms are addressed in their respective specifications. The operational risks of credential selection, fallback, certificate management, and recovery are discussed in the deployment sections of this document. 14. IANA Considerations This document requests no IANA actions. 15. Acknowledgements The authors thank Ilari Liusvaara and Michael Richardson for their review comments and technical discussion of Trust Anchor ID signaling, certificate selection, and enterprise deployment considerations. 16. 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. 17. Appendix A. 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. Elkins & Ackermann Expires 22 April 2027 [Page 34] Internet-Draft Enterprise Standalone MTC Deployment October 2026 +=========================+=================+=====================+ | 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 18. Appendix B. Selected TrustAsia Handshake Decodings 18.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 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 Elkins & Ackermann Expires 22 April 2027 [Page 35] Internet-Draft Enterprise Standalone MTC Deployment October 2026 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. Chrome provides instructions for testing its Quantum-resistant Root Program [CHROME-CQRP-TEST]. 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. 18.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. Elkins & Ackermann Expires 22 April 2027 [Page 36] Internet-Draft Enterprise Standalone MTC Deployment October 2026 18.3. ClientHello: requested Trust Anchor IDs 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. Elkins & Ackermann Expires 22 April 2027 [Page 37] Internet-Draft Enterprise Standalone MTC Deployment October 2026 18.4. EncryptedExtensions: available Trust Anchor IDs 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. Elkins & Ackermann Expires 22 April 2027 [Page 38] Internet-Draft Enterprise Standalone MTC Deployment October 2026 18.5. Certificate: standalone MTC and cosigners 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. 19. References 19.1. Normative References [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, . [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, . Elkins & Ackermann Expires 22 April 2027 [Page 39] Internet-Draft Enterprise Standalone MTC Deployment October 2026 19.2. Informative References [TAI-RECOVERY-PR135] "Explicit guidance on untrusted certificates (TLS Trust Anchor IDs PR 135)", n.d., . Merged into repository main on 17 October 2026; verify inclusion in a published Internet-Draft [CHROME-CQRP-TEST] "Chrome Quantum-resistant Root Program - Testing Instructions", 16 October 2026, . [CHROME-CQRP] Google Chrome Root Program, "Chrome Quantum-resistant Root Program Policy, draft v0.3.0", 14 August 2026, . [TRUST-ANCHOR-ID-RDNA] Benjamin, D., "Move id-rdna-trustAnchorID to the Trust Anchor IDs specification", 12 October 2026, . 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, . 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 22 April 2027 [Page 40]