On Oct 19, 2007, at 2:27 PM, Jim Fenton wrote:
Douglas Otis wrote:
On Oct 19, 2007, at 8:46 AM, Jim Fenton wrote:
4871 indeed uses a broad notion of "responsibility". However, in
the case where the signing address is the same* as some other
header field, such as 2822.From, I don't see how a signer can be
responsible for a message that uses its own address without an
implied claim that the address is correct.
* "same" meaning that the i= address is either the identical, or
that the i= address has the same domain if i= has no specified
local part.
It would be a bit more accurate to use the term "signing domain",
rather than "signing address". An address (the i= parameter) is
optional, after all.
The parameter is optional, but if absent, the signing address (what
i= represents) takes the default value of the d= parameter
(preceded by an @). There is always a signing address. I get
tired of typing "i= (or d= in its absence)" every time I talk about
i=, since this is in the specification, but every time I don't
spell this out very explicitly I need to write a clarifying message.
When an i= parameter defaults, only the signing domain is specified.
Here the term "signing domain" always applies without explanation.
In addition, there is no such thing as a "signing address". This
implies a process that does not exist.
Someone might consider an email-address within a message's header
matching an i= parameter (default or otherwise) as having been
verified based upon this term "signing-address" rather than "signing-
domain". This is _not_ how the base specification has been written,
nor is this in agreement with even an Informational Discussion
describing use of the i= parameter.
Quote from the base specification Informative Discussion:
Constraints between the value of the "i=" tag and other identities in
other header fields seek to apply basic authentication into the
semantics of trust associated with a role such as content author.
Trust is a broad and complex topic and trust mechanisms are subject
to highly creative attacks. The real-world efficacy of any but the
most basic bindings between the "i=" value and other identities is
not well established, nor is its vulnerability to subversion by an
attacker. Hence reliance on the use of these options should be
strictly limited. In particular it is not at all clear to what
extent a typical end-user recipient can rely on any assurances that
might be made by successful use of the "i=" options.
The optional i= parameter represents the identity of the user or
agent (e.g., a mailing list manager) on who's behalf the message
was signed. The base specification makes no statement that this
optional parameter SHOULD NOT be applied when the user or agent
identity has not been validated. (See the informative note about
whether the i= parameter can be trusted.) Without a stipulation
that the i= parameter MUST BE validated, and exactly which
validation mechanisms must be used within the base specification,
it would be a significant change to assume inclusion of the i=
parameter thereby confers responsibility to validate identities
onto signing domains. There are also cases where the i= parameter
can not be applied, such as when the signing domain is within a
sub-domain of the identity, or when the identity is within another
domain. Would you envision the blocking of messages which did not
include the i= parameter containing the local-part?
The validation of the local-part of i= is that it must (wildcard)
match the value of g=, if present, in the key record. An agent in
possession of a private key that does not constrain the local part
(no g= in the key record, or g=*) is one that is trusted by the
domain to take responsibility for any message on behalf of any
address in the domain. So the i= parameter is already validated.
The domain is responsible for messages it sends, with or without a
DKIM signature. Adding a DKIM signature allows messages
retransmitted on their behalf to be identified as having been sent by
that domain. A DKIM signature makes no strong statement regarding
whether email-addresses within a message will have been validated in
some undefined fashion. You appear to be claiming otherwise. This
seems to be rather dangerous and wishful thinking. Don't oversell
what DKIM provides.
The cases you cite: signing domain is within a subdomain of the
identity, or when the identity is within another domain, are
intentional. example.com should not be taking responsibility for
messages on behalf of bigbank.com. If it has a legitimate reason
to do this, it is delegated a key by bigbank.com and signs as that
domain.
I would not envision (and can think of absolutely no reason to)
blocking messages without an i= parameter specifying a local-part.
The ability to specify i= without a local-part was done for a reason.
Including a local-part within an optional parameter does not have a
clear, well defined requirement. Any reasons or requirements for
include the i= parameter has been specified with "mights" and
"mays". Hence the i= parameter SHOULD NOT be relied upon. It is
also wholly improper to declare the i= parameter as the signing
entity. The signing entity is the d= domain. Refer to the signing
entity as the signing domain.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html