Welcome to mtcs@, and what we hope MTCs will look like in Chrome!
Joe DeBlasio
Hello!
We're excited to see the Merkle Tree Certificate (MTC) ecosystem get off the ground. Since MTCs are a new technology, we think it's important for those looking to implement MTC cosigners, monitors, MTC-enforcing TLS clients, and others to have somewhere to discuss implementation details and operational aspects of building out this new ecosystem.
Given Chrome's accelerated timeframe for building out MTC support, there are a lot of types of conversations that can happen in parallel. As of this writing, MTCs are not yet fully standardized, and spec discussions are likely best directed to the PLANTS and ACME mailing lists. We similarly don't mean this list for communicating Chrome's Quantum-Resistant Root Program Policy -- policy updates will be published online asap, and there will be better venues for feedback there. Instead, we intend this resource for those in the "building" stage of MTCs.
There are many details yet to be worked out, and none of this is finalized, but to provide a preview of the shape of things to come for Chrome...
What MTCs in Chrome will look like
In standalone certificates, Chrome will require a cosignature from the issuing Certification Authority (CA), as well as one additional mirror. That mirror must be operated by a distinct entity from the CA to reduce the risk that a failure of one log operator's infrastructure makes the certificate invisible to monitors. Since CAs are expected to make their issuance logs publicly accessible, this ensures that MTCs offer a similar level of transparency to what Certificate Transparency (CT) offers today while still minimizing overall certificate size. For Chrome's support of landmark-relative certificates, Chrome's servers will similarly ensure issuer logs are mirrored by other entities before identifying landmarks as trusted.
While we're incredibly grateful to the CT log operators of today, it has remained a challenge for years to ensure adequate logging capacity, since there are few incentives to operate a CT log. To address this for MTCs, CAs, at least initially, will be expected to run mirrors usable by all other CAs. Other interested parties are still welcome to run mirrors as well, much as they may run CT logs today.
To ensure monitors, CAs, mirrors and others are all on the same page, Chrome will publish a json containing all of the cosigners (CA and mirroring) that Chrome recognizes, similar to how Chrome publishes its root store and CT log list today. Mirrors will be expected to implement the tlog-mirror specification.
MTCs accepted in Chrome will largely be short-lived, with lifetimes topping out at 47-days, with 7-day certificates strongly encouraged. Chrome's MTC cosigners will all be expected to use ML-DSA. For mirroring cosigners, we will accept only ML-DSA-44. For CA cosigners, we will support ML-DSA-44 and ML-DSA-87. The CA experience will look largely similar to today -- acceptance into the Chrome Quantum-resistant Root Store will apply through the Common CA Database. CAs will be expected to follow the CA/Browser Forum TLS Server Authentication Baseline Requirements, though there will be some necessary departures due to the speed at which we're moving and to minimize policy churn required in subsequent years.
Testing MTCs with Chrome
So as to provide an opportunity for all members of the ecosystem to develop against a realistic live environment, we anticipate building out MTC enforcement in Chrome using testing-only MTC CA trust anchors tentatively starting in July. CA cosigners recognized by Chrome in this stage will never be trusted by Chrome clients by default; individuals who wish to do so will be able to use this environment only after enabling a flag.
Any existing CA or CT log operator who wishes to be included in this validation phase will be welcome. Other than requiring that logs are publicly served and that cosigners and logs use compatible algorithms (i.e. the logs and cosigners look like the "real thing"), we will not be enforcing requirements regarding, e.g., key generation or storage. This environment is just for testing. Chrome may also monitor logs included in this testing phase for log availability and correctness, similar to how Chrome monitors CT logs today. Any issues we identify, we will share with the log's operator to help them correct those problems prior to the full launch of "Phase 2" in early 2027. We do hope that participants will share freely what challenges they encounter and what they learn during this phase so that everyone in the ecosystem can benefit, perhaps by posting to this list.
As mentioned above, none of the details here are yet set in stone, and we'll keep the community updated as dust starts to settle. We hope you'll join us in building out this new ecosystem together. We don't have all the answers yet, but questions are welcome,
-Joe, on behalf of Chrome's MTCs team