Ned Freed wrote:
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.
A "good idea" isn't necessarily expressed as MUST. Violating
a MUST means that things break and cause harm. MUST is also
not necessarily used to promote a certain way of implementing
a good idea like agility. Instead of "edit config file and
select SHA-256" agility could be also implemented by "get and
install fresh package from where you got the last package".
I can see a SHOULD here, but no MUST. Probably it's one of
the usual MUSTard interpretation issues, and we actually mean
the same thing.
If verifiers MUST support SHA-256, then it's fine if signers
support only SHA-256. Why a "MUST SHA-1" for signers if they
don't want to use it ? Maybe you want a "SHOULD support two
algorithms, and at this time one of them MUST be SHA-256, the
other MAY be SHA-1". Or something else you talked about here,
whirlpool or whatever.
BTW, a conforming implementation could be a rather expensive
feature with an accredited SHA test lab and registration fee.
Bye, Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html