I am not quite sure why I am listed as ambivalent. Before the listed announcement on April 15th, the mail archive lists two messages by me on topic [0]. There is [1], in which I specifically write
> I agree with Stephen on this one and would not support adoption of > non-hybrids. And I would not support adoption of hybrids. 😊 The logic should be “live and let live”. Several governments agreed that non-hybrids are secure enough for them to protect their national security information. Why are you standing in the way of those government standards, when the alternatives (hybrids, acceptable to you) are available for use by those who don’t like hybrids? Plus, I haven’t seen an answer to my logical (I think) point: if the goal of hybrids is ensuring the data is protected against CRQC , then hybrids will become irrelevant at least as soon as CRQC are available, and thus useless for long-term protection. And there is [2], stating > Even with Recommended=N, I can imagine many managers reacting to a > presentation on "YOU NEED TO USE PQC LIKE ML-KEM BECAUSE ELSE..." by googling > "deploy ML-KEM now" and being recommended this rather than a safer > hybrid[omitted reference]. I am not convinced that such a person, if given > more knowledge, "doesn't want to do that". For some, their data must be protected past CRQC – so, for them the whole bet is on the PQ component. Their need is not satisfied by hybrids, because the Classic component of hybrids helps only until CRQC is around. I your data doesn’t need to live that long – good for you, use hybrid, or stay with Classic – either way it doesn’t matter. But if your data has to “outlive” Classic – then hybrid is not an option. (This should be obvious to anybody, why isn’t it?!) Which is why non-hybrids must be allowed.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
