You are correct that this is an enhancement and not a bug-fix.
But if the WG consensus turns out to be for it, then that's
where we end up, right?
Stephen, since Michael did not suggest a challenge to the process, it's not
clear why you felt it necessary to put things in those terms.
Michael raised a concern. A legitimate concern, if I may say.
We should deal with it the same way we deal with any other concern.
I'm far from convinced that _any_ permutation of this is worth breaking
backward compatibility. None of the reasons you gave seem compelling to
me.
That's a fair position. Others may disagree, equally fairly.
However, given that we have agreed to basically move to sha256,
signers who use sha256 will be signing incompatibly with allman-01
verifiers so I don't see why this change would be significant,
following on from that change.
Perhaps you missed the fact that this particular enhancement is being specified
in a way that permits messages signed using sha-1 to be accepted by validators
who implement the IETF's version of DKIM?
This difference between a compatible enhncement and an incompatible enhancement
is quite basic and it would be quite useful not to confuse them.
> Having a way to detect which broke -- header or body -- does not
require breaking backward compatibility.
Sort-of. Adding the putative "X=" header-hash you mentioned would
also require a verifier to do more than allman-01, so detecting
which is broken would require a verifier change, although such
signatures would remain compatible with allman-01 as you point
out.
The issue is not whether the verifier changes but whether mail from a pre-ietf
signer can be validated by a post-IETF implementation.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html