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. > 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 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). With composite certificates, the combinatorial explosion occurs directly in certificates, which is the absolutely worst place to have that in. > ________________________________ > 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]
