On 4/25/2011 12:30 AM, Murray S. Kucherawy wrote:
The only suggested change not yet made has to do with the choice of fields to
sign. Section 5.5 of RFC4871 (6.5 in bis) lists header fields to sign,
something
the IESG had us add as I recall.
The original specification provided a very modest list of 'required' fields to
cover. In fact I think it was only From. One AD held a Discuss until we added
more; in order to get the document out quicker, the current list was formulated.
The AD's core error was in thinking that DKIM was providing classic content
authentication and protection, rather than merely affixing an identifier to a
message.
Section 6.8 of the MLM draft extends that list
slightly, falling back on the justification given in RFC4871. It does so
largely
with the intent of taking responsibility for fields it added, especially
Authentication-Results, so that downstream agents can have some faith that
they’re “real”.
The dilemma is that it's natural to extend the set of fields in this way and
especially for an additional set like the List-* set. The problem is that the
DKIM Signing specification provides no semantics to the distinction between
what
is and is not signed. DKIM merely attaches an identifier to the /message/, not
a subset of the /message/.
As Dave pointed out (and he’s free to correct me if I have this wrong), we
never
ascribed any semantics to header fields covered by a signature. For X to trust
Y’s signing of an Authentication-Results field, there’s meaning being assigned
by both to a valid signature from X. But that’s out-of-band as far as DKIM is
concerned, and to go back and add it now in bis would require recycling at
Proposed Standard. So, although there are people that want to (or maybe even
do)
use DKIM this way, it’s outside of DKIM’s scope and the MLM document shouldn’t
make this specific statement about which fields to sign.
At the same time, a lot of this document talks about possible applications of
DKIM that go beyond the scope defined in RFC4871 and bis to help MLMs in a
DKIM
world, so maybe leaving it in is just fine, perhaps making that caveat
explicit
yet again at that point in the draft. This is my (current) preference.
My own primary concern, here, is that the document clearly mark the difference
between what is currently withing the DKIM specification and what goes beyond
it.
Suggestions welcome.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html