ietf-dkim
[Top] [All Lists]

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

2008-01-14 21:47:40

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

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>