[ietf-dkim] Conflicts between -ssp-requirements and -ssp (was: Step 9)

[Eric Allman]

It sounds like you are arguing that "all" should be "strict" and 
"strict" should be eliminated; as a corollary, no Third Party 
Signatures should be accepted under any circumstances.  That's a 
valid argument, but it has nothing to do with whether the -ssp draft 
is accurate.

I note however that -ssp-requirements doesn't seem to cover the Third 
Party Signature case at all.  Section 2 defines "Third Party 
Signature" but then never uses the term.  In fact, although the one 
line description of Problem Scenario 1 reads "Is All Mail Signed with 
DKIM?", and section 4.1 seems to cover the case of a Third Party 
Signature (at least, it doesn't mandate a First Party Signature), 
sections 2 and 5.3 point 3 define "DKIM Signing Complete" as 
requiring a First Party Signature.  In short, it appears that -req 
doesn't permit third party signatures under any circumstances.  I'm 
not sure this was the intent of the working group.

Reading the documents in this light, it's pretty clear that -ssp and 
-req are in conflict.  The WG needs to decide on which way it wants 
to go.

eric




--On September 30, 2007 12:14:23 PM -0700 Michael Thomas 
<mike at mtcc.com> wrote:
> The main problem I'm having is tying "all" to third party
> signatures whatsoever. The requirements make no mention of "all"
> being tied to them, and I -- again -- don't see what the value is
> for the _originator_ to make any statement about them. "All" is a
> function of the originator's practices alone. Whether a useful (to
> the receiver) third party signature is tacked on in transit is
> completely out of its hands.