On Tue, Jul 14, 2026 at 5:12 PM John Gray <John.Gray= [email protected]> wrote:
> 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? > > Because we do not want to carry that legacy code forward when it is not needed. This is a code that you need to maintain, fix bugs, test, etc; we would rather get rid of it completely when it is not needed. > 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. > > You can do that easily with the Dual approach. > 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. > > Maybe, but that transition period might take a very long time, and keeping the old legacy code around might not be the best approach. Regards, Rifaat > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
