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. 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. : ( As a result, instead of DKIM offering a "reportable" or "displayable" identifier clarifying who introduced the message, this identifier must again be guessed. : ( Jim's example as to why this definition is needed offers yet another problem with this scheme. In Jim's example, there are users and a mail-list in example.com. Example.com SSP asserts they sign "all" messages. Messages signed by the mailing-list contain the identifier of "mailing- list" that is not found within the From/Sender/Resent-* headers, whereas all the "user" messages will be signed with the i= parameter either containing the identity within the From header, or left blank, especially when the user is represented by a header further up the header stack. It is unknown whether the entire stack is included within the signature hash, so again guessing is needed when selecting a specific top most identifier and might be prone to spoofing. When the i= parameter is blank, the identity of who introduced the message is in doubt. In addition, messages signed by the mailing-list are also non-compliant with the "all" signed assertion, so they are likely to be rejected. The goal of this scheme was to "protect" the From line in a message for all legacy MUAs. This does not work. Protecting the From line MUST BE the role of the signer, and not that of the verifier. The signer should not offer keys to untrustworthy entities. When i= points to the Sender header, and this key is g= restricted, and the From header contains a user within the domain, message filtering will be able to identify this type of message as being fairly odd, and modern MUAs will be able to highlight the identity, making this message also appear odd to the recipient. IMHO, RFC 4871 should have declared such non-From header signatures with g= restricted keys as being invalid. The g= restricted key used for non-From headers represents the corner case of all corner cases. This extremely odd use is the primary reason for the extremely convoluted Author Signature definition. 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. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
