First External Operators Apply to Chrome’s Post-Quantum Certificate Test Program
Table of Contents
August 4, 2026 — TrustAsia Technologies has opened what appears to be the first publicly visible certificate authority application for Chrome’s Merkle Tree Certificate (MTC) test-operator program. Chromium Issue 538260165, titled “Test MTC CA Operator: [TrustAsia]” and filed on July 24, uses one finalized IETF standard and one draft-stage mechanism: unsigned CA trust-anchor certificates per RFC 9925, and the critical MTCCertificationAuthority extension defined in Section 5.5 of the PLANTS working group draft.
PKI standards expert Corey Bonnell identified the filing publicly, describing it as the first such application he could locate in the Chromium issue tracker. A Geomys test-operator issue followed on July 31. The bottom line for organizations tracking the post-quantum transition: CAs and infrastructure operators are now filing to participate in the test program that Chrome is building toward its quantum-resistant root store. MTC is crossing from specification and isolated experimentation into multi-party test-root onboarding.
TrustAsia, a Shanghai-based certificate authority and established Certificate Transparency log operator in Chrome’s CT program, has operated Chrome-qualified CT logs since 2021. That history matters because Chrome’s Phase 2 MTC rollout, targeted for Q1 2027, specifically invites CT log operators with at least one “usable” log in Chrome before February 1, 2026. TrustAsia’s current log2026a and log2026b shards both carry usable status, clearing that threshold comfortably.
The filing lands during a period of accelerating MTC activity. Chrome’s Q2 2026 security update reported that the team ran a proof-of-concept experiment with Cloudflare, began circulating a draft MTC CA policy for feedback, and announced an early testing program. In June, Let’s Encrypt committed to MTC as its chosen route to post-quantum certificates, targeting a staging environment in late 2026 and a production-ready environment in 2027.
What the Filing Contains
Two technical details in TrustAsia’s application deserve attention because they show the MTC specification has progressed to the point where independent CAs can build working test artifacts against it.
Unsigned CA trust-anchor certificates. In the MTC architecture, a CA does not sign individual certificates in the traditional X.509 sense. Instead, it certifies entries by adding them to an issuance log and cosigning subtrees of the Merkle tree. The CA’s identity is represented as a “cosigner” whose role is to attest that it validated every entry in the subtrees it signs. Section 5.5 of the IETF PLANTS draft recommends that when this CA cosigner certificate is used to represent a trust anchor, it take the unsigned form defined in RFC 9925. According to Bonnell, TrustAsia’s filing uses this approach.
RFC 9925, authored by David Benjamin at Google and published in February 2026, defines an unsigned X.509 profile for contexts where the certificate serves as a container for subject or trust-anchor information rather than an issuer-signed edge in a certification path. MTC is one of the architectures that benefits from this profile. Conventional path validators must reject the placeholder signature algorithm as a certification-path signature, preventing an MTC CA certificate from being silently processed as an ordinary intermediate by implementations that do not understand MTC.
The MTCCertificationAuthority critical extension. The PLANTS draft defines a new X.509 extension, id-pe-mtcCertificationAuthority, that marks a certificate’s subject as an MTC-issuing CA. The extension carries four fields about the associated issuance log: the log hash algorithm, the cosigner’s signature algorithm, and separate minimum and maximum serial number bounds. The extension’s final OID remains designated as TBD in the draft, with early implementations using an experimental private-enterprise OID. TrustAsia’s filing includes this extension and marks it as critical. Marking the extension critical prevents a conventional certification-path validator from silently processing the certificate as an ordinary intermediate when it does not understand MTC semantics.
The distinction in standards status between these two mechanisms matters. RFC 9925 is a finalized IETF Standards Track document. The MTCCertificationAuthority extension remains part of an active working-group Internet-Draft, currently at version 05 (published July 6, 2026). TrustAsia is building test artifacts against a specification that is still under active revision, which is evidence of implementation interest and confidence in the architecture’s direction of travel, though not that the specification has stabilized. Version 05 includes material changes from earlier revisions, including reworked relationships between CAs and cosigners and an altered Merkle tree structure.
Where This Sits in Chrome’s MTC Rollout
Chrome’s three-phase MTC deployment plan, announced in February 2026, provides the context for TrustAsia’s filing:
Phase 1 (underway since early 2026): Chrome and Cloudflare are conducting a live feasibility study. Cloudflare operates as a “mock MTCA,” re-encoding existing certificates from trusted CAs as MTCs and publishing them in a tiled transparency log. Approximately 1,000 Cloudflare-proxied domains are participating in the experiment. Every MTC connection is backed by a traditional X.509 certificate as a failsafe, and the experiment currently uses classical signatures. Chrome has shipped preliminary MTC support and presented initial results at the Real World Cryptography conference.
Phase 2 (targeted Q1 2027): Chrome plans to invite CT log operators with established track records to bootstrap public MTC infrastructure. TrustAsia’s filing positions it for this phase. The requirement of a “usable” log before February 2026 narrows the eligible pool to organizations with demonstrated operational reliability in running global, high-availability security infrastructure.
Phase 3 (targeted Q3 2027): Chrome plans to launch the Chrome Quantum-resistant Root Store (CQRS), a separate trust store that would support only MTCs. The CQRS would operate alongside the existing Chrome Root Program during the transition.
TrustAsia’s test-operator application and the Geomys filing a week later are consistent with Chrome’s announced early testing program, though the publicly visible issues do not by themselves establish whether these organizations filed proactively or in response to a private invitation. Either way, they provide the first publicly visible evidence that Chrome’s intended operator-onboarding path is being used.
My Analysis
Beyond the Original Collaboration
When I published my analysis of Google’s MTC architecture on February 28, Chrome and Cloudflare were running the only publicly documented live-browser experiment. DigiCert released an open-source MTC Playground on March 6, implementing a runnable MTC system against an earlier draft version. Three months later, Let’s Encrypt announced its MTC roadmap. Now TrustAsia and Geomys have filed test-operator issues against Chrome’s tracker.
The important pattern is not the count of individual actors but the widening range of participants: browser vendor, CDN, commercial CAs, a nonprofit CA, and specialist infrastructure operators, building against the same architecture from different organizational contexts and geographies. That breadth reduces one of the central risks I flagged in my February analysis: that MTC could become a proprietary infrastructure play rather than an open standard. Independent CAs building against the specification push the architecture toward openness, though it is worth noting that Chrome would still define CQRS admission policy and decide which roots its users trust. The governance concentration question has not been resolved by independent implementation.
Reading the Technical Signals
TrustAsia is building test artifacts against a specification that remains under active IETF revision. Version 05 of the PLANTS draft, published on July 6, introduced material changes from the earlier versions. This is normal for a working-group draft at this stage, but it means that implementations built today may need rework as the specification continues to evolve.
What the filing demonstrates is that the RFC 9925 unsigned certificate profile and the PLANTS draft’s CA representation mechanism together provide a coherent enough implementation path for organizations outside the original Google-Cloudflare collaboration to produce working artifacts. Prior to DigiCert’s Playground in March, the only evidence of independent implementation was absent. Now multiple organizations have built test systems.
The CT Log Qualification Path
Chrome’s decision to open Phase 2 participation to existing CT log operators was deliberate. Running a Certificate Transparency log at Chrome’s quality bar requires sustained uptime, cryptographic integrity guarantees, and the ability to handle global-scale query loads. That operational profile maps directly onto what MTC issuance log operators will need: append-only data structures, high-availability serving, and compliance monitoring.
TrustAsia’s CT log history is the credential Chrome is selecting for. Their logs were qualified in Chrome in 2021, and their current yearly shards carry usable status. The architectural overlap between CT logs and MTC issuance logs was a deliberate design choice by the MTC authors, and TrustAsia’s application is the first publicly visible evidence that Chrome’s intended CT-operator recruitment path is being used.
What MTC Progress Means for PQC Migration Planning
I have written extensively about the fork in the web PKI that MTC represents. In Quantum Ready, Chapter 16 lays out the planning implications: public-facing web infrastructure should track the MTC world; private PKI should proceed with X.509 and post-quantum algorithms, waiting for nothing. The trap runs both directions. An organization that delays its private PKI “until MTC settles” is waiting for a bus that does not stop at its station. An organization that engineers its public estate as simply bigger X.509 is building for a web that Chrome is constructing a separate MTC-based path to replace.
TrustAsia’s filing, alongside the Geomys filing and DigiCert’s earlier Playground work, strengthens the case for that fork call. With Chrome and Cloudflare testing, Let’s Encrypt committed, the IETF PLANTS draft iterating rapidly through five working-group versions, and independent operators now filing test-root applications, the question for enterprise PQC migration planners has shifted. Six months ago, MTC was a plausible direction with institutional backing. Today it is an active construction project with multiple independent participants building against the same specification.
The practical action item has not changed: automate your public certificate lifecycle, preferably through ACME. The CA/Browser Forum’s Ballot SC-081v3 does not mandate ACME, but the reduction to 47-day maximum certificate lifetimes by March 2029 makes dependable lifecycle automation operationally unavoidable at scale. Chrome is separately considering ACME-only workflows for its future MTC root program. Have an explicit conversation with your certificate authority about its MTC roadmap, and watch Chrome’s CQRS timeline. These are no-regrets moves that pay off whether MTC arrives on schedule or slips.
A Note on TrustAsia’s Geography
TrustAsia Technologies is based in Shanghai and is a major SSL certificate issuing company in China. It was included in the Chrome Root Store in mid-2025 after a public discussion and CCADB review process. A Chinese CA seeking participation in a post-quantum infrastructure program anchored by Chrome is worth noting for the geopolitical context it provides, though the technical merits of the filing stand on their own regardless of the applicant’s headquarters.
The MTC specification is an open IETF standard-in-progress. Its value depends on broad CA participation across geographies and organizational types. TrustAsia’s application is a useful test of whether Chrome’s emerging MTC onboarding process can attract geographically diverse operators. Whether that diversity extends to actual admission and governance will depend on how Chrome defines and applies the CQRS policy.
What to Watch Next
Three developments will indicate whether MTC deployment is tracking toward Chrome’s 2027 targets.
Chrome’s early testing program should produce public documentation clarifying the onboarding process for CAs beyond the Google-Cloudflare experiment. If TrustAsia and Geomys are the leading edge of a broader wave of test-operator applications, the MTC ecosystem is developing faster than the published phase timeline suggests.
Let’s Encrypt’s staging environment, targeted for late 2026, will be the first large-scale test of MTC issuance by a CA with production-volume operational experience.
The IETF PLANTS draft itself, currently at version 05 and authored by David Benjamin (Google), Devon O’Brien (Apple), Bas Westerbaan and Luke Valenta (Cloudflare), and Filippo Valsorda (Geomys), will need to stabilize before production deployment. The change log shows material revisions between versions, including reworked CA representation, altered Merkle tree structures, and evolving ACME integration.
For organizations tracking the post-quantum transition, the pattern to watch is institutional convergence: browser, CDN, standards body, commercial CAs, and now independent infrastructure operators all moving in the same direction. That convergence is what turns a specification into infrastructure. And infrastructure is what sets the deadlines that matter.
The post First External Operators Apply to Chrome’s Post-Quantum Certificate Test Program appeared first on PostQuantum - Quantum Computing, Quantum Security, PQC.
点赞
收藏
点踩
分享