Chrome MTC Testing and Validation Trust Store
Chris Clements
As announced in February 2026, Chrome will not add traditional X.509 certificates containing post-quantum cryptography to its root store. Instead, Chrome will rely on Merkle Tree Certificates to mitigate the impact of PQ key and signature size increases while integrating transparency directly into the issuance process.
To support development and interoperability with Chrome, we will provide a mechanism to submit non-production cosigners for inclusion in Chrome to be used for general testing and validation. Applications will open in July 2026, and will be open to any organization currently operating either traditional roots CAs or CT logs included in Chrome.
This message aims to provide some clarity on the test and validation trust store.
What is Chrome providing for testing?
We plan to offer a dedicated MTC root store explicitly for the purposes of end-to-end testing and validation. This test root store will be delivered to Chrome clients, but not trusted for production use. Instead, Chrome clients can be individually configured to enable trust of MTCs from these specific test issuers. Chrome M151 is expected to have support for testing Standalone and Landmark-relative MTCs.
Additionally, Chrome will monitor the logs included in this testing phase for availability and correctness, similar to how it currently monitors CT logs.
How do I request access to testing and when will that access be provided?
We’ll send another message to mt...@chromium.org once we’re actually ready to receive test Operator submissions.
Once announced, you’ll need to file a bug in the Chromium Issue Tracker and can expect to include the following information:
The name of your operating organization and the best technical contact email(s) for the team managing these test endpoints.
For your Mirroring Cosigner, a publicly accessible and stable URL to a JSON object containing:
the submission and monitoring URL prefixes, as defined by the tlog-mirror specification,
the cosigner's public key, provided as a DER-encoded ASN.1 SubjectPublicKeyInfo structure, base64-encoded, and
the cosigner ID that uniquely identifies the cosigner, as a trust anchor ID in dotted decimal ASCII format without a "1.3.6.1.4.1." OID prefix.
For your CA Cosigner, a publicly accessible and stable URL to a JSON object containing:
a URL prefix, as defined by the tlog-tiles specification,
a base-64 encoded MTC CA Cosigning Certificate conforming to the MTC CA Certificate Profile defined in the latest MTC specification, and
a description of intended issuance for certificates with a maximum validity of up to 7 days or 47 days.
Chrome will aim to include these cosigner keys in the test root store within two weeks of receiving a complete request and will communicate with the test Operator once the root store has been updated.
How do I enable the testing root store in Chrome?
We’ll provide a follow-up message with the specific experimental feature flags and steps needed to confirm a successful post-quantum MTC connection as soon as available.
Are constraints such as certificate lifetimes and algorithms strictly enforced in testing?
Yes. Testing certificates will be subject to the same validation logic as production certificates. This includes restrictions to 7-day or 47-day maximum validity. For both Mirroring and CA Cosigners, we will accept only ML-DSA-44 (OID: 2.16.840.1.101.3.4.3.17) (RFC 9881) cosigning keys. There is no equivalent key restriction on the test Subscriber certificates.
Though not technically enforced by the client, practices such as the use of strict domain control validation or the use of Hardware Security Modules, are encouraged to maximize the value of this testing infrastructure.
Am I required to run a mirror during the testing phase?
Yes. As Chrome will be enforcing realistic cosigner requirements (e.g., requiring mirroring cosignatures on Standalone certificates), we ask that participants in the testing phase contribute a Mirroring Cosigner usable by all CA Cosigners to ensure adequate and realistic mirroring capacity is available.
The CA Cosigner issuance log should implement the API endpoints, cryptographic formats, and Merkle Tree structures defined in the MTC specification (specifically draft-ietf-plants-merkle-tree-certs-04) and the tlog-tiles specification. The Mirroring Cosigner should implement the API endpoints, cryptographic formats, and validation logic defined in the MTC specification and the tlog-mirror specification.
How many cosignatures are required for Chrome to validate my test certificate?
Chrome clients will enforce the same cosignature requirements to validate a certificate in the testing phase as with production certificates. Standalone certificates must have at least two cosignatures. One must be from the MTC CA Operator, and one must be from a Mirroring Cosigner recognized by the Chrome test root store. Chrome's servers will similarly ensure that issuer logs are mirrored before trusting subtrees for Landmark-relative certificates.
What exactly might Chrome monitor for “availability and correctness”?
Chrome’s compliance monitoring infrastructure will continuously query both the test MTC CA issuance logs and Mirroring Cosigner endpoints throughout their lifetime. The monitoring will focus on uptime metrics, cryptographic integrity, and adherence to technical specifications, intending to be a feedback loop for MTC CA Operators from Chrome.
Development on Chrome's monitoring infrastructure is ongoing, but Operators can expect that Chrome will monitor for availability and uptime by looking for:
Endpoints (both issuance logs and mirrors) maintaining at least 99% uptime over a 30-day rolling window (no more than 7.2 hours of downtime per month).
Endpoints not experiencing a daily uptime below 99.9% for more than 3 consecutive days.
A majority of mirror checkpoints remaining within a few minutes of the current issuer checkpoint.
Operators should also expect that Chrome monitors will verify that:
API endpoints, cryptographic formats, and validation logic all match the definitions in the MTC specification, as well as the tlog-tiles (for CAs) and tlog-mirror (for mirrors) specifications,
merkle trees served cryptographically validate,
mirrors provide consistent, append-only views of mirrored logs, and that
log entries remain available for at least 14 days after the corresponding certificate's validity period ends.
Chrome may send notifications to the Operator when availability and correctness failures are observed. During the testing phase, these notifications are purely to support Operators in developing robust implementations -- we encourage (but do not require) sharing postmortems and development challenges or milestones to mt...@chromium.org so that everyone can benefit from lessons learned.
Where should I share my findings and feedback?
Please share your implementation experiences and challenges on mt...@chromium.org! The hope is that everyone in the ecosystem can benefit from these learnings.
What happens to my test setup when Phase 2 (production inclusion in the default Chrome Quantum-resistant Root Store) launches in 2027?
The test setup can persist at the MTC CA Operators' discretion. We will maintain Chrome's testing infrastructure until Chrome accepts the first Phase 3 eligible MTC CA Operators.
Notably, cosigner keys accepted as part of the testing trust store will not be accepted for production use in Chrome. MTC CA Operators will need to generate new cosigner keys and fully adhere to the CQRP Policy to be included in Phase 2 or later launches.
—
We’ll follow-up with the Chrome flags for experimentation and announcing when we’re accepting testing submissions, but please feel free to ask other questions related to the Chrome MTC test and validation root store. We’ll keep a running list of this FAQ in this doc.
-Chris, on behalf of Chrome's MTCs team