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
[EMAIL PROTECTED]
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
