It does not break current implementations though. As Murray
and Arvel's implementations can attest.
Again, I didn't say your "X=" broke anything. I said that it
requires a change in the signer and verifier in order to detect
which of the header or body broke the signature.
Well, but that's irrelevant. Mike's (correct) point is that if the
verifier doesn't care about the new information provided, the verifier
doesn't have to change. With the proposal on the table, all verifiers
would have to migrate.
I agree, though, that since the verifiers have to migrate anyway (to
SHA-256), I think this is a less-than-compelling reason not to do this.
The "slippery slope" reason is more compelling.
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