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 > [EMAIL PROTECTED] > > 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, [EMAIL PROTECTED] would result in an Author Signature when the Author Address on the message is something like [EMAIL PROTECTED] > >> 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
