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,
Its neither that vague, nor that frightening. NIST will end up
organising a competition for a new hash algorithm - they've nearly
1. I can't guess what you interpreted as "frightening" in my characterization.
All I did was note your own reference to a 5-year timeframe and the lack of our
having any details about what would be chosen by then. As for vagueness, the
lack of detail could hardly be characterized otherwise.
2. You did not answer my primary question: What are you *specifically* are
suggesting being done to the specification?
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.
I'd be fine with that. Although it'd be a pity not to have a MUST
for the signer, but I guess some wording could handle that.
In other words, you think it appropriate to *require* that all signers *always*
This would mean, for example, that support for the next, preferred algorithm,
would require revising and re-issuing the specification.
Equally, I'd also be fine with the MUST for sha-256, if that were
where the consensus lay. I guess the main argument for the MUST on
sha-256 would be to encourage moving away from sha-1 before there's
much wider DKIM deployment.
I think it is a bit unusual, if not unprecedented, to choose "MUST" as a means
of encouraging folks, rather than because there is a technical *requirement* for
only and exactly the behavior that is mandated.
NOTE WELL: This list operates according to