[ietf-dkim] Issue:1519 SSP-01 Unnecessary constraint on i= when asserting "strict"

[Douglas Otis]

Signature compliance changes when a From domain's SSP indicates  
"strict".

When a message has a valid unconstrained signature of the From domain,  
verifiers should consider this domain's signature authoritative for  
the domain's policies.  The only instance where the i= parameter  
should play a role in "strict" policy compliance would be when the key  
restricts local-parts via the g= parameter.

As SSP's "strict" is currently defined, although a message might be  
signed by the From domain using an unrestricted key, when the i=  
parameter is not "on-behalf-of" the From header, it will not provide  
compliance with a "strict" policy.  The From domain should validate  
sources within their domain prior to signing.  Hopefully this  
signature will also indicate the validated source.   A "strict" policy  
should not interfere in a signature's ability to indicate which source  
had been validated.

SSP's "strict" creates an unnecessary i= parameter requirement that  
will cause:

- unexpected corner cases such as when -

  a) office administrators send "on-behalf-of" their boss (Sender)/From
  ...


Mitigating corner cases will require:

- use of ambiguous signatures where the i= parameter is excluded

- use of multiple signatures

SSP policy should strive to minimize disruption.  There is no  
justification for "strict" policy compliance to invalidate any  
unrestricted signature of the From domain.  After all, unrestricted  
keys are able to sign any header and _must_ be utilized by trustworthy  
systems.  When unrestricted keys are used, it is also reasonable to  
assume that the domain's signing policies were applied prior to  
signing.  SSP's "strict" definition unreasonably constrains how the i=  
parameter might be utilized for unrestricted keys.  It is not  
reasonable to assume domains will have mitigated the exceptions  
created by the SSP definition for "strict" and its additional i=  
parameter requirements.  It is only reasonable to assume DKIM  
practices are based upon RFC 4871.  As currently defined, SSP is not  
compliant with RFC 4871.

-Doug