If we say that a signer SHOULD use SHA-256, then I think we have solved the
security-strength concerns, for the moment.
Agreed.
If the security community converges on a different preference, prior to our WG
Last Call for the base, then we can plug in something other than SHA-256. It's
a minor change.
However I think the model for the spec language is clear:
A validator MUST support {SHA-1, SHA-256}.
A signer SHOULD use {SHA-256}.
This leaves out what the signer MUST support: I believe you need to have a MUST
support SHA-256 in there. I'm ambivalent about whether or not there should be a
signer SHOULD support SHA-1 in there. I figure that signers that want to use
SHA-1 will do so as long as they can be assured of verifier support.
We can, of course, add discussion about the trade-offs. This might lead to the
somewhat unusual alternative for signer language, along the lines of:
A signer MAY use {SHA-1} for its lower overhead, in spite of potentially
reduced security strength. A signer SHOULD use {SHA-256} for its higher
security strength.
It may be unusual, but I like it.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html