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]
