I agree that not doing hybrid is the best option in theory, but the reality is that some customers and jurisdictions require hybrid.
Regards, Rifaat On Wed, Apr 29, 2026 at 8:51 PM David Benjamin <[email protected]> wrote: > Hehehe. Well, I would agree that composites are preferable to this model. > But I also think not doing hybrids is preferable to both. :-) > > On Wed, Apr 29, 2026, 20:44 Andrei Popov <[email protected]> > wrote: > >> Indeed. A good argument in favor of composites, even if David did not >> intend it this way 😊 >> >> >> >> Cheers, >> >> >> >> Andrei >> >> >> >> *From:* David Benjamin <[email protected]> >> *Sent:* Wednesday, April 29, 2026 4:56 PM >> *To:* ekr <[email protected]> >> *Cc:* [email protected] >> *Subject:* [EXTERNAL] [TLS] Re: anyone interested in multiple >> CertificateVerify messages? >> >> >> >> The main challenge with doing something like that is not in TLS, but in >> what leaks out of TLS. Systems everywhere are designed around a notion of >> "the" peer certificate that you received over the connection. There's the >> tls-server-end-point channel binding, but more broadly, TLS APIs tend to >> expose a "get peer certificate" function. >> >> >> >> I think this thus falls under the "way too complicated and expensive to >> justify doing" bucket. Once you have to move mountains to get the hybrid >> property, it becomes extremely not worth it. >> >> >> >> On Wed, Apr 29, 2026 at 7:37 PM Eric Rescorla <[email protected]> wrote: >> >> Even stipulating for the moment that it's good to sign with multiple >> certificates, I do not believe that this is the correct approach to doing >> so. >> >> >> >> If we're going to do something here, something more like >> https://datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/ seems >> like a better starting point. >> >> >> >> -Ekr >> >> >> >> >> >> On Wed, Apr 29, 2026 at 4:27 PM Stephen Farrell < >> [email protected]> wrote: >> >> >> Hiya, >> >> Given that it may be the case that getting certificates for >> composite signing keys could be impractical and also involve >> a combinatoric explosion in the number of credentials severs >> would need to have available, I wonder if anyone has explored >> whether it'd be useful to look at defining a way in which a >> server (or, I guess, a client) could authenticate using more >> than one CertificateVerify message? >> >> I guess that figuring that all out, and getting it implemented >> and deployed would involve a pile of work, but ISTM it might >> be useful, hence the question:-) >> >> Cheers, >> S. >> >> PS: If this isn't a bonkers idea, I'd be willing to do work on >> it, for whatever that'd be worth:-) >> >> _______________________________________________ >> 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] >> >> _______________________________________________ > 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]
