Stephen Farrell wrote:
Michael Thomas wrote:
Stephen Farrell wrote:
Section 3.3.3 includes 512 bit rsa as a MUST. I think that that
might be an error. Is there really any need for anything smaller
than 1024 in any case?
Isn't there something of a calculation which equates effort to
break over time? DKIM lifetimes are normally quite short, so
smaller keys are not implausible, especially given the level
of protection DKIM actually provide (weakest link: DNS).
That's a defensible argument. Just to be clear though - there
are two lifetimes in DKIM - signature lifetime, related to
message transit times, and key lifetime, related to some unknown
management cycle, and its the latter (and presumably longer) one
that's in question here. From painful experience, changing keys
is something that some enterprises are really, really bad at.
Ah, yes, and I agree that key rollover is probably the
larger problem. Is 768 an implausable lower bound? We
could even perhaps go so far as to say SHOULD sign/1024
(where the wiggle room is if you have a good rollover
story, and the performance difference is worthwhile).
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
