Jeff Macdonald wrote:
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.
I was misunderstood here. A local part on i= is REQUIRED if the signing
key is "restricted" through use of a g= parameter other than *. i= can
be used at other times and for other things as well, as you point out.
In the example you gave, i=(_at_)foo(_dot_)bar(_dot_)org would result in an
Author
Signature when the Author Address on the message is something like
jdoe(_at_)foo(_dot_)bar(_dot_)org(_dot_)
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. : (
Huh?? ASP does not prohibit other signatures, it just provides no
additional information about them.
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.
Sure, and doesn't signing the Sender header field clarify who actually
introduced the message, if that's important?
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.
Yes, that's the point.
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.
Just because the signing policy is expressed only at the domain level
doesn't mean that the definition of Author Signature must also be at
exactly the same level of granularity. So an Author Domain Signing
Policy can still deal with Author Signatures.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html