Would you care to expand on that? Why is it dangerous? My understanding (and do correct me if I'm wrong) is that the proposal under discussion is that the server (or client in an mTLS scenario) sends multiple Certificate messages (to convey the multiple public keys) and multiple Certificate Verify messages, each of which signs with a different public key (and algorithm).
As an example, the server might send both an RSA certificate (and certificate verify) and an ML-DSA certificate (and certificate verify); the client checks both, and proceeds only if both verify. I don't see why this is cryptographically dangerous. If the RSA certificate/signature is secure, then the authentication is secure, and likewise the ML-DSA certificate/signature. Of course, an implementation might have a bug where it doesn't check one of the certificates/signatures properly, but that's actually fairly easy to test. I do see a complication of how the client specifies its authentication policy; that is, what set of certificates it insists on authenticating (e.g. just one certificate is fine, or does it require both a classical and a postquantum certificate), but that detail can be handled within the protocol; it does not occur to me that it would be 'dangerous'. Now, I am not specifically advocating this approach; I believe that we will want to support hybrid authentication in some form, but I personally don't have a strong opinion on how that is done (whether parallel certificates as suggested here, or with composite certificates or possibly a third method). I'm just interested in your reasoning - why is the possibility of multiple things that don't interact considered excessive dangerous flexibility? ________________________________ From: Ilari Liusvaara <[email protected]> Sent: Thursday, April 30, 2026 11:08 AM To: [email protected] <[email protected]> Subject: [TLS] Re: anyone interested in multiple CertificateVerify messages? Furthermore, to me the design seems dangerous due to excessive flexibility. As bad hybrids are, this seems _way_ worse.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
