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