On Jan 9, 2020, at 7:33 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
I have a somewhat related question. Is it better to talk of ‘key lengths’ or ‘key sizes’?
To my mind (and Paul will tell you that I get the details wrong), a key, the entity it identifies or that uses it, and an algorithm that might use it are a matched set. If I were to provide a quantum key to an RSA algorithm, it simply wouldn't work. So to my mind, whenever you talk about a key or a key length (which is specifically an attribute of an RSA key), you are implicitly talking about the entire set - and would do well to say so. In other words, if we're using RSA keys and changing the length, we should say "we plan to still use the RSA algorithm, but we are changing the length". Stating that we want to use an elliptical curve key only makes sense if we change the algorithm to an elliptical curve algorithm - and I'll bet one wants to get far more specific in such a case. Now, as was pointed out on the call, if we're commenting on *this*key*roll*, then discussing different algorithms is out of scope - but not, I would argue, because it doesn't make sense, but because there is a decision that has already been made and acts as prior restraint. What I'd like to see, therefore, is a compound statement conveying "IANA chooses to continue to use the RSA algorithm, but proposes to change the key length" or some such thing. The value of that is that mumble time units in the future, IANA will presumably roll the key again. At that point, I fully expect that "conservation of mental cycles" will be in vogue, and someone will say "why don't we do it the way we did it last time?" This document will come out and get updated to the new scenario. At that point, I'd like the statement to force the question - should the same prior restraint be in effect, or should one contemplate other algorithms? If other algorithms are also in view, that will imply making sure that relevant software can support elliptic curve or whatever. In the meantime, I could imagine BIND, UNBOUND, etc sprouting an algorithmic API, and the indicated future discussion therefore enabled to say "well, the relevant packages all support <>; that's at least an option." I could also imagine folks like Paul, Wes, and others kicking the tires of said software, and saying "<> actually works."