Jim As the cut-off approaches, this is an appeal for you to reconsider where agreement might be found.
Risks associated with the use of g= restricted keys signing messages where i= identities are not found within the From header exists whether policy is asserted or not. A g= restricted key signifies the signing is restricted due to limited trust. In other words, the message signed by such keys may not be controlled by the domain's signing practices, whether any policy records are published or not. Being aware of the risk associated with local-part restricted keys REQUIRES the presence of this restriction be indicated the DKIM validation process, or this risk can not be accurately assessed. The risk related to the use of g= restricted keys does not change substantially when the domain also asserts they sign "all" messages. Domains asserting such policy are also likely more cautious about the distribution of these local-party restricted keys. Why limit weighing this risk with local-part restricted keys to just rare situations where domains assert a DKIM policy? Otherwise, use of restricted local-parts not within the From header is likely indicative of messages attempting to phish or spam using keys purloined from someone's laptop. You seem fairly determined to keep your version of the "Author Signature" definition you feel designed to address this concern, but only in fairly limited situations. This definition, in many cases, prohibits use of user/agent specific information regarding a token directly associated with signatures without also implementing multiple signatures, or expecting verifiers to guess identities by picking the higher header within the message header stack. This is most unfortunate, as the value DKIM may have had in curbing abuse depends, to a substantial degree, upon the definition expressed within RFC 4871 for the i= parameter. This definition permits the i= parameter to serve as a token for the entity introducing the message (on whose behalf the signature was added). This token enables simpler feedback reports, and defensive measures that can be used by receiving domains. "They can use multiple signatures when they wish to be specific" sounds too much like "let them eat cake." This statement represents an excuse for an awkward and erroneous definition that overlooks the intent of RFC 4871, and the increased overhead, complexity, and risk. A defence afforded by meaningful tokens of the user/agent is not affected by a value being opaque and matches nothing within the message. Such an opaque value would be compliant with RFC 4871. The i= identity's real value is found as a token that can track sources within a domain of compromised systems. Whether the token represents an obscured machine or person does not matter. Even an i= identity changing every day still provides useful information when dealing with large domains where blocking at the domain is truly onerous. In addition, the Author Signature restatement of the definition for the i= parameter is plain wrong. One can not say the i= parameter represents on whose behalf the signature was added, and then say this identity must also represent the email-addresses found within the From header. Such a definition must be wrong in many cases. DKIM is not about ensuring that the identity of an individual matches that of an email-address contained with the message. Such matching is completely optional, since DKIM is _not_ attempting to replace S/MIME or OpenPGP. As such, there is no reason for DKIM policies to then stipulate what identities are permitted to represent the on-behalf-of entity. The recognizable identity offered by DKIM is the _DOMAIN_. Your Author Signature definition forces recipients into guessing which header might contain the identity on whose behalf the signature was added. This may happen when, to be compliant with the Author Signature definition, the signature remains ambiguous as a path of least resistance. Guessing identities then opens the door for spoofing, especially when multiple signatures are added, but perhaps in the wrong order. It is ironic most DKIM messages are not processed during the SMTP transaction, where a policy definition expecting use of multiple signatures only makes this goal less obtainable. This definition causes the signature processing overhead to be more complex, and more error prone, and less safe. Anyone using DKIM naively thinking that, because they sign all their messages using RFC 4871, they can then make a DKIM policy assertion they sign "all" their messages, will be in for a rude awakening due to your definition of Author Signature. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
