- Lastly, DKIM needs to plan for sha-1 being retired (2010) and probably
for sha-256 being superseded by some new NIST-competition-winning
algorithm in the next 5+ years. So even if we start now with "only
sha-256", all of the above is still an issue down the road.
DKIM already permits specifying different algorithms.
If you are suggesting that it needs to do more than that, to anticipate some
requirement that might be imposed 5 years from now, please elaborate.
As for SHA-1 vs. SHA-256: Dealing with both the current desire to use sha-256
and maintain compatibility with pre-IETF, existing use of sha-1 is handled
easily by having the specification state something like:
A signer SHOULD use sha-256.
A validator MUST support sha-256 and sha-1.
This permits pre-IETF signers to be validated by post-IETF implementations.
Whether to make the signing behavior a SHOULD or a MUST depends upon whether the
IETF version is permitted to maintain downward compatibility with pre-IETF
validators.
Given that the very limited purpose of DKIM, for assigning transit
accountability, and given that SHA-1 is a "concern" rather than being outright
"broken", the use of SHOULD seems reasonable.
A MUST probably also is inappropriate because it then makes it impossible for
the signer to choose some other algorithm that the signer deems appropriate.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html