[ietf-dkim] draft-ietf-dkim-ssp-02.txt (issue 1519?)

[Douglas Otis]

On Feb 1, 2008, at 4:42 PM, Jim Fenton wrote:

> Douglas Otis wrote:
>> On Feb 1, 2008, at 2:58 PM, Jim Fenton wrote:
>>
>> A domain using RFC 4871 as defined might wish to clarify which  
>> entity had been authenticated.  Such authentication information  
>> would help prevent intra-domain spoofing.  SSP essentially prevents  
>> a single signature from offering identity assurances when a message  
>> is being redirected (Resent-From header) or being sent on behalf of  
>> (Sender header) the From header.  Is it really reasonable for an  
>> MTA to add two signatures, one ambiguous and the other identity  
>> specific?  An additional signature is only needed because of the  
>> SSP definition for a compliant Author's signature.  There is enough  
>> information within a signature added on-behalf-of (i=) of the  
>> Resent-From header for compliance to be ascertained without also  
>> requiring an additional ambiguous signature (no local-part).
>
> SSP has no relationship with the Resent-From, Sender, and similar  
> header fields.  Is the root issue here that you would like it to do  
> so?  If I remember correctly, your draft proposes this, but I have  
> seen no consensus to deviate from the requirements in this way.
>
> On the other hand, matching the local-part of i= (when it is  
> present) prevents a signature that may be associated with a Sender  
> or Resent-From address that happens to be in the same domain as the  
> From address, from being misinterpreted as an Author Signature when  
> it's not.

Both SSP and ASP establish policies that assure the presence of a  
domain's signature for all From email-addresses.  As some suggested,  
there might be a desire to extend policy protections to the Sender  
header as well.  Sender and From email-address protections can be an  
option without creating any RFC 4871 signing changes provided the  
definition of an "Author Signature" does not mandate use of specific  
identities.

When a signature by a domain is valid, the message can be assumed to  
comply with the domain's policies.  After all, messages that do not  
comply with a domain's signing policy must not be signed.  Signatures  
including the identity of the From header is not necessary to obtain  
an assurance of policy compliance.  However SSP's "Author Signature"  
definition adds an unnecessary local-part stipulation!  The ASP Author  
Signature definition acknowledges that policy is assured by the  
domain's signature.

The only caveat might be with restricted keys.  In this case, a domain  
is trusting those given restricted keys to not generate misleading  
messages.  For those that wish to give restricted keys to  
untrustworthy entities, the simplest solution would be to define  
Author Signatures as those matching domains (as does ASP's  
definition), but with an added condition that signatures for other  
identities with restricted keys are excluded.  At least, not adding  
the restricted key caveat will not reduce the information given  
receivers.

-Doug