> 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
