[ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first Author breaks email semantics

[Douglas Otis]

On Jan 14, 2008, at 7:35 PM, Frank Ellermann wrote:

> Dave Crocker wrote:
>
>> The current SSP language modifies RFC2822, and so there should be
>> considerable clarity about the need, the benefit, and the impact.
>
> +1

+1

This issue also covers ISSUE 1519.

When a domain indicates all messages are signed via SSP "dkim=all",  
the normal use of RFC 4871 permits signatures to be on-behalf-of any  
header.  While the SSP domain is determined by the "first author"  
domain, the signature might be applied by the "first author" domain,  
but not on-behalf-of the "first author" as determined by the DKIM- 
Signature header's i= parameter.

There are a couple of choices to resolve the resulting conflicts  
created by the current SSP definitions where:

a) restricted keys signed on-behalf-of other than the "first author"  
are SSP policy of "all" compliant

b) unrestricted keys signed on-behalf-of other than the "first author"  
are not SSP policy of "strict" compliant

Both a and b conditions represent a possible problem.  Unrestricted  
keys MUST BE used by trustworthy systems where the choice of which  
header to sign on-behalf-of MUST BE in compliance with the domain's  
signing policy.

-- It is ludicrous to define SSP in a manner that negates a signature  
where the signing domain can be used for the "first author" and the  
where the key used is unrestricted by the g= parameter.  

-- It is questionable to define SSP in a manner where a signature not  
used for the "first author" and where the key is restricted by the g=  
parameter. 

By changing a and b to:

A) restricted keys signed on-behalf-of other than the "first author"  
are not SSP policy "all" compliant

B) unrestricted keys signed on-behalf-of other than the "first author"  
are SSP policy "strict" compliant

Then allows the following generalization:

1) restricted keys signed on-behalf-of other than the "first author"  
are not "all" or "strict" compliant and are to be treated as "invalid".

This solves the concern Jim raised regarding a process that normally  
only notes whether a key selector provided a valid result.

-Doug