Dave Crocker wrote:
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.
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.
Nothing. I interpreted you as being frightened of something
that might be required in future. I was trying to reassure you.
> 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.
I disagree. Its very well known how to plug in a new hash function.
Nothing vague about it IMO.
2. You did not answer my primary question: What are you *specifically*
are suggesting being done to the specification?
I am making no specific proposals, simply adding to the set of
things to be considered when/if some signature-algorithm flags are
being considered.
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.
A "pity"?
Yes. Its easier to just tell someone what they MUST do, rather than let
them figure it out from a SHOULD and a MAY. Not a big deal.
In other words, you think it appropriate to *require* that all signers
*always* use SHA-256?
That could be appropriate. I haven't said that I think it is.
This would mean, for example, that support for the next, preferred
algorithm, would require revising and re-issuing the specification.
That's inevitable so long as we prefer any set of algorithms. Same as
happens with every protocol using crypto when preferred algorithm
goodness changes.
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.
I think you may be taking one word a tad too literally there. (Is
that unprecedented:-)
Discouraging use of suspect algorithms is a good. It may or may not
constitute a sufficient good to be worthwhile doing in this case.
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html