[ietf-dkim] draft-ietf-dkim-ssp-02.txt

[Douglas Otis]

On Feb 2, 2008, at 3:18 AM, Eliot Lear 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.
>>
>> 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.
>>
>> IMHO, unless the SSP draft is changed to comply with RFC 4871, the  
>> WG should consider adopting the ASP draft instead.
>
> Please indicate the paragraph in RFC 4871 that this draft would  
> conflict with.


RFC 4871:
,---
3.5. The DKIM-Signature Header Field
...
i= Identity of the user or agent (e.g., a mailing list manager) on  
behalf of which this message is signed (dkim-quoted-printable;  
OPTIONAL, default is an empty Local-part followed by an "@" followed  
by the domain from the "d=" tag). The syntax is a standard email  
address where the Local-part MAY be omitted. The domain part of the  
address MUST be the same as or a subdomain of the value of the "d=" tag.
'___
RFC 4871 clearly indicates the i= parameter is _intended_ to identify  
the user or agent for which the message is being signed.  When a  
signature is added on-behalf-of an entity whose email-address is found  
within the Sender header, and where the message happens to include a  
 From address within the same domain, the definition for Author  
Signature within the SSP makes the signature specified by RFC 4871 non- 
compliant with an "all" or "discardable" policy assertions, however  
the definition within ASP does not.  SSP stipulations changes RFC 4871  
signature handling to not use the i= parameter when there might be  
such a conflict with the From header.  Not surprisingly, RFC 4871  
never suggested the i= parameter not be used when there might be a  
conflict with an address within the From header.  This definition  
ensures the i= parameter will:
1) be falsified to include the From header email-address.
2) exclude the local-part to remain ambiguous.
3) necessitate multiple signatures to overcome ambiguities created by  
option 2.

SSP-02:
,---
2.6.  Author Address

  The "Author Address" is an email address in the From header field of
  a message [RFC2822].  If the From header field contains multiple
  addresses, the message has multiple Author Addresses, which may
  potentially cause the Evaluator to perform multiple SSP Checks for a
  given message.

2.8.  Author Signature

  An "Author Signature" is any Valid Signature where the identity of
  the user or agent on behalf of which the message is signed (listed in
  the "i=" tag or its default value from the "d=" tag) matches an
  Author Address in the message.
  '___
The SSP Author Signature definition essentially makes use of the i=  
parameter when the identity is not found within the From header  
problematic.  As the i= parameter is the only field that pertains to  
actual agent, it might be obfuscated by the signing domains using  
temporal hashing, but could be useful for tracking, for example.  Per  
the Author Signature definition in SSP, this type of use will require  
multiple signatures.  The additional overhead of multiple signatures  
is not necessary and represents a waste of resources or the  
prohibition of many uses for the i= parameter.
-Doug