On Tue, Jul 14, 2026 at 08:54:59PM +0000, Scott Fluhrer (sfluhrer) wrote: > > > > -----Original Message----- > > From: [email protected] <[email protected]> > > Sent: Tuesday, July 14, 2026 4:12 PM > > To: <[email protected]> <[email protected]> > > Subject: [TLS] Re: Fwd: New Version Notification for > > draft-yusef-tls-pqt-dual- > > certs-02.txt > > > > Introducing a new algorithm requires creating a new line of certificates, > > and > > most webservers just do not support any sane way of automatically doing > > that. > > > > And even if webserver does support it, there are all manner of nasty edge > > cases > > making life hard for the ACME client. > > If introducing a new algorithm into ACME is an issue, I believe that should be > fixed - not only for hybrid, but postquantum in general. We can't expect that > we can rely on RSA, ECDSA and EdDSA for that many more years. We don't know > when q-day will happen, but I've seen estimates from 2029 to "early 30's".
It is just that introducing any new algorithm takes manual steps. Further issue is webserver algorithm support; it might not support post-quantum at all, or only stand-alone ML-DSA. > > And while dual certificates are in theory simple (do both independently with > > intersected algorithm list), in practice this causes major issues with APIs > > (since > > there are now two EEs). > > Is EE == Encrypted Extension? If that's the correct acronym > expansion, I don't see why we couldn't just use one. On the other > hand, I do acknowledge that it would make things more difficult for > the TLS protocol level - I'll let the people that actually work on > that level to talk about how difficult it is (and if you're one of > those guys, I would bow to your superior knowledge). EE => End Entity. I would say that by far the worst part is interaction between TLS implementation and the application code running on top of it. Also, implementing the algorithm checking is surprisingly nasty (there is a long list of CVEs related to this kind of thing). Other than that, it seems quite straightforward (assuming no nasty surprises in the way dual certificates are expressed in TLS). > > With composite certificates, the combinatorial explosion occurs directly in > > certificates, which is the absolutely worst place to have that in. > > The obvious way to address that is to not specify every combination, > but only one (or a handful). There have been a huge number of > elliptic curves published, however we appear to be quite happy with > using a few. Hence needing security profile standard. The LAMPS stuff has 18, and I do not see that getting cut down. -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
