>> not recommended for use in signature_algorithms > > People deploying TLS can do the performance measurements for themselves > and decide whether high confidence in security is affordable for their > applications. Shouldn't speed be given lower weight than security in > decisions of what to recommend?
The problem is interoperability , or induced lack thereof. So, depending on the intended server “visibility” and the expected range of clients, a server can require McEliece for KEX and SLH-DSA for cert signing. But that’s not likely to be useful in the “wide Internet”. “Not recommended” does not mean “prohibited”: for the larger part of the Internet users those “not recommended” algorithms won’t make sense, while those who need/want them – can still use them.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
