[ietf-dkim] The (really) latest SSP draft

[Jim Fenton]

Douglas Otis wrote:
>
> On Oct 19, 2007, at 8:46 AM, Jim Fenton wrote:
>
>> Dave Crocker wrote:
>>
>
>
>>> 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 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.

>
> 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 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.

-Jim