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
