On Mon, May 4, 2026 at 11:26 AM Bellebaum, Thomas <thomas.bellebaum= [email protected]> wrote:
> > > Let's start with two fully migrated endpoints: > > > [...] > > This sounds like you suggest combining the classical chain for a legacy > > client with the post-quantum chain. How do you address the problem I > > pointed out that you don't want upgraded clients to accept the > classical > > chain for the legacy client? > > I don't. See the first sentence above :) > Ok, fine, I'll admit that in a PKI where all endpoints and anchirs are ugpraded the multiple CertificateVerify and composites have similar effect. But that's not solving the important case of PKIs that have a mix of upgraded and legacy client and servers. > > To wit: the classical certificate for a legacy server obviously has a > > classical leaf, but a post-quantum chain. That could be composite. The > > present proposal does not recover composites there as that would require > a > > server upgrade. If there isn't a way to do that, then the present > proposal > > has no value, as clients are only as secure as the weakest thing they > > accept. > > The idea was to replace every PQ-only signature with a composite, Stephen started the thread with 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'm discussing that point. Best, Bas
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
