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