SC-106: Enable Post-Quantum Cryptography (PQ) Key Pairs in TLS Server Certificates

[slghtr-says]

Summary

This ballot adds ML-DSA (FIPS 204) as a permitted key and signature algorithm in publicly-trusted TLS server certificates, including ML-DSA-signed CA certificates, CRLs, and OCSP responses, enabling the certificate ecosystem to begin migrating to post-quantum authentication. Passing this ballot does not compel any Root Store Operator to accept ML-DSA. Whether ML-DSA certificates are trusted within a root program's hierarchy remains governed entirely by that program's own policy, and those policies today restrict keys to RSA and ECDSA. Passing this ballot also does not change the signature algorithm used in the Signed Certificate Timestamps embedded in these certificates as that remains in the control of Certificate Transparency log operators. Many Relying Parties validate server certificates through system and library trust stores and have no practical path to post-quantum authentication within the existing X.509 public trust infrastructure. These include SDK-based service clients, embedded and IoT systems, enterprise middleware, and applications that authenticate against system trust stores managed by operating system vendors. This profile must exist at the CA/B Forum level before CAs can issue these certificates and Root Store Operators can decide to trust them.

Policy Rationale

Why not permit mixed classical and post-quantum chains?

ML-DSA exists to provide authentication that remains sound once a cryptographically relevant quantum computer exists. That guarantee holds only if every signature on the path to a certificate is itself post-quantum. A classical link anywhere in the chain, including a classical certificate that cross-signs an ML-DSA CA, leaves the authentication of everything beneath it only as strong as that classical signature, which a quantum adversary can forge. Requiring ML-DSA certificates to chain to ML-DSA issuers ensures that a chain presented as post-quantum provides post-quantum authentication end to end, and does not quietly reduce to classical strength at a cross-signature or a classical issuer.

The same rule has a practical effect on Certificate Transparency as well. ML-DSA public keys and signatures are much larger than their classical counterparts, and logs accept submissions by root rather than by algorithm, so a log serving a classical root cannot decline the ML-DSA certificates issued beneath it. By keeping ML-DSA out from under classical roots, the rule leaves the decision whether to carry these larger payloads with root programs and Certificate Transparency programs rather than settling it in the certificate profile.

[bwesterb]

Have you thought about the migration and the downgrade protection while we're halfway? It's essential to have a PQ secure signal that a server doesn't support PQ leafs yet. A straightforward implementation of that is a mixed chain, although it might be better to hide the PQ signature on the classical leaf in an extension. I can highly recommend this presentation.

[csosto-pk]

Have you thought about the migration and the downgrade protection while we're halfway? It's essential to have a PQ secure signal that a server doesn't support PQ leafs yet. A straightforward implementation of that is a mixed chain, although it might be better to hide the PQ signature on the classical leaf in an extension. I can highly recommend this presentation.

Yes, the migration and downgrade protection will be interesting, but I think these issues are more straightforward for the use-cases that this ballot is focusing on (non WebPKI). And it's unlikely these certs will burden CT much even if CT logs logged them, because there won't be gazillions of them issued by LE.

Cross-signing leaves or chains is a decent option, but recent investigations have shown we need to tighten up the Root signalling and the chain picking logic in common TLS implementations (OpenSSL (nginx etc), BoringSSL, s2n) anyway to make it work. Regarding downgrades, I think this is similar to WebPKI's challenges; no perfect solution. Personally, I am not sure adding a PQ sig in a classical cert as a signal is worth the burden to legacy clients. Dynamic caching and maybe a static list are more compelling for these non-WebPKI use cases. Regardless, I don't think it is important to address all of these technical details in the ballot.

[BenWilson-Mozilla]

Provisions that restrict ML-DSA to “pure” post-quantum chains (e.g. “If used within a Certificate or Precertificate, such as the signatureAlgorithm field of a Certificate or the signature field of a TBSCertificate, the CA SHALL NOT use these signature algorithms unless the algorithm identifier of the public key being certified is one of id-ml-dsa-44, id-ml-dsa-65, or id-ml-dsa-87”) should be removed.

The security of a certificate path depends on the path constructed and accepted by the relying party. A client requiring post-quantum authentication can require and validate an entirely post-quantum path while disregarding classical alternatives. Conversely, a client that accepts a classical path obtains only classical assurance, but the availability of that path does not weaken the separate post-quantum path.

Mixed chains also have legitimate transition and deployment uses. For example, under the proposed “Turducken” approach to post-quantum downgrade resistance, an issuing CA could use its ML-DSA signing key to sign an end-entity X.509 certificate whose subjectPublicKeyInfo contains a classical TLS authentication key. A newly created post-quantum root could also be cross-signed by an existing classical root, allowing clients that support post-quantum signatures—but do not yet have the new root in their trust stores—to construct a compatible path. Such a path would not itself provide end-to-end post-quantum assurance, but its existence would not diminish the assurance provided by a separate, entirely post-quantum path.

The concerns about payload size and the scope of certificates that Certificate Transparency logs may be required to accept may warrant operational or policy controls, but they do not appear to justify prohibiting mixed chains in the Baseline Requirements. Furthermore, Root Store Operators, CT programs, and relying parties can decide which roots, algorithms, paths, and certificate profiles they are prepared to accept.

Accordingly, I suggest that restrictions requiring pure ML-DSA chains be removed so that Root Store Operators, relying parties, and others can establish their own applicable trust and path-validation policies.

[csosto-pk]

@BenWilson-Mozilla , I feel this is a reasonable point. Some common server-side TLS implementations would not pick the proper Turducken leaf cert to send back to the client as they are today, and arguably the advantage of the proposed Turducken approach is that the server TLS code does not need to immediately get updated. So, the benefit of Turducken appears to be questionable at least where these implementations are deployed, but a A cross-signed ML-DSA Root could have a use like RSA cross-signed ECDSA Roots a decade+ ago.

If the concerns about payload size and the scope of certificates that CT logs have to accept can be addressed by operational or policy controls indeed, I think it makes sense to drop the requirement for pure ML-DSA chains.

[ Update: Crossed out references to Turducken certs and complications with current TLS stacks as I had misunderstood Turducken as two separate leaves although they were a classical cert encompassing PQ sig and CA in optional extensions or SCTs. ]

[ChristopherRC]

First, thank you to the authors and proposers for the effort and work invested in drafting this latest proposal and iterating on the preamble. Navigating PQ migration across diverse stakeholders is complex.

We recognize the desire to establish standards for ML-DSA in the TLS BRs. We are also worried about its potential impact on the web, specifically regarding the scalability and operational sustainability of the CT ecosystem - and the risk of fracturing the broader post-quantum migration for secure connections on the internet.

We agree with @BenWilson-Mozilla, and also have a few concerns with the proposal as written. We'd also like to address some possible sources of confusion regarding downgrade protection and CT concerns. There are two different directions of mixed chains. A classical CA might sign a PQ EE key (forbidden in 7.1.3.1.3), or a PQ CA might sign a classical EE key (forbidden in 7.1.3.2.3).

• The first (classical signs PQ) carries risk to CT, as it introduces ML-DSA EE keys to an existing classical PKI. CT logs may be exposed to much larger certificates, without the benefit of the scalability improvements made in Merkle Tree Certificates. It also serves no security purpose, as the attacker will simply target the more powerful CA key. The restrictions in 7.1.3.2.3 make sense.

• The second (PQ signs classical) are the ones that have a legitimate use for downgrade protection in a transition. This document and the later presentation at IETF 126 discusses this in detail. While we do not plan to support this particular PQ CA construction in Chrome (Merkle Tree Certificates are much more suitable for a PKI with CT), these downgrade protection considerations are broadly applicable. We agree with @BenWilson-Mozilla and @bwesterb here and think this second provision in 7.1.3.2.3 should be removed.

This brings us to questions of the SCWG's scope. The BRs defined by the SCWG represent the minimum collective set of requirements established by and for Certificate Consumers. As reaffirmed in our discussions during CABF F2F 64 in Tokyo:

• The SCWG Charter explicitly defines Certificate Consumers as producers of software intended for "browsing the Web securely."
• The charter defines Certificate Issuers from the perspective of issuing certificates that are "...treated as valid when using a browser created by a Certificate Consumer Member."

A central goal of the SCWG has been to prevent non-browser and private PKI use cases from encumbering the web's agility and security posture. For a browser, we don’t see this PQ CA construction as viable due to constraints from message size, CT logging, and CT enforcement. Having said that, we also recognize that non-browser RPs, like those mentioned in the ballot, may have significantly different constraints. But these uses thus far have been explicitly out of scope for the SCWG, misaligning with our charter mandate.

Now, in trying to navigate toward a viable solution, recognizing that non-web use cases are seeking workable standards for their unique situations, and recognizing that similar needs have surfaced repeatedly over the years maybe now is the time to actively consider an additional WG within the CA/Browser Forum tailored specifically for Certificate Consumers outside the scope of web browsers. Should a new WG be created, Chrome obviously wouldn’t need to participate but we’re happy to help progress things forward in whatever shape makes the most sense.

It is also unclear to us what is currently blocked on this ballot. Root Programs are already free to define their policies. Between active ML-DSA pilot programs operating successfully (e.g., Microsoft's recent PQC pilot announcement) and live browser testing for size-optimized architectures like Merkle Tree Certificates in Chrome, the industry already has some viable avenues to test and innovate without modifying the TLS BRs today. Browsers are still experimenting with what structures are appropriate to keep the web safe. Modifying the TLS BRs now risks enshrining constraints (akin to those in the mixed hierarchy discussion above) that can harm the transition before we collectively understand what constraints are appropriate.

Rather than continuing to push this proposed ballot forward as is, we encourage exploring broader structural separation so that requirements can be more closely tailored to reflect the needs of their use cases.