On Tue, Jul 14, 2026 at 10:41 AM Eric Rescorla <[email protected]> wrote:
> > > On Tue, Jul 14, 2026 at 5:10 AM Rifaat Shekh-Yusef < > [email protected]> wrote: > >> Hi Ekr, >> >> Thanks for the detailed review and comments. >> See a few comments inline. >> >> Regards, >> Rifaat >> >> >> On Thu, Jun 25, 2026 at 12:52 PM Eric Rescorla <[email protected]> wrote: >> >>> Document: draft-yusef-tls-pqt-dual-certs-02.txt >>> >>> Overall, if we are to support the simultaneous use of PQ and >>> traditional signatures in TLS, I think that composites are a superior >>> approach. >>> >> >> Can you elaborate on what you mean by "superior" in this case? >> > > Yes, I think the complexity of this approach outweighs the alleged > benefits. > We tried to address that in the latest version of the draft and align it with composite: https://datatracker.ietf.org/doc/html/draft-yusef-tls-pqt-dual-certs-03 > >> As far as I can tell, the only real benefit of this design >>> is that it allows you to perform a transition of the form traditional >>> -> simultaneous PQ/T -> pure PQ while avoiding the need to issue >>> separate composite certificates. >>> >>> >> Note that the use cases we are trying to address are *enterprise* use >> cases, *not Web*. >> >> Composite - requires 3 PKIs: the existing traditional, composite, and >> pure pqc. >> Dual - requires 2 PKIs: traditional and pure pqc. >> > > I'm not persuaded that 3 PKIs is significantly more complicated than 2. > I agree that 2>1 but we're not in that world. > > >> >> The transition from one mode to another in the dual case is much simpler >> and smoother than the composite, relying on changing some configuration to >> drop the traditional certificate when the time comes. >> > > The same thing is true with composite, AFAICT. > > With composite you need a new PQC PKI before transitioning from hybrid. > > >> Dual provides a better backward compatibility with legacy products making >> it simpler for organizations to gradually transition their systems. >> > > I don't agree with this. In either case, you have two certificates and > have to switch hit modes. > > Well, in this case, the server will need 3 PKIs: * Traditional PKI for legacy clients * Composite PKI for hybrid clients. * PQC PKI for pure PQC clients. And a complex server side policy to make sure that each client gets the right certificate. This gets even more complicated if a Composite CA signs a standard certificate. > >> Dual utilizes existing standards PKI infrastructure and standalone >> certificates allows for easier future replacement of algorithms without >> waiting for a new composite specification to define how to combine the >> signatures of these algorithms. >> > > It seems to me that we are seeing composite specifications added at about > the same time as pure PQ, so I don't think this is right. > > Will this always be the case? maybe. > >> Given modern automation (ACME) and shortened certificate >>> lifetimes, it's hard to believe just issuing the certificates is a big >>> deal, though perhaps technically being able to make the composites is? >>> >> >> I am not sure I understand this comment. Can elaborate on this? >> > > You're going to need to issue a lot of certificates anyway, I don't see > why > issuing the composite certificate is a big deal. > The issue is not with the end entity certificate, but the PKI and the CA certificates. Regards, Rifaat > > -Ekr > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
