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