Dave Crocker wrote:
A validator MUST support {SHA-1, SHA-256}.
+1
A signer MUST support {SHA-1, SHA-26}.
IMHO unnecessary, "SHOULD use SHA-256" and "MAY use SHA-1"
are good enough as you have it here:
I'm sorry, but this is NOT good enough for all the reasons previously given.
A signer SHOULD use {SHA-256} for its higher security
strength. However a signer MAY use {SHA-1}, such as for
compatibility with an installed base, lower computational
cost, or easier implementation effort.
All fine, but IIRC Stephen's concern was about the future
transition to another constellation when SHA-1 met Mr. Bond.
The problem isn't going to be finding a new hash - when SHA-1 falls we move to
SHA-256 and by the time SHA-256 falls I'm confident we'll have something
demonstrably better.
Rather, the problem is making sure that transitions are possible. This is why
having two mechanisms is a good idea - without two agility doesn't get tested
and likely will not work when we really need it.
To emulate this, what would you say about CRC32 today ?
Not that it is especially relevant, but I would say it is fine for its intended
purpose, which never should have been (and among informed people never was)
cryptograhic in nature.
Is
that "SHOULD NOT accept" and "MUST NOT generate" ? Or take
MD5 if CRC32 is too simple.
Attempting to list the many things it would be silly to do is a waste of time.
People will always find ways to be stupid. What we can do, and need to do, is
insure that a compliant implementation can be used intelligently.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html