[ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"
mike at mtcc.com
Wed May 4 10:53:46 PDT 2011
On 05/04/2011 10:43 AM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: Michael Thomas [mailto:mike at mtcc.com]
>> Sent: Wednesday, May 04, 2011 10:29 AM
>> To: Murray S. Kucherawy
>> Cc: dcrocker at bbiw.net; ietf-dkim at mipassoc.org
>> Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"
>> It's because I didn't want to imply that those were the only two. It's just
>> what I found in my quick scan. But they were the advise about ignoring
>> signatures with sha1, and another saying you could ignore an l= *tag*.
> I can't recall the history of the first one, other than it being consistent with general IETF movement away from use of SHA1. Perhaps someone else can comment there.
Saying that receivers can ignore signatures with sha1 is a serious
difference. What does that do for interoperability if followed? Nothing
good is my guess. The advise I've always heard is "walk, but don't run"
away from sha1. Let's be real: DKIM's crypto guarantees are already low;
sha1 is the least of its weaknesses.
> The advice that a verifier can ignore the "l=" tag was in RFC4871, so copying it to RFC4871bis doesn't seem like a problem to me.
You can't ignore the *tag*. That's the normative change. Whether you
ignore the *output* is another matter. But of course you can't ignore
the output because l= is "internal". Yet another problem.
More information about the ietf-dkim