> If hybrid signatures are used, we strongly prefer non-composite hybrids, as they simplify the PKI and provide greater flexibility.
Like dual? On Wed, Jul 15, 2026, 7:22 AM John Mattsson <john.mattsson= [email protected]> wrote: > >However, I don't believe that SLH-DSA would be considered a practical > solution for TLS negotiation. > > I would disagree. Ericsson’s conclusion is that SLH-DSA is practical for > all of our TLS, DTLS, and QUIC telecom use cases. > > Our conclusion is also that we prefer the modest performance overhead of > standalone SLH-DSA over the significant PKI complexity introduced by hybrid > signatures. If hybrid signatures are used, we strongly prefer non-composite > hybrids, as they simplify the PKI and provide greater flexibility. > > Cheers, > John Preuß Mattsson > > *From: *Scott Fluhrer (sfluhrer) <[email protected]> > *Date: *Wednesday, 15 July 2026 at 12:58 > *To: *John Mattsson <[email protected]>; [email protected] > <[email protected]>; > <[email protected]> > *Subject: *Re: [TLS] Re: Fwd: New Version Notification for > draft-yusef-tls-pqt-dual-certs-02.txt > > You are, of course, correct. > > However, I don't believe that SLH-DSA would be considered a practical > solution for TLS negotiation. > > ------------------------------ > *From:* John Mattsson <[email protected]> > *Sent:* Wednesday, July 15, 2026 1:29 AM > *To:* Scott Fluhrer (sfluhrer) <[email protected]>; > [email protected] <[email protected]>; <[email protected]> < > [email protected]> > *Subject:* Re: [TLS] Re: Fwd: New Version Notification for > draft-yusef-tls-pqt-dual-certs-02.txt > > >And the Europeans (or, at least their governments) have indicated that it > is a requirement for their security profiles. > > No, all European government I know of approve standalone SLH-DSA. > > Cheers, > John Preuß Mattsson > > *From: *Scott Fluhrer (sfluhrer) <[email protected]> > *Date: *Tuesday, 14 July 2026 at 22:55 > *To: *[email protected] <[email protected]>; > <[email protected]> > *Subject: *[TLS] Re: Fwd: New Version Notification for > draft-yusef-tls-pqt-dual-certs-02.txt > > > > > -----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 > > > > On Tue, Jul 14, 2026 at 06:01:55PM +0000, Scott Fluhrer (sfluhrer) wrote: > > > Forgive my curiosity, but could you please expand on that? > > > > > > We designed the composite certificates/signatures to act like "just > > > another signature algorithm" (if you don't peek into the innards and I > > > don't know why anything other than the low level crypto would need > > > to). > > > > 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". Those guesses are from companies working on Quantum > Computing, and so might reflect either marketing hype or overoptimistic > hope, but I don't know if we want to make that a security assumption. > > > > > > > > My personal opinion: I see the need for both pure and hybrid > > > authentication. However, the hybrid authentication needn't be > > > composite certificates - dual (aka parallel) certificates would > > > address the need just as well. > > > > My opinion is that hybrid authentication should be left to environments > with > > security profile standard specifying it. > > And the Europeans (or, at least their governments) have indicated that it > is a requirement for their security profiles. Even if the situations that > ACME supports need not consider those requirements, private CAs certainly > would have to and those would be in scope for TLS. > > > > > 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). > > > > > 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. > > > > > > > > ________________________________ > > > From: Ilari Liusvaara <[email protected]> > > > Sent: Tuesday, July 14, 2026 1:44 PM > > > To: <[email protected]> <[email protected]> > > > Subject: [TLS] Re: Fwd: New Version Notification for > > > draft-yusef-tls-pqt-dual-certs-02.txt > > > > > > As an operator, I can say that issuing composite certificate is a big > > > deal, even with automation like ACME. Because it involves actions that > > > can not be feasibly automated. > > > > > > > > > > -Ilari > > > > _______________________________________________ > > TLS mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
