-----Original Message-----
From: Dave CROCKER [mailto:dhc(_at_)dcrocker(_dot_)net]
Sent: Monday, April 25, 2011 3:00 PM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Revision to draft-ietf-dkim-mailinglists posted
So with all that in mind, here's my suggestion for replacing the first part of
this section:
<<<<<<<<<<<
6.5 Signature Practices
The purpose of the DKIM cryptographic algorithm is to affix an
identifier
to the message in a way that is both robust against normal transit-related
changes and resistant to kinds of replay attacks. An essential aspect of
satisfying these requirements is choosing what header fields to include in the
hash and what fields to exclude.
s/kinds/some kinds/
The basic rule for choosing fields to include is to select those fields
that constitute the "core" of the message content. Hence any replay attack
will
have to include these in order to have the signature succeed; but with these
included, the core of the message is valid, even if sent on to new recipients.
...or the header and/or body is otherwise modified.
Common examples of fields with addresses and fields with textual content
related
to the body are:
o From
o Reply-To
o Subject
o Date,
o To, Cc
o Resent-Date, Resent-From, Resent-To, Resent-Cc
o In-Reply-To, References
o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post,
List-Owner, List-Archive
One could argue that the MIME fields (omitted here) constitute the core of the
message as they go to the representation of the content. However, they haven't
been precluded by the above text so it's probably fine.
I'd actually like to add Authentication-Results because an agent that wishes to
claim that observed authentication meta-data should become part of the message
core certainly should sign such a field, but that's not worth recycling at
Proposed and basically RFC5451 already says that anyway.
The basic rule for choosing field to exclude is to select those fields for
which there are multiple fields with the same name, and fields that are
modified
in transit. Examples of these are:
o Return-Path
o Received
o Comments, Keywords
Note that the DKIM-Signature field is also excluded from the
header-field
hash, because its handling is specified separately.
Typically, it is better to exclude other, optional fields because of the
potential that additional fields of the same name will be legitimately added
or
re-ordered prior to verification. There are likely...
Works for me.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html