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

[Douglas Otis]

On Feb 1, 2008, at 2:58 PM, Jim Fenton wrote:

> Douglas Otis wrote:
>> This draft goes to the opposite extreme of the ASP draft and  
>> increases the restrictions for "all" compliance as well. This draft  
>> indicates _ALL_ messages are to include a signature with an i=  
>> parameter matches that of an identity within the From header.  This  
>> is not the defined use for RFC 4871.
>
> It is true that RFC 4871 does not require or define any binding  
> between the i= parameter and the From header field (or any other  
> header field, for that matter).  That is defined by *SP.  The  
> question is really the nature of that binding:  whether it's the  
> entire address (in cases where i= has a local-part) or whether it's  
> just the domain.  That seems to be what's at the heart of issue 1519.

You mean the i= binding is required by SSP.  ASP only requires domains  
to match.  IMHO, even that is too restrictive.  ASP should have  
permitted signing domains at or above the From header.  Only when the  
t=s parameter is asserted within the key, would there be a need for  
domains to match.

>> The ASP approach creates fewer corner cases.  At least with the ASP  
>> draft, any risk of misuse remains within the control of a domain to  
>> rectify.
>
> This last statement I don't understand.  Can you give an example of  
> "misuse within the control of a domain" that is introduced by  
> matching the local-part?

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

ASP seems like the better of the two approaches.  Eventually, MUAs  
will be doing there right thing.  Until then, it is important  
compliance requirements not lead to the use of falsified or ambiguous  
information.  The i= parameter could also be a temporal value not  
matching with any header when privacy is considered important.  A  
temporal value could provide a means to control abuse without exposing  
the provider's customer's identity.

-Doug