Doug, Much as I appreciate your personal appeal, it's really the rough consensus of the working group, and not my opinion, that matters.
If I understand correctly, the difference between the approach you favor and the one that I favor is as follows: Approach A (favored by Doug): Check the g= tag on the key referenced by a valid signature, if present, compare it to the local-part of a From address to determine if the signature is an Author Signature. Approach B (favored by Jim): Compare the i= value on a valid signature (or its default value) against a From address; if the i= value has a local-part, then it must match the local-part of that From address. If there is a g= tag in the key, then there must be a matching local-part in the i= of the signature in order for the signature to be valid, so the approaches are approximately equivalent in this case. If there is not a g= tag (or if its value is *), and if there is no local-part in the i= of the signature, then the approaches are also equivalent. The difference appears when there is not a g= tag (or if its value is *) and the i= contains a local-part. Approach A would consider this to be an Author Signature regardless of the local-part, and approach B would only consider this to be an Author Signature if the local-parts match. My rationale for B is that it allows a domain to apply a signature not representing an author sharing the domain. While we haven't gone through the details of how mailing list signing might work, there might be times when such an agent might want to sign a message, but explicitly not as the author. It also does not require the retention (or re-retrieval) of the key information in evaluating whether something is an Author Signature. As I understand it, your rationale for A is that it allows the local-part of i= to be used for an opaque tag representing but not revealing the identity of the user or agent for which the signature is being applied. My response to this is that there are lots of other places an opaque tag could be put, since it is local to the use of a particular domain, and can be done without interfering with the ability of a domain to sign as other than an author. -Jim Douglas Otis wrote: > 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
