[TLS] Re: Fwd: New Version Notification for draft-yusef-tls-pqt-dual-certs-02.txt

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Tuesday, July 14, 2026 4:12 PM
> To: <[e-mail]> <[e-mail]>
> 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 <[e-mail]>
> > Sent: Tuesday, July 14, 2026 1:44 PM
> > To: <[e-mail]> <[e-mail]>
> > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]