Paul's note further convinces me that the correct semantics for SSP are not
'the message will be signed' but rather 'there will be a DKIM header'
The difference between the two is that adding a DKIM header need not mean the
same thing as signing the message. A DKIM header might simply specify a
selector for a key record that 1) specifies the NULL algorithm 2) some form of
restrictions on use.
Such a use would fully address the third party policy concerns raised.
* The sender would choose the from address, insert the NULL key record
with the relevant selector.
* The Third Party sender would sign the message themselves and add in a
NULL DKIM header for the selector specified by the sender.
* Receivers would note that the email is compliant with the sender policy
and that the Third Party Sender claims responsibility.
In this scheme everything works fine. The semantics of the policy language are
simple but effective. There is no need for crypto to be exchanged between the
parties unless they want to. The complexity is kept out of the policy record,
everything is in the key record.
The optimum semantics remain 'there will be a DKIM header with a selector of
the form *.xyz.example.com'
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Paul Hoffman
Sent: Monday, August 21, 2006 11:28 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Delegating responsibility: a make
vs. buy design decision
At 10:40 AM -0400 8/21/06, Damon wrote:
It sounds like what you and few other people want is an SSP policy
that says "if you receive a message that is supposedly from
this site
(for some definition of "from") and it doesn't have the
mark that says
that XYZ is authorized to sign the message, assume the message is
forged". Is that a correct summary of the requirement you see?
I am glad you put a question mark at the end.
But you didn't answer: is that a correct summary. (And, if
not, is there a summary that looks like this one?)
It took me a while to read through this can of worms, but for every
argument against the optional flags that myself, Hector, and I few
others are looking for, I see contrary arguments that only
bolster the
point that these thing we are hinging on are OPTIONAL. Just because
they are OPTIONAL does not automatically make them irrelevant nor
unnecessary.
True. However, even if they are optional, they have to be
fully specified in order for people in the WG to understand
if they are relevant or necessary. The parts that I miss in
this thread is: "for this particular optional statement of
policy, what is the recipient of that policy message expected
to do? What are the requested to do?"
I see people who supposedly agree with each other about the
policy appear disagree on the required and requested response
to the policy.
Some of that is because the tone of the messages is "this is obvious"
(which it is not), and some of it is because there are
long-winded discussions of the usefulness of the messages
that don't concretely say what the recipient should/must do.
Note that the above summary of this one point has such a
specification: "assume the message is forged".
--Paul Hoffman
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html