On Oct 27, 2007, at 8:13 AM, Dave Crocker wrote:
Patrick Peterson wrote:
I agree. RFC 4871 does not contain claims that a DKIM signature
implies content is "truthful". Your intent is unclear from your
question: if we are both right, is this a good thing? Or do we
need to modify RFC 4871?
Discussion about raw DKIM signing sometimes seems to have the
underlying view that the From field is validated as being accurate.
At the least, this seems to vary among different folk. I wanted to
see whether there is a clear view one way or the other.
I'm not suggesting "fixing" DKIM. I'm seeking clarity among the
community. (It's a California thing.)
RFC 4871 does not provide a concise definition of what a valid
signature implies, or indicate any assertion of signed content
validity. Nor does RFC 4871 indicate which validations are to be
applied prior to asserting the i= parameter. Either fields must be
to be added to the key, or a separate policy record used in
conjunction with a valid signature must be added. A policy record
for a valid signature would represent additional overhead to that of
a content validity policy parameter added to the key record. It
seems some might be interested in introducing of a policy type
parameter within the DKIM key. Some have suggested selector domain
label conventions as another possible approach.
Value is obtained when a mailing list adds a DKIM signature. In such
a case, few would expect the From field to always match that of the
signing-domain. It would be possible to add records within the From
domain that authorize a different signing-domain, while also
simultaneously asserting a practice of only using authorized signing-
domains. This would permit stronger, and yet more flexible policy
statements aimed at restricting valid sources for a particular
domain. The tpa-ssp draft scales to an astounding degree while still
retaining a deterministic overhead of one or two transactions. This
could introduce a safer and far more scalable third-party
authorization scheme, over that of SPF. (Assuming a third-party
authorization mechanism would be desired.)
The concept of delegating a portion of a DNS zone, or continuous
exchanges of public keys or locations between various administrative
domains seems wholly unworkable for most situations, such as mailing
lists. Should DKIM erode the use of the mailing-list+ One would
hope not, as mailing-lists represent a fairly practical coping
mechanism in their own right.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html