On Fri, May 01, 2026 at 01:40:46AM +1000, Viktor Dukhovni wrote: > On Thu, Apr 30, 2026 at 02:56:01PM +0000, Bellebaum, Thomas wrote: > > > Assume we use plan 2 and a client implementing the cross product of > > its chosen algorithms, while connecting to some server, fails to > > validate a certificate issued by (say) CAi. By deduction, it cannot > > validate PQi+Ti, so it either cannot validate PQi (meaning this > > connection would have also failed, had we followed plan 1) or it > > cannot validate Ti (meaning this connection would have failed now). > > No, this assumes that each client library will implement and, either by > default, or in typical client configurations, include among its > supported signature algorithms TLS codepoints associated with at least > each of: > > id-MLDSA44-ECDSA-P256-SHA256 > id-MLDSA44-Ed25519-SHA512 > id-MLDSA44-RSA2048-PKCS15-SHA256 > id-MLDSA44-RSA2048-PSS-SHA256 > > id-MLDSA65-ECDSA-P256-SHA512 > id-MLDSA65-ECDSA-P384-SHA512 > id-MLDSA65-ECDSA-brainpoolP256r1-SHA512 > id-MLDSA65-Ed25519-SHA512 > id-MLDSA65-RSA3072-PKCS15-SHA512 > id-MLDSA65-RSA3072-PSS-SHA512 > id-MLDSA65-RSA4096-PKCS15-SHA512 > id-MLDSA65-RSA4096-PSS-SHA512 > > id-MLDSA87-ECDSA-P384-SHA512 > id-MLDSA87-ECDSA-P521-SHA512 > id-MLDSA87-ECDSA-brainpoolP384r1-SHA512 > id-MLDSA87-Ed448-SHAKE256 > id-MLDSA87-RSA3072-PSS-SHA512 > id-MLDSA87-RSA4096-PSS-SHA512 > > this is based on what's presently in: > > > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs-19#section-8.1.2 > > Which makes (so far) for 18 signature schemes instead of 3, with 18 > public key and signature formats to implement. The list will grow...
Furthermore, as an implementer, 15 of those 18 would cause something to break in the signature library I have written... And this is ignoring any security concerns. > If we're truly expecting CrQCs by ~2029, for example: > > https://scottaaronson.blog/?p=9718 > > the composites are all pointless. Support for just "mldsa44" and > perhaps "mldsa65" (or their PQ-only replacements) should suffice for > mainstream public sites. TLS software libraries can implement > "mldsa87", but perhaps not include it in the default list of supported > signature algorithms. Sufficiently motivated server operators and their > specific clients can opt-in to configurations that also support > "mldsa87". I do not think there is really any reason not to also enable mldsa87 by default. If one supports mldsa44 and mldsa65, then also doing mldsa87 is a small step (as an implementer). And even if one adds a few years to that, the composite signatures are worse than pointless. Any key algorithm transitions are extremely hard. One really do not want any attractive nuisances to make things even harder. -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
