-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave CROCKER
Sent: Wednesday, May 04, 2011 2:54 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating
Domain Identity"
On 5/4/2011 11:34 AM, Murray S. Kucherawy wrote:
-----Original Message-----
From: Michael Thomas [mailto:mike(_at_)mtcc(_dot_)com]
Sent: Wednesday, May 04, 2011 10:54 AM
To: Murray S. Kucherawy
Cc: dcrocker(_at_)bbiw(_dot_)net; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary - proposing ODID
"Originating Domain Identity"
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.
So the issue is that someone might read it as "leave l=<value> out
of what you feed to the hash" versus "hash it, but ignore what it's
telling you"?
If so, I agree, we should fix that.
Seems like the replacement text should be something along the lines
of:
l= Body length count (plain-text unsigned decimal integer;
OPTIONAL,
...
Considerations Section 8. To avoid this attack, signers
should
be extremely wary of using this tag, and verifiers might
wish
to ignore the tag.
To avoid this attack, signers need to be extremely wary of using this
tag, and
verifiers might choose to ignore signatures containing it.
If this is the sort of advice we are going to give then we should just
deprecate "l=".
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html