We need to support composite authentication in private PKI use-cases. In a private PKI, it is easy for us to issue composite certificates. We have business to business applications which communicate via TLS and they make use our PKI issued certificates. We need to be able to use composite authentication between them.
>With composite certificates, the combinatorial explosion occurs directly >in certificates, which is the absolutely worst place to have that in. As Scott said, Composite signatures are just a signature algorithm, and they already have IANA registered OIDs. At the certificate level, they are just a signature. The certificate logic doesn't need any changes. I did not have to change my Certificate, CSR, CRL, OCSP or any other signed PKI structures for them to work, just like I didn't have to change them to add ML-DSA. That is why we have algorithm identifiers, to give us agility. Once my crypto library supports the signature algorithm, it just drops in, the same is true with Composite signatures. By the way, I'm not against the multi-certificates draft either. I don't agree that there has to be 3 PKI's in a transition... Traditional - > PQ/T -> PQ. Once you are on a PQ/T, you don't need to be in a hurry to migrate away from it. If EC/RSA is broken by a CRQQ, then composite ML-DSA is close to as good as pure ML-DSA at that point, so why would you need to expend the effort to move to the pure ML-DSA when you are already essentially there? Then, even if you decided to move to a different algorithm because you don't like ML-DSA anymore, you would probably decide to move to whatever the best algorithm is at that time, which could be a PQ/PQ if you are still concerned about algorithm resiliency. So I agree that a third migration will definitely happen one day, I am just not convinced it needs to happen before there is a CRQC. I also know there will be 4th and 5th migrations, and that such migrations will continue for the foreseeable future. 🙂 The negotiated resiliency in the multi-certificates drafts is definitely more complicated, but can be a flexible mechanism to handle all the various combinations of algorithms that will be invented. A word of caution: When we originally designed composite signatures back in 2019, we tried to make it flexible in a similar way as multi-certs. We defined s structure called composite that specified the algorithm identifiers for the algorithms that make up the composite. The LAMPS working group told us it was a "foot canon" and that implementors would choose the worst possible Insecure combinations, and that we needed to take the choice away. Is the dual certs draft going to ensure any kind of safety rail? Like whitelists of algorithms that are useable with the mechanism? I confess I haven't read the latest update yet. 🙁 Cheers, John Gray ________________________________ From: [email protected] <[email protected]> on behalf of Ilari Liusvaara <[email protected]> Sent: Tuesday, July 14, 2026 4:11 PM To: <[email protected]> <[email protected]> Subject: [EXTERNAL] [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" 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] Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
