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. ]