Well for one very big reason: it doesn't break current interoperability.
...
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.
Even given that, I wouldn't advocate a change that means verifiers have
to have two ways of verifying during the transition... if I didn't think
it worth it. In this case, I do think it worth it.
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).
Barry
--
Barry Leiba, Pervasive Computing Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html