Hi Watson, I also wonder where did you come to such a conclusion from.
Besides discussion about contexts in EdDSA, there was a slide in my presentation that was about signature formats ambiguity in IKEv2, that may be interpreted as a promotion for using the same key with different signature algorithms. This interpretation is wrong, the purpose of the slide was to show, that the same, say RSA key can be used either in RSASSA-PKCS1 scheme, or in RSASSA-PSS scheme and there are some interoperability issues with that in IKEv2. By no means this slide meant that the key is used in both schemes. Regards, Valery Smyslov. From: Yoav Nir Sent: 18 ноября 2016 г. 11:31 To: Watson Ladd Cc: [email protected] WG Subject: Re: [IPsec] Take a stand for key hygine Hi, Watson On 18 Nov 2016, at 9:18, Watson Ladd <[email protected]> wrote: > Dear all, > > In reviewing the proceedings now online I noticed that someone is > proposing to support using the same key with multiple signature > algorithms. This is a bad idea that makes everyone sad. Showing that a > signature under one algorithm cannot be abused to obtain another > signature with a different algorithm is not something that is done. I don’t know where you got that, but I haven’t reviewed the proceedings. I believe you mean what I said about contexts in Ed448 (and possibly Ed25519ctx) from the CFRG draft. The question raised in IPsec (and TLS and in 30 minutes also in Curdle) was whether to specify a non-empty context string fro Ed448 (like “IKEv2”), or whether to just use the empty string. The argument for adding the string is that people use the same keys for different purposes (not different algorithms) anyway, even if we tell them not to, and by adding a context string we’re preventing signing oracles between IKEv2 and other protocols. The argument against is that this encourages the bad practice of using the same key for different purposes. We could end up with people regularly re-using keys and then they do it with RSA. Or EDCSA. Or any algorithm that does not feature contexts. At no point did anyone propose support for the same key with multiple signature algorithms or even for multiple purposes. HTH Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
