Differences between the two ML-DSA ballot proposals
Corey Bonnell
Hello,
Last October, I created a draft ballot for allowing ML-DSA keys to be certified and used as CA keys in PR 624 [1]. This ballot was created to support the PQC pilot that Microsoft announced at the Warsaw F2F, so some of the requirements of the ballot support the specific goals of that pilot.
A few weeks ago, Google also submitted a proposal in PR 662 [2]. These two proposals are substantially similar, as they’re both based on the language used in SMC-013 [3]. However, there are two major differences:
- PR 624 only allows for ML-DSA-87, whereas PR 662 allows for all three parameter sets (ML-DSA-44, ML-DSA-65, ML-DSA-87) to be used. PR 624 restricts ML-DSA to only the -87 parameter set to satisfy the requirements of the Microsoft pilot at that time.
- PR 624 does not allow for mixed (purposefully avoiding the word “hybrid” here!) algorithm hierarchies. In other words, the proposal prohibits the use of an RSA CA to sign a certificate that certifies an ML-DSA key, and vice versa. This requirement was established to satisfy the Microsoft pilot goals. PR 662 has no such restriction.
To resolve these differences, I recommend the following approach:
- Allow all three ML-DSA parameter sets. The restriction to allowing only -87 made sense in the context of a specific pilot program but doesn’t make sense for general use. ML-DSA-44 keys and signatures (1,312 and 2,420 bytes, respectively) are roughly half the size of ML-DSA-87 keys and signatures (2,592 and 4,627 bytes, respectively). As a practical matter, requiring ML-DSA-87 will use significantly more bandwidth during TLS handshakes, so flexibility here is desirable.
- Allow for mixed hierarchies. Although security is lost for RSA and ECDSA-based CAs in the event of a quantum break, requiring non-mixed hierarchies may pose migration challenges. For example, there may be libraries and applications that consume end-entity certificates that certify ML-DSA keys but not yet support ML-DSA trust anchors. Also, the CT ecosystem still very firmly uses P-256, so ML-DSA end-entity certificates may still contain SCTs signed using ECDSA. The use of non-mixed hierarchies (or quantum-resistant only hierarchies) is likely a good goal in the future, but it seems to be needlessly restrictive now.
In summary: do what PR 662 is proposing.
Thoughts on this approach?
Thanks,
Corey
[1] https://github.com/cabforum/servercert/pull/624
Pedro FUENTES
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/DS0PR14MB6216D60D55593F76BA6F3DEE923E2%40DS0PR14MB6216.namprd14.prod.outlook.com.
WISeKey SA
Corey Bonnell
Hi Pedro,
That is an excellent question. I’ll leave it to Google to clarify since PR 662 is a Google proposal.
Thanks,
Corey
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/D4ACD45B-3705-4188-82C4-530A66AF40AC%40wisekey.com.
Chris Clements
Hi Corey,
Thanks for summarizing the DigiCert and GTS proposals. While we appreciate the desire to provide flexibility and facilitate a PQC transition, Chrome has concerns regarding PR 662 (and PR 624) and their potential impact on the web, specifically regarding the viability of the CT ecosystem and the risk of fracturing the broader post-quantum migration for secure connections on the internet.
As this group is likely aware, allowing ML-DSA keys and signatures introduces a large increase in certificate size. Regardless of whether the hierarchy is mixed or purely ML-DSA, CT logs will be forced to ingest, store, and serve these significantly larger certificates. CT did not need to be considered when Ballot SMC013 added ML-DSA to the S/MIME BRs. If CT logs reject these larger certificates to protect their infrastructure, the certificates will lack SCTs and be unusable for public TLS on the web. Conversely, if logs accept them, we risk bloating and threatening the stability of the entire CT ecosystem. We are not supportive of a TLS BR update when the CT ecosystem’s ability to safely support it remains unproven. A post-quantum TLS PKI on the web without a functional transparency mechanism is a net-negative for ecosystem security.
It should also come as no surprise that Chrome believes MTCs are the viable path forward for PQC on the web. MTCs have been intentionally designed so that website operators who do not wish to optimize for certificate chain size can deploy Standalone MTCs just as easily as a traditional X.509 certificate, acting essentially as a new end-entity key type with a new signature algorithm, requiring no extra infrastructure for landmark distribution. Passing a permissive ballot for traditional X.509 certificates with large PQ keys will incorrectly signal to the ecosystem that such certificates are a viable, long-term path for the web.
While it's understandable that some organizations want to pilot ML-DSA signatures, modifying the globally applicable TLS BRs to facilitate localized testing feels disproportionate. Further, and I don’t want or mean to speak on behalf of Microsoft, but it’s not clear to me that their pilot program requires a change to the TLS BRs. Ultimately, organizations testing ML-DSA key support, TLS handshakes, or production pilots can and should utilize test infrastructures, private PKIs, or custom trust anchors. If those pilots reveal that the risks are managed and wider-spread ML-DSA support is appropriate, we can then revisit its broader applicability and determine if it should be codified in the TLS BRs.
At this point in time, Chrome cannot support either of these proposals, as the specific motivation for doing so remains unclear and the associated risks for the web and transparency are simply too high.
Thank you
-Chris
蔡家宏(chtsai)
Hi Chris,
As a global standard, the BR's scope extends beyond browsers. We might consider a more inclusive approach, as many non-browser applications do not require SCTs and can effectively manage the increased latency from larger PQC signatures.
Best Regards
蔡家宏 Chya-Hung Tsai
Director
Identification & Certificate Research
Tel: +886-2-2370-8886 ext. 722
Fax: +886-2-2388-6720
Email: cht...@twca.com.tw
10F., No. 85, Yanping South Road,
Taipei 100002, Taiwan(R.O.C.)
https://www.twca.com.tw
Dimitris Zacharopoulos (HARICA)
I don't see why we can't plan for both. Adding ML-DSA in X.509 server authentication certificates doesn't block the MTC path.
As it was highlighted, CT is not a requirement in the BRs which means the baseline requirements could allow ML-DSA as a drop-in replacement of RSA/ECDSA in server TLS certificates without factoring the Certificate Transparency element. After all, the CABF and the SCWG are opining on the cryptographic suitability of an algorithm which must be secure enough for the server authentication purposes.
Even if MTCs become adopted, other consumers may not support them which means the ecosystem must have flexibility to continue with X.509 support despite the performance impact due to longer signatures.
I believe the motivation is clear which is to have a PQC solution ready for server authentication sooner than later. The BRs should allow the use of a Quantum Safe, secure algorithm for X.509 server authentication certificates for certificate consumers that want to continue relying on the existing technology. If a new technology emerges that is faster, more reliable and more efficient, it will drive adoption on its own and support from CAs.
IMHO if the SCWG does nothing about PQC, it will send the wrong signal that it ignores the risks and doesn't care enough to provide a solution to a long-known issue.
Thanks,
Dimitris.
Aaron Gable
Ben Wilson
Mozilla’s current restrictions on certificate key algorithms and sizes are simply present policy requirements. They are not insurmountable or permanently fixed. They can be quickly revised if ML-DSA or any other post-quantum algorithm is standardized, sufficiently analyzed, supported, and determined to operate satisfactorily for the Web PKI. Once these things happen, such changes are straightforward from a policy and implementation perspective.
Thanks,
Ben
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
Sebastian Robin Nielsen
I checked this.
And no, CT logs does not need to accept submission for any root in CCADB.
This because CCADB works as a ”application system” to multiple trusted root programs.
Meaning if 0 trusted root programs accept the root, CCADB would still have the certificate, but it would not be trusted by any root programs.
A CT log only needs to comply with their ”own” root programs. Meaning, a CT log that comply to mozilla root program only need to accept roots present in mozilla’s root program.
Chrome could technically, set a enforcement that a CA certificate approved by any root program must be accepted.
But that would also technically mean, that Chrome suddenly ”accept” a competing root program into their policy – and that would be kinda weird.
Im not entirely sure how the application process in CCADB actually work – if you actually must show a logged certificate to be able to get approved into a root program (which would then make it a moment 22 if not pending roots in CCADB is approved in the CT logs) but im pretty sure if such need would arise, it would be possible to create a ”pending-only CCADB CT log” that can be used to show you have the capability to log – and such log is totally erased from time to time to ensure ML-DSA certificates don’t clog the system, and this CT log would only accept certificates pending in CCADB, but not any certificate from a approved root.
Best regards, Sebastian Nielsen
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
Aaron Gable
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/006b01dcdd98%243520c5e0%249f6251a0%24%40sebbe.eu.
Adriano Santoni
Perhaps it should also be factored in that, for PQC certificates to be actually usable for website authentication, the TLS protocol must support them.
At the moment, I understand this isn't the case, but there is an I-D (co-authored by Google) to extend TLS 1.3 for this purpose (for ML-DSA). Assuming it's published soon, say by the end of the year, it will take more time for the main TLS implementations to be updated accordingly. Some TLS implementations are specific to individual applications, while others are operating system-level and shared by multiple applications (not just browsers) and may take longer to adapt.
I suppose this is another piece of the puzzle.
Adriano
Tomas Gustavsson
Sent: Thursday, May 07, 2026 8:32 AM
To: server...@groups.cabforum.org
Subject: Re: [External Sender] Re: [EXTERNAL]-[Servercert-wg] Differences between the two ML-DSA ballot proposals
Dimitris Zacharopoulos (HARICA)
Dimitris.
Adriano Santoni
The most popular API clients (OpenSSL, Bouncy Castle, WolfSSL,
...)
already works with ML-DSA server and client certificate
authentication.
That's fine, but... what about SChannel, BoringSSL, Apple Network Framework, and NSS ?
Adriano
Tomas Gustavsson
To: server...@groups.cabforum.org
Subject: Re: [External Sender] Re: Re: [EXTERNAL]-[Servercert-wg] Differences between the two ML-DSA ballot proposals