[ietf-dkim] 1193 considered harmful

[Dave Crocker]

> 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>