the Chromium logo

The Chromium Projects
Chromium > Chromium Security > Post-Quantum HTTPS Authentication Roadmap >

Post-Quantum HTTPS Authentication Roadmap

David Benjamin and Joe DeBlasio, 2026-02-27

This document outlines a roadmap for post-quantum HTTPS server authentication in Chromium, that is, how a TLS connection is authenticated by an HTTPS server’s TLS key, which is in turn associated with the HTTPS server identity by a certificate from a trusted certification authority (CA).

Transitioning to a PQ web will be a long process with many moving parts, and we expect details to evolve over time. As such, this document is not a precise specification but a rough outline that aims to help reason about security and compatibility properties. We divide the transition into four stages:

Stage 1: Add Post-Quantum Options

Chromium is already working to add support for PQ authentication in TLS. This includes PQ-secure CAs with Merkle Tree Certificates and ML-DSA TLS keys.

However, without removing classical options, this does not protect connections from a cryptographically relevant quantum computer (CRQC). An attacker can always target the client’s weakest supported authentication option. Even if, say, https://example.com were to adopt post-quantum authentication, a CRQC can still compromise the key of any trusted classical CA, forge a certificate, and impersonate the site. This attack is possible no matter what CA https://example.com actually uses.

At the end of the transition, when Chromium has removed all classical options, this attack will not be possible. However, such a Chromium would be incompatible with all existing classical servers, so this is only viable when the entire Web is PQ-capable. That will take a long time.

Thus we need intermediate stages that offer downgrade protection: protecting PQ-capable sites that need protection against a CRQC, even while supporting sites that remain on classical keys.

Stage 2: Opt-in Individual Sites

Requiring a post-quantum PKI (see Stage 3 below) achieves downgrade protection but may still take some time due to the changes required to the CA ecosystem. If necessary, we can provide downgrade protection even sooner with an analog to HTTP Strict Transport Security (HSTS).

HSTS defines a Strict-Transport-Security HTTP header which allows HTTPS servers to opt into only being accessed over HTTPS. This works with a combination of client state and a preload list. We could deploy an analogous HTTP Require-Post-Quantum (HRPQ) response header, for example:

Require-Post-Quantum: max-age=31536000; includeSubDomains

When connecting to a Require-Post-Quantum origin, Chromium would not allow classical CAs or classical TLS keys. This would allow sites to opt-in to stronger behavior. This could be deployed in a stateful form (updated in response to HTTP headers), a preload list, or a combination of the two.

As an opt-in mechanism, HRPQ is attractive for compatibility. However, there are risks and complications to both forms of this mechanism:

As more sites become PQ-capable, these risks will only increase. As a result, HRPQ is not a good long-term answer for downgrade protections. Requiring a post-quantum PKI will allow the removal of HRPQ support.

Stage 3: Require a Post-Quantum PKI

There are far fewer CA operators than server operators on the Web. Servers already have to regularly obtain new certificates from their CAs, and TLS server certificate provisioning is increasingly automated with protocols like ACME. Designed right, transitions within just the PKI can complete much quicker.

Suppose we target a Chromium that only accepts PQ CA signatures. That is, a Chromium that:

These clients can both statelessly provide downgrade protection and can reach this state without waiting for every site to become PQ-capable. Sites would transition as follows:

A diagram of the transition described above, using arrows to describe certificates. The first step is a server with only a certificate from a classical CA covering a classical TLS key. This can automatically transition to the second step: one certificate from a classical CA to a classical TLS key and one certificate from a PQ CA to the same classical TLS key. This can manually transition to the third step: one certificate from a classical CA to a classical TLS key and one certificate from a PQ CA to a PQ TLS key. The first two steps are labeled "Servers without a PQ key". The third step is labeled "Servers with a PQ key". The second and third steps are labeled "Compatible with a PQ-CA-only client". There is a legend explaining that certificates (arrows) from PQ CAs are for PQ clients, and the certificates (arrows) from classical CAs are for legacy clients.

While a server can transition directly to the final state (many likely will), it must provision new keys and update their serving software to do so. We cannot hope to automate this at the PKI alone.

However, the intermediate state can be automated. Server software does not need PQ support to serve a PQ certificate—the signature from the CA is broadly opaque to the TLS serving stack. A CA can be updated to issue certificates that are PQ-signed using the server’s existing TLS key, paired with a certificate signed by a traditional CA (how to support this pairing without requiring server-side changes is described below). Clients can then authenticate the most secure signature that they recognize, while ignoring the alternate option.

Once a client has removed all classical CAs, its connections to these PQ-capable servers will be secure against a CRQC. Crucially, the only accepted certificates are those from PQ CAs. An attacker cannot forge a certificate that tricks a client into accepting a classical TLS key for a PQ-capable server.

A diagram showing how this provides compatibility and downgrade protection by comparing the view from classical and PQ-CA-only clients. The top half of the diagram, labeled "What a classical client sees", shows how, in both servers with and without PQ keys, only the classical-CA-to-classical-TLS-key certificates exist to classical clients. The bottom half of the diagram, labeled "What a PQ-CA-only client sees", shows how, only the PQ-CA-issued certificates exist to PQ-CA-only clients. In the server without a PQ key, this client sees the PQ-CA-to-classical-TLS-key certificate. In a server with a PQ key, this client only sees the PQ-CA-to-PQ-TLS-key certificate. The classical-CA-to-classical-TLS-key certificate, and thus the classical TLS key, is invisible.

For servers maintaining both a classical and PQ key, downgrade protection is contingent on the servers ensuring classical TLS keys are not compatible with a PQ-CA-only client. That is if the server has a PQ TLS key, it should only ask the PQ CA to sign its PQ key, not its classical key. Otherwise an attacker can compromise authentication via the classical key. These misconfigurations will be visible via transparency logs.

A diagram showing the above misconfiguration. There are three arrows (certificates): classical CA to classical TLS key, PQ CA to classical TLS key, and PQ CA to PQ TLS key. The classical CA and the first arrow are grayed out, to indicate the view from a PQ-CA-only client. However, both arrows from the PQ CA, and thus the classical TLS key, are visible. This shows that, in this misconfiguration, the PQ-CA-only client accepts and is thus vulnerable to the classical TLS key.

Later sections will discuss how to design this transition so that it can be automated.

Certificate Negotiation

Throughout this transition, servers will need to retain compatibility with legacy clients. Legacy and PQ clients can not trust the same CAs, so every PQ transition unavoidably requires sending different certificates to different clients. TLS solves these kinds of problems with certificate negotiation:

Together, these allow server software to correctly and automatically select the right certificates with the right clients in each of the above configurations.

To provision these certificates in the PQ-incapable case, ACME extensions like ACME Profile Sets can help CAs transparently provision two certificates for the same key. ACME extensions cannot automatically provision the PQ-capable case, but this is unavoidable: to become PQ-capable, a server must first provision a new private key, and update to server software that can load it.

However, some of these capabilities are fairly new, and we need to automatically update servers that do not yet support them. Thus, while certificate negotiation and profile sets will help for the next authentication transition, the automated transition for servers to support classical/PQ-paired certificates will need an additional tool:

Alternate Certificate Issuer

Many existing PQ-incompatible servers, and their ACME pipelines, are only capable of configuring one certificate. We can do this by embedding the post-quantum certificate inside the classical one. Define an X.509 extension, id-alternateCertificateIssuer that describes the issuer-specific differences between the classical certificate and the equivalent post-quantum certificate. Specifically:

A PQ client that recognizes this extension will reconstruct the PQ-CA-to-classical-key certificate and verify it, ignoring the certificate's classical signature. A legacy client will ignore the extension and see an otherwise normal purely classical certificate. The TLS server software will likewise ignore the new extension.

Crucially, this extension only overrides issuer-specific information, not subject information. This is to avoid a situation where the TLS server software inspects the certificate to derive some of its own configuration (e.g. configuring SNI dispatch from subjectAltNames), but then a PQ client uses different information altogether.

A diagram showing two certificates embedded in each other. There are two boxes representing CAs. The box for the PQ CA is inside the box for the classical CA. There are two parallel arrows (certificates) from these boxes to a classical TLS key. One arrow starts from the outer classical CA box. The other starts from the inner PQ CA box. There is a legend indicating that the classical CA box is for legacy clients, and the PQ CA box is for PQ clients.

This transition can be performed automatically, as the TLS server software will simply see a new X.509 extension, which it will ignore.

From the CA side, the issuance process will be:

  1. Issue the PQ-signature-to-classical-key certificate.
  2. Extract the PQ-issuer-specific differences into an id-alternateCertificateIssuer extension.
  3. Issue a classical-to-classical certificate with this extension embedded.

We’ll need to take some care in how we define this extension. X.509 is extensible and does not clearly differentiate subject and issuer fields. We should ensure:

This extension is undesirable for the long-term:

We intend for this to be a purely transitionary mechanism, based on the limitations of existing, older servers. For newer servers, the more principled certificate negotiation approach solves this more efficiently and flexibly.

To enforce this, clients will only implement id-alternateCertificateIssuer when the subjectPublicKeyInfo field is classical. PQ-capable servers have two TLS keys and necessarily can already manage distinct certificate chains, so the extension is unnecessary. This also means that when a PQ-CA-only client migrates to fully PQ-only (Stage 4 below), support for the extension can be removed.

Removing HRPQ

A PQ-CA-only client does not need HRPQ for downgrade protection. Once a client purely supports PQ CAs, it can remove HRPQ, avoiding the associated risks and complications. Clients that were unable to deploy HRPQ, such as more constrained non-browser clients, can instead skip to this stage once the HTTPS server ecosystem is ready.

Stage 4: Require Post-Quantum TLS Keys

Finally, to ensure all HTTPS connections are PQ-secure, clients will eventually transition to a PQ-only state. This means:

This is a far-future stage, and requires all servers to upgrade to a fully PQ-capable configuration to remain compatible with PQ-only clients. To help the client eventually reach this state, we can apply some combination of the following tools to aid sites in transitioning:

As the actual client change at this stage requires the Web ecosystem be fully ready, we expect this to take a very, very long time to complete and provide security benefits. The earlier stages outlined in this document are thus important to achieve post-quantum security before then.