On Jan 29, 2008, at 9:52 AM, Jeff Macdonald wrote:
On Wed, Jan 16, 2008 at 09:46:26AM -0800, Dave Crocker wrote:
<snip>
In any event, "on behalf of" is key wording that permits more
flexibility than you seem to be acknowledging. Note, for example,
that the agent specified in the Sender field is acting "on behalf
of" the author.
Is that agent authorized to work "on behalf of" the author?
When the author's email-address domain is within (applying the key's
g= and t= restrictions) the domain of the signature on-behalf-of the
sender (per i=), the signature is authoritative for the author's
domain. By signing the message, the author's domain confirms the
message meets their signing policies. As such, the signing domain has
indicated their authorization of the Sender in this case.
What sense would it make for an SSP assertion to declare valid
signatures of the very domain to be non-compliant?
Whereas SSP began as a simple idea as a means of deciding whether
an unsigned message should have been signed, it has morphed into an
effort to validate the From field. That is a very, very different
goal.
While DKIM has the goal of assigning *any* identity to a message,
so that that identity can be assessed, the current work on SSP is
attempting to instead validate authorship.
DKIM needs to say what part of DKIM asserts a new identity. What is
the output of DKIM? And should that output be treated as opaque.
In general, the i= parameter should be considered independent of SSP
policies (an exception may be made for g= restricted keys). For
unrestricted keys, only the d= parameter needs to be assessed.
Unfortunately, the scope of a signature has been complicated. A
signature's scope can be restricted with g= and t= parameters within
the key.
The i= parameter should be generally considered independent of SSP
policies. Whether the i= parameter is on-behalf-of a particular
header is a separate matter. Any on-behalf-of identity indication
conveyed to the recipient must ensure this information is included
within the signature's hash. This information must also be within the
key's g= and t= parameters. A signing domain can have the signature's
i= parameter assert on-behalf-of to convey who introduced the
message. This identity might be opaque and not match with any
existing headers. This might be done to retain the privacy of the
entity introducing the message.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html