Okay, I've implemented the current spec, and extended it for sha256. But
it was done in such a way that I am still supporting sha1. I feel that
this proposed suggested change falls in the same category as moving from
sha1 to sha256, and should be treated the same way:
Receivers MUST implement bodyhash= and b=
Signers MUST implement bodyhash=
Signers SHOULD use bodyhash=
We need to make sure that we understand the proposal thoroughly. Some of
the descriptions so far have been worded in a way that their meaning
could be misconstrued.
That's my 2c.
Tony Hansen
tony(_at_)att(_dot_)com
Barry Leiba wrote:
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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html