Full Report
Posted by Chrome Secure Web and Networking Team Today we're announcing a new program in Chrome to make HTTPS certificates secure against quantum computers. The Internet Engineering Task Force (IETF) recently created a working group, PKI, Logs, And Tree Signatures (“PLANTS”), aiming to address the performance and bandwidth challenges that the increased size of quantum-resistant cryptography introduces into TLS connections requiring Certificate Transparency (CT). We recently shared our call to action to secure quantum computing and have written about challenges introduced by quantum-resistant cryptography and some of the steps we’ve taken to address them in earlier blog posts. To ensure the scalability and efficiency of the ecosystem, Chrome has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. Instead, Chrome, in collaboration with other partners, is developing an evolution of HTTPS certificates based on Merkle Tree Certificates (MTCs), currently in development in the PLANTS working group. MTCs replace the heavy, serialized chain of signatures found in traditional PKI with compact Merkle Tree proofs. In this model, a Certification Authority (CA) signs a single "Tree Head" representing potentially millions of certificates, and the "certificate" sent to the browser is merely a lightweight proof of inclusion in that tree. Why MTCs? MTCs enable the adoption of robust post-quantum algorithms without incurring the massive bandwidth penalty of classical X.509 certificate chains. They also decouple the security strength of the corresponding cryptographic algorithm from the size of the data transmitted to the user. By shrinking the authentication data in a TLS handshake to the absolute minimum, MTCs aim to keep the post-quantum web as fast and seamless as today’s internet, maintaining high performance even as we adopt stronger security. Finally, with MTCs, transparency is a fundamental property of issuance: it is impossible to issue a certificate without including it in a public tree. This means the security properties of today’s CT ecosystem are included by default, and without adding extra overhead to the TLS handshake as CT does today. Chrome’s MTC Propagation Plan Chrome is already experimenting with MTCs with real internet traffic, and we intend to gradually build out our deployment such that MTCs provide a robust quantum-resistant HTTPS available for use throughout the internet. Broadly speaking, our rollout spans three distinct phases. Phase 1 (UNDERWAY): In collaboration with Cloudflare, we are conducting a feasibility study to evaluate the performance and security of TLS connections relying on MTCs. To ensure a seamless and secure experience for Chrome users who might encounter an MTC, every MTC-based connection is backed by a traditional, trusted X.509 certificate during this experiment. This "fail safe" allows us to measure real-world performance gains and verify the reliability of MTC issuance without risking the security or stability of the user's connection. Phase 2 (Q1 2027): Once the core technology is validated, we intend to invite CT Log operators with at least one “usable” log in Chrome before February 1, 2026 to participate in the initial bootstrapping of public MTCs. These organizations have already demonstrated the operational excellence and high-availability infrastructure required to run global security services that underpin TLS connections in Chrome. Since MTC technology shares significant architectural similarities with CT, these operators are uniquely qualified to ensure MTCs are able to get off the ground quickly and successfully. Phase 3 (Q3 2027): Early in Phase 2, we will finalize the requirements for onboarding additional CAs into the new Chrome Quantum-resistant Root Store (CQRS) and corresponding Root Program that only supports MTCs. This will establish a modern, purpose-built trust store specifically designed for the requirements of a post-quantum web. The Chrome Quantum-resistant Root Program will operate alongside our existing Chrome Root Program to ensure a risk-managed transition that maintains the highest levels of security for all users. This phase will also introduce the ability for sites to opt in to downgrade protections, ensuring that sites that only wish to use quantum-resistant certificates can do so. This area is evolving rapidly. As these phases progress, we will continue our active participation in standards bodies such as the IETF and C2SP, ensuring that insights gathered from our efforts flow back towards standards, and that changes in standards are supported by Chrome and the CQRS. Cultivating new practices and policy for a more secure and reliable web We view the adoption of MTCs and a quantum-resistant root store as a critical opportunity to ensure the robustness of the foundation of today’s ecosystem. By designing for the specific demands of a modern, agile, internet, we can accelerate the adoption of post-quantum resilience for all web users. We expect this modern foundation for TLS to evolve beyond current ecosystem norms and emphasize themes of security, simplicity, predictability, transparency and resilience. These properties might be expressed by: Grounding our approach in first principles, prioritizing only elements essential for establishing a secure connection between a server and a client. Utilizing ACME-only workflows to reduce complexity and ensure the cryptographic agility required to respond to future threats across the entire ecosystem. Upgrading to a modern framework for communicating revocation status. This allows for the replacement of legacy CRLs and streamlined requirements to focus only on key compromise events. Exploring “reproducible” Domain Control Validation to create a model where proofs of domain control are publicly and persistently available, empowering any party to independently verify the legitimacy of a validation (i.e., serve as a “DCV Monitor”). Enhancing the CA inclusion model to prioritize proven operational excellence. By establishing a pathway where prospective MTC CA Owners can first demonstrate their reliability as Mirroring Cosigners and DCV Monitors, we ensure that acceptance is based on verified performance and a reliable track record. Evolving the third-party oversight model to prioritize complete, continuous, and externally verifiable monitoring. This shift would focus on ensuring a high standard of transparency and consistency, providing immediate and reliable insights into performance that can replace the function of annual third-party audits. To secure the future of the web, we are dedicating our operational resources to two vital parallel tracks. First, we remain fully committed to supporting our current CA partners in the Chrome Root Store, facilitating root rotations to ensure existing non-quantum-resistant hierarchies remain robust and conformant with the Chrome Root Program Policy. Simultaneously, we are focused on building a secure future by developing and launching the infrastructure required to support MTCs and their default use in Chrome. We also expect to support “traditional” X.509 certificates with quantum-resistant algorithms for use only in private PKIs (i.e., those not included in the Chrome Root Store) later this year. As we execute and refine our work on MTCs, we look forward to sharing a concrete policy framework for a quantum-resistant root store with the community, and are excited to learn and define clear pathways for organizations to operate as Chrome-trusted MTC CAs.
Analysis Summary
# Best Practices: Quantum-Resistant HTTPS Transition using Merkle Tree Certificates (MTCs)
## Overview
These recommendations outline the strategic shift required to secure HTTPS connections against prospective quantum computer attacks by transitioning from traditional X.509 certificate chains to the more bandwidth-efficient Merkle Tree Certificate (MTC) model. The focus is on leveraging MTCs to maintain high performance while adopting post-quantum cryptography and ensuring enhanced transparency by default.
## Key Recommendations
### Immediate Actions (Phase 1 - Underway)
1. **Participate in Feasibility Studies:** If involved in large-scale TLS operations (e.g., CAs, CT Log operators), actively seek collaboration opportunities (like the one with Cloudflare) to test MTC performance and security with real internet traffic.
2. **Maintain Current X.509 Conformance:** Continue to support and ensure existing non-quantum-resistant certificate hierarchies remain robust and fully conformant with the current Chrome Root Program Policy, including facilitating necessary root rotations.
3. **Support Private PKI Transition:** Organizations utilizing their own private PKIs should plan to support "traditional" X.509 certificates containing post-quantum algorithms for internal use, as these will not be included in the public Chrome Root Store.
### Short-term Improvements (Leading up to Q1 2027 - Phase 2)
1. **CT Log Readiness Assessment:** Current Certificate Transparency (CT) Log operators should assess their operational excellence and high-availability infrastructure to ensure they meet the prerequisites to participate in bootstrapping public MTCs by the Q1 2027 deadline (if they have a usable log before Feb 1, 2026).
2. **ACME Workflow Adoption:** Begin exploring or implementing ACME-only workflows, as this framework is expected to be prioritized for reducing complexity and ensuring cryptographic agility within the new ecosystem.
3. **Revocation Status Modernization:** Begin planning to upgrade the mechanism for communicating revocation status, aiming to replace legacy Certificate Revocation Lists (CRLs) and focus requirements strictly on key compromise events.
### Long-term Strategy (Q3 2027 and Beyond - Phase 3)
1. **Prepare for CQRS Onboarding:** Certification Authorities (CAs) intending to issue quantum-resistant certificates issued via MTCs must prepare to meet the finalized requirements for onboarding into the new **Chrome Quantum-resistant Root Store (CQRS)**.
2. **Demonstrate Reliability via MTC Roles:** Prospective MTC CA Owners should plan to first establish reliability by operating as **Mirroring Cosigners** and **Domain Control Validation (DCV) Monitors** before applying for main CA inclusion.
3. **Implement Reproducible DCV:** Establish internal mechanisms to support or utilize **"reproducible" Domain Control Validation**, allowing for public and persistent availability of DCV proofs to enable independent verification of domain ownership legitimacy.
4. **Adopt Continuous External Monitoring:** Plan for a shift in third-party oversight from scheduled annual audits to models emphasizing **complete, continuous, and externally verifiable monitoring** of operational performance and transparency.
## Implementation Guidance
### For Small Organizations (Primarily Certificate Consumers)
- **Monitor Browser Updates:** Remain vigilant for updates regarding the MTC propagation plan, as the transition will eventually impact how certificates are validated in Chrome.
- **Prioritize Post-Quantum Readiness:** While full MTC adoption may be later, ensure current TLS infrastructure supports cryptographic agility to easily swap out algorithms when post-quantum candidates become finalized or mandated.
### For Medium Organizations (Organizations owning high-profile public websites)
- **Engage with Current CAs:** Discuss your strategy with existing Certificate Authorities to understand their timeline for supporting MTCs and post-quantum algorithms within their issuance processes.
- **Audit Transparency Compliance:** Ensure all existing certificate issuance and validation processes strictly adhere to modern Certificate Transparency (CT) requirements, as MTC transparency requirements are built upon this foundation.
### For Large Enterprises (CAs, CT Log Operators, Major Infrastructure Providers)
- **Active Standards Participation:** Dedicate resources to participate or monitor IETF PLANTS working group activities to shape or adapt to evolving MTC and quantum-resistant standards.
- **Infrastructure Investment:** Allocate budget and engineering focus toward deploying high-availability infrastructure suitable for operating public MTC infrastructure (e.g., MTC Tree Head signing services, Mirroring Cosigning services).
- **Develop CQRS Strategy:** Begin drafting policies and technical architectures for supporting a dual environment (legacy Chrome Root Store and new CQRS) during the transition period.
- **Opt-In Planning:** Prepare technical infrastructure to support server-side configuration allowing clients to **opt-in to downgrade protections**, enabling the use of only quantum-resistant certificates where desirable.
## Configuration Examples
*No specific technical configuration commands or syntax were provided in the source text for MTCs or new revocation frameworks. The guidance is process-oriented.*
## Compliance Alignment
* **IETF PLANTS Working Group:** Direct alignment with emerging standards developed within this group (e.g., Merkle Tree Certificates draft).
* **Certificate Transparency (CT):** The MTC model fundamentally incorporates and evolves the security properties of existing CT ecosystems.
* **NIST PQC:** Organizations must align their post-quantum algorithm choices with selections vetted by NIST’s Post-Quantum Cryptography project.
* **Chrome Root Program / CQRS:** Future compliance will be defined by the requirements set for inclusion in the new Chrome Quantum-resistant Root Store (CQRS).
## Common Pitfalls to Avoid
- **Ignoring Bandwidth Overhead:** Do not assume generic post-quantum cryptography implementation will work without addressing the massive bandwidth penalties associated with traditional, bulky X.509 chains; MTCs are necessary for scalable public adoption.
- **Assuming Immediate Deprecation of X.509:** Continuing to rely solely on traditional X.509 until the final phase may result in missing key transition deadlines; the dual-track approach requires managing both legacy and MTC infrastructure.
- **Underestimating Transparency Requirements:** Assume that moving to MTCs implies default, mandatory public transparency for all issued certificates; this removes the option of non-transparent issuance found in some legacy models.
## Resources
- Internet Engineering Task Force (IETF) PLANTS Working Group Documentation (Search for Merkle Tree Certificates draft)
- Chrome Root Store Documentation
- Certificate Transparency Official Website
- NIST Post-Quantum Cryptography Project Information (For algorithm guidance)