[ietf-dkim] 1193 considered harmful

[Stephen Farrell]

Michael Thomas wrote:
> My understanding in the chartering phase is that there was a great
> deal of desire to not make backward incompatible changes unless they
> were really, really needed. Ie, for things like security botches, and
> the like. This is much more of an enhancement and to my mind a fairly
> marginal one at that. Consider this: this will be setting the
> precedent on what is acceptable for breaking backward compatibility.

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?

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

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

I'd be interested in more opinions, including those in the room
yesterday, who might have changed their minds, or not...

S.