First External Operators Apply to Chrome’s Post-Quantum Certificate Test Program

August 4, 2026 — TrustAsia Technologies has filed what appears to be the first certificate authority application for Chrome’s Merkle Tree Certificate (MTC) test root store. The filing, Chromium Issue 538260165, implements two recently introduced mechanisms from the IETF’s MTC specification: unsigned CA cosigner 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 highlighted the filing on LinkedIn, noting it is the first such application he could locate in the Chromium issue tracker. The bottom line for organizations tracking the post-quantum transition: CAs are now applying to participate in the infrastructure that will deliver post-quantum authentication on the public web. MTC has moved from Google-Cloudflare experiment to a system that other certificate authorities are building against.

TrustAsia, a Shanghai-based certificate authority and one of five independent Certificate Transparency log operators recognized by Chrome, 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.

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 with details expected in July 2026. In June, Let’s Encrypt committed to MTC as its chosen route to post-quantum certificates, with a staging environment targeted for late 2026 and production issuance in 2027.

What the Filing Contains

Two technical details in TrustAsia’s application deserve attention because they show the MTC specification is now mature enough for independent CAs to implement.

Unsigned CA cosigner 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 representing this CA cosigner as an unsigned certificate, using the placeholder signature algorithm defined in RFC 9925.

RFC 9925, authored by David Benjamin at Google and published in February 2026, standardizes a way to create X.509 certificates that carry no cryptographic signature. The standard explicitly addresses the safety concern: any relying party that encounters one of these certificates and does not understand the unsigned format will reject it, preventing accidental trust. TrustAsia’s filing uses this mechanism for its CA cosigner certificates.

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 three parameters about the associated issuance log: the hash algorithm used, the cosigner’s signature algorithm, and the minimum and maximum serial number range. TrustAsia’s filing includes this extension and marks it as critical, which means any standard X.509 implementation that does not understand MTC will reject the certificate rather than misinterpreting it as a conventional CA certificate.

The “critical” designation is a deliberate safety mechanism. During the transition period when MTC and traditional X.509 coexist, a CA certificate that could be confused for a traditional signing CA would be dangerous. The critical marking prevents that confusion at the protocol level.

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. Roughly 1,000 TLS certificates have been enrolled. Every MTC connection is backed by a traditional X.509 certificate as a failsafe. Chrome is shipping preliminary MTC support and has presented initial results at the Real World Cryptography conference.

Phase 2 (targeted Q1 2027): Chrome will 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 will launch the Chrome Quantum-resistant Root Store (CQRS), a separate trust store that supports only MTCs. The CQRS will operate alongside the existing Chrome Root Program during the transition.

TrustAsia’s test root application falls between Phase 1 and Phase 2. It is consistent with the “early testing program” Chrome announced in its Q2 2026 update, suggesting that Chrome is opening a path for CAs to begin test integration before the formal Phase 2 invitations go out.

My Analysis

From Lab to Lineup

When I wrote my analysis of Google’s MTC architecture in April, the only entities with working MTC implementations were Google and Cloudflare. Two months later, Let’s Encrypt committed to MTC as its post-quantum certificate path. Now a third CA, operating from a completely different organizational and geographic context, has filed a concrete test root application implementing the current IETF specification. Three data points in five months.

The pace matters because it addresses one of the central risks I flagged in my earlier analysis: MTC could become a Google-dominated architecture that concentrates power in browser vendors rather than distributing it across the CA ecosystem. Every independent CA that builds against the specification pushes the architecture toward an open standard rather than a proprietary infrastructure play. TrustAsia’s filing is evidence that the IETF PLANTS draft is readable and implementable by organizations outside the Google-Cloudflare collaboration that originated it.

Reading the Technical Signals

Two aspects of TrustAsia’s filing carry information beyond the filing itself.

First, they are using RFC 9925 (unsigned certificates), which was standardized in February 2026. That standard exists specifically because the MTC architecture needed a way to represent CA cosigners in X.509 format without requiring a traditional signature. The fact that TrustAsia’s implementation uses it correctly suggests the standard and the PLANTS draft together provide a coherent implementation path. Prior to this filing, the only evidence of RFC 9925 in practice came from the Google-Cloudflare experiment.

Second, the MTCCertificationAuthority extension is not yet finalized. It is part of a working group draft at the IETF, still several revisions from becoming a proposed standard. TrustAsia is implementing against draft-stage specifications, which means they are betting on the architecture’s trajectory, not waiting for the finish line. For organizations tracking MTC readiness, this signals confidence in the specification’s stability from a CA with operational skin in the game.

The CT Log Qualification Path

Chrome’s decision to open Phase 2 participation to existing CT log operators was not arbitrary. 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 precisely the credential Chrome is selecting for. They were added to Chrome’s CT log list as “Qualified” in 2021 and currently operate multiple yearly CT log shards (including log2026a and log2026b). 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 concrete validation that the pipeline from CT operator to MTC operator works as intended.

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 the browsers are in the process of leaving.

TrustAsia’s filing strengthens the case for that fork call. With Chrome and Cloudflare testing, Let’s Encrypt committed, the IETF PLANTS draft at version 03 and iterating rapidly, and now a third-party CA 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 through ACME (the CA/Browser Forum’s Ballot SC-081v3 is already forcing this with certificate lifetimes dropping to 47 days by March 2029), have an explicit conversation with your certificate authority about its MTC roadmap, and watch the Chrome 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 the leading 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 actively participating in a post-quantum infrastructure program led by Google 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. If MTC is to become the post-quantum authentication mechanism for the global web, it cannot be a club limited to Silicon Valley CAs and European institutions. TrustAsia’s participation, whatever its motivations, tests whether the specification and Chrome’s root program can accommodate that global scope.

What to Watch Next

Three things will tell us whether MTC deployment is tracking to its 2027 production timeline.

Chrome’s early testing program details, promised for July 2026 in the Q2 update, should clarify the process for CAs beyond the Google-Cloudflare experiment. If TrustAsia’s filing was submitted in response to an invitation from that program, it means Chrome is actively recruiting test participants. If TrustAsia filed proactively ahead of a formal invitation, it means CAs are moving faster than the program’s published cadence.

Let’s Encrypt’s staging environment, targeted for late 2026, will be the first large-scale test of MTC issuance. Let’s Encrypt issues a majority of the public web’s certificates. When it begins issuing MTCs even in a staging capacity, the volume of test certificates will jump by orders of magnitude from the current Cloudflare experiment.

The IETF PLANTS draft itself, currently at version 03 (April 2026) 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 significant revisions between versions, and several open questions remain in the text (the authors note a TODO on timestamps in checkpoint signatures). Working group drafts at this stage of iteration typically need 12 to 18 months to reach proposed standard status, which aligns with the Q3 2027 target for the Chrome Quantum-resistant Root Store.

For organizations tracking the post-quantum transition, the pattern to watch is institutional convergence: browser, CA, standards body, and now independent third-party CA all moving in the same direction, on roughly the same timeline. That convergence is what turns a specification into infrastructure. And infrastructure is what sets the deadlines that matter.