On Tue, Feb 19, 2008 at 03:04:08AM -0800, Douglas Otis wrote:
Expanding upon the effect of the SSP-02 Author Signature definition
based upon a conversation with Jim...
Jim suggested that to comply with SSP-02, signatures will not make use
of the i= parameter, since the i= parameter is needed only for g=
restricted keys.
Is that really true? I thought one could use i= in cases like so:
d=bar.org
i=(_at_)foo(_dot_)bar(_dot_)org
I didn't think g= was needed in that case.
Instead of a practice that offers an explicit token (even one that is
opaque) identifying the user/agent that introduced the message, once
again examining the header stack and guessing which header might apply
again becomes necessary. It is also unknown whether the entire header
stack will have been captured within the signatures hash, so this
guessing may also be prone to the introduction of spoofed headers
while attempting to resolve top most identifiers.
Secondly, this also means that MUAs attempting to highlight who the
signature indicates as having introduced the message is also prone to
getting this wrong, because the signature's identity (i=) MUST BE
absent whenever the entity introducing the message is _not_
represented by the email-addresses within the From header. : (
Although unlikely, some domains may feel compelled to sign the message
twice. One signature to comply with the SSP-02 Author Signature
definition, and another to clarify who actually introduced the
message. : (
I think being able to use multiple signatures offers flexibility.
As a result, instead of DKIM offering a "reportable" or "displayable"
identifier clarifying who introduced the message, this identifier must
again be guessed. : (
I don't think it really matters who introduced the message. What really
matters is if any of the DKIM identities are recognizable.
Jim's example as to why this definition is needed offers yet another
problem with this scheme.
<snip>
Recommendation:
1) Change "Author Signature" to "Author Domain Signature".
2) Change "Author Signing Policy" to "Author Domain Signing Policy".
3) Accept the premise that when the "Author Domain" signs the message,
the message is complaint with the "Author Domain's Signing Policy" _by
definition_.
4) Only when the message is not signed by the "Author Domain", is the
"Author Domain Signing Policy" in need of checking.
These seem reasonable to me, but I don't know if we need to be that
fine grained.
--
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | jmacdonald(_at_)e-dialog(_dot_)com
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html