On Friday, October 15, 2010 07:50:36 pm Murray S. Kucherawy wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas
Otis Sent:
Friday, October 15, 2010 2:30 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] detecting header mutations after signing
Citing a layer violation makes little sense. With DKIM, the message
body does not stand on its own. DKIM binds elements related to the
RFC5322 header fields with the message body, for the purpose of
extending favorable message handling, such as white-listing. Since
DKIM has this property, citing layer violations lacks any basis.
I thought the "What DKIM does" thing was a long-dead horse, as we'd long
ago reached consensus that what DKIM does is provide a stable identifier
on the message, and nothing more. That makes this assertion inapposite.
Does it? If the identifier is bound to the hashed information, I think it
makes complete sense to believe one can make something of that content and
it's relation to the identifier. It provides a stable identifier, but that
identifier is inextricably tied to the signed content.
I think perhaps now would be a good time to make that explicit, since a lot
of people (including some in here) are continuing to infer that DKIM should be
used to "protect" the body. So I propose this be added to 4871bis:
1.4 Data Integrity
A DKIM signature associates the d= name with the computed hash of
some or all of the message (see Section 3.7) in order to prevent the
re-use of the signature with different messages. Verifying the
signature asserts that the hashed content has not changed since it
was signed, and asserts nothing else about "protecting" the end-to-end
integrity of the message.
I apologize in advance if that causes yet another traffic maelstrom, but
it's something we need to settle. And since the discontinuous expectation
of DKIM exists outside the working group as well as inside it, that means
consensus needs to be codified.
Your proposed wording sounds a lot to me like what I think of as "protecting"
the end-to-end content. I feel there's a lot of talking past each other here.
If we were doing what you think of as "protecting", what would be different?
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html