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

[Douglas Otis]

On Oct 27, 2007, at 8:13 AM, Dave Crocker wrote:

> Patrick Peterson wrote:
>> I agree. RFC 4871 does not contain claims that a DKIM signature  
>> implies content is "truthful". Your intent is unclear from your  
>> question: if we are both right, is this a good thing? Or do we  
>> need to modify RFC 4871?
>
> Discussion about raw DKIM signing sometimes seems to have the  
> underlying view that the From field is validated as being accurate.  
> At the least, this seems to vary among different folk. I wanted to  
> see whether there is a clear view one way or the other.
>
> I'm not suggesting "fixing" DKIM.  I'm seeking clarity among the  
> community. (It's a California thing.)

RFC 4871 does not provide a concise definition of what a valid  
signature implies, or indicate any assertion of signed content  
validity.  Nor does RFC 4871 indicate which validations are to be  
applied prior to asserting the i= parameter.  Either fields must be  
to be added to the key, or a separate policy record used in  
conjunction with a valid signature must be added.  A policy record  
for a valid signature would represent additional overhead to that of  
a content validity policy parameter added to the key record.  It  
seems some might be interested in introducing of a policy type  
parameter within the DKIM key.  Some have suggested selector domain  
label conventions as another possible approach.

Value is obtained when a mailing list adds a DKIM signature.  In such  
a case, few would expect the From field to always match that of the  
signing-domain.  It would be possible to add records within the From  
domain that authorize a different signing-domain, while also  
simultaneously asserting a practice of only using authorized signing- 
domains.  This would permit stronger, and yet more flexible policy  
statements aimed at restricting valid sources for a particular  
domain.  The tpa-ssp draft scales to an astounding degree while still  
retaining a deterministic overhead of one or two transactions.  This  
could introduce a safer and far more scalable third-party  
authorization scheme, over that of SPF.  (Assuming a third-party  
authorization mechanism would be desired.)

The concept of delegating a portion of a DNS zone, or continuous  
exchanges of public keys or locations between various administrative  
domains seems wholly unworkable for most situations, such as mailing  
lists.  Should DKIM erode the use of the mailing-list+  One would  
hope not, as mailing-lists represent a fairly practical coping  
mechanism in their own right.

-Doug