Barry Leiba wrote:
This is very different from the current method, and a naive receiver
would *not* compute the new signature correctly.
That's correct; it would not -- the verifier would have to change to add
this method of verifying, and could remove support for the allman-01
version when it's satisfied that it's not seeing them any more.
You (Mike) clearly see this as more of a problem than I do. The
compatibility I want to be careful to maintain is this:
1. Continue to be able to use existing DNS records.
2. Make the transition to the IETF spec easy by making sure that
verifiers can verify both old and new sigs without much difficulty, and
that signers can, therefore, make their transition when enough verifiers
have done theirs.
I find this "enough" to be an *extremely* squishy concept. When is
"enough" enough? How can a signer determine such a thing? Who would
be brave enough to go first? We have to keep in mind that email has
no feedback loop, so it is *extremely* prone to entropy.
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.
The method I outlined -- and have implemented for around 6 months
or so -- does not break backward compatiblity and achieves the goal
of determining if the breakage is in the headers or not.
But it doesn't do any of the other nice things that I outlined.
What would allow it, with no transition needed, would be to hash the
body and put it in the header tag... and then continue to do the
full-message hash as now. I think that's a non-starter, though, because
it requires hashing the entire body twice (once by itself, and once with
the header stuck on).
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. Having a way to detect which broke -- header or body -- does not
require breaking backward compatibility.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html