Alicja Kario writes: > We can't use hybrid if we don't have a specification how to put hybrid > keys into X.509 certificates.
Take a specification of how to put a Dilithium key into certificates. Modify the spec as follows: replace Dilithium with the trivial Ed25519+Dilithium concatenation. This immediately produces a spec of how to put Ed25519+Dilithium into certificates. Compared to the original spec, the modified spec is less scary and does a better job of encouraging rapid deployment. So why spend time on the original spec? Of course, the two specs aren't interoperable with each other, and aren't interoperable with the previous standards. Each spec triggers upgrade challenges. This isn't an argument for one spec over the other. > And that there are no technical reasons for not specifying use of pure > PQ signatures. I disagree. Specifying ECC+PQ in TLS, and skipping the specification of just PQ in TLS, reduces security risks. https://cr.yp.to/talks.html#2016.02.24 said "Pre-quantum signature system P needs to be replaced with post-quantum signature system Q. Make auditors happier: Replace P with P + Q. P + Q public key concatenates P public key, Q public key. P + Q signature concatenates P signature, Q signature. ... Auditor sees very easily that Ed25519+SPHINCS-256 security >= Ed25519 security." I was using software updates as an example (later I discussed KEMs and also mentioned keeping an ECC layer for those), and commented that keeping ECC had "unnoticeable cost". One could attempt to argue that using PQ instead of ECC+PQ is an important cost saving for TLS, but so far the claims I've seen along these lines don't hold up to examination (see, e.g., the quotes and analysis in https://blog.cr.yp.to/20240102-hybrid.html). In any event, the possibility of somehow justifying a cost argument against ECC+PQ doesn't change the fact that there's a security argument for ECC+PQ. ---D. J. Bernstein _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
