On Oct 19, 2007, at 8:46 AM, Jim Fenton wrote:
Dave Crocker wrote:
1. Is the SSP specification intended (or allowed) to modify the
semantics of the DKIM Base specification (RFC 4871)?
I am hoping that folks do *not* intend to change the semantics of
the base specification, since any change will disrupt adoption of
the base.
I thought we had been very clear about this: SSP is intended to
provide additional information beyond that in the signature(s), and
particularly in the absence of an originator signature.
If such a change does occur, it should be clearly indicated as being
a change.
2. Does RFC 4871 contain any claims that a DKIM signature carries
a claim by the signer that any of the body or header content is
"correct" or "truthful"?
I ask because I believe it does not carry any such claim and that,
rather, a DKIM signature asserts a very generic degree of signer
"responsibility" which does not extend to formal claims of
correctness.
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 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 TPA-SSP permits less stringent authorizations rather than
identify validations. Identity validation goes well beyond the
intent of DKIM. Rather than bestowing the validity of an identity
onto a message, an identity in question would be able to authorize
the signing domain.
It might be useful to restate little can be assumed based upon the i=
parameter within the SSP. This could be changed by an SSP assertion
that the signing domain validates all identities, and clarifies what
this assertion actually implies.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html