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