On 6-Oct-2006, at 06:01, Robert Loomans wrote:
In section 3.8 the draft uses normative language to specify key
sizes. Should it not instead specify *minimum* key sizes, or is it an
explicit goal to specify an absolute size? (Would it be bad, for
example, if I chose to use a 4096 bit key instead of the 2048 bit key
I SHOULD use?)
I believe there are concerns about the overhead of using unnecessarily
larger keys....
I'd like to understand that concern a little better.
It seems to me (as a crypto non-expert) that the three principle
degrees of freedom available when you generate a key are the
algorithm, the key length, and the the validity period.
For applications in which the key is exercised very regularly, the
usual (general) advice I have heard is to use a larger key, or to
reduce the validity period.
This kind of advice regarding specific key lengths and lifetimes
seems to change over time -- the key sizes get longer and the
validity periods get shorter -- presumably as a result of ongoing
research and improved capabilities of the machinery which can be used
to break keys.
By specifying absolute values for the algorithm and the key size,
this document leaves us only with the validity period, and changing
that in many cases is going to involve talking to a customer to
reissue a certificate. Talking to customers is expensive.
For sensitive applications, it also seems possible that in the future
the requirement to use a 2048-bit key length might imply the need for
such keys to expire more frequently than is practical to manage.
I'm quite prepared to believe there are reasons to fix the key size
in the specification, but I think that decision needs some
justification.
Joe
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
