Subject: Re: [ietf-dkim] [dkim] #11: 2.5 SDID minor nit

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Apr 2011 14:51:34 -0700

> -----Original Message-----
> From: dkim issue tracker [mailto:[email-masked]]
> Sent: Friday, April 15, 2011 2:48 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: [dkim] #11: 2.5 SDID minor nit
> 
> #11: 2.5 SDID minor nit
> 
>  http://mipassoc.org/pipermail/ietf-dkim/2011q2/015834.html
> 
>  In Section 2.5, the text
> 
>     identity claiming responsibility for introduction
>     of a message into the mail stream.
> 
>  seems to be odd and as stated technically untrue.
> 
>  Isn't SDID identity the responsible signer?  SDID has no technical
>  responsibility for either the creation of the message since it did not
>  exist yet, or responsibility for actually adding the message into the
>  mail stream.
> 
>  Maybe it can be reworded:
> 
>     A single domain name that is the mandatory payload output of DKIM and
>     that refers to the identity claiming responsibility for the signed
>     message introduced into the mail stream.

I think it's redundant to refer to a signed message, since that's what the entire document is defining; if the message isn't signed, the document doesn’t apply in the first place.

So the question to me is more like: Is an intermediary adding a signature generating a new message?

If the answer is "yes", then no change is required.

If the answer is "no", then it seems to me the simplest path is to change "identity claiming responsibility for introduction of a message into the mail stream" to "identity claiming some responsibility for a message in the mail stream".

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

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 15 Apr 2011 19:05:25 -0700

On 4/15/2011 2:51 PM, Murray S. Kucherawy wrote:
> So the question to me is more like:

I think that that's entirely the wrong question.

For this stage of the document, the questions are:

    1) What problems have been documented as being due to this wording?

    2) What technical errors does this text clearly represent.

In both cases, the answer for this text is "none".

Hence, no change should be contemplated.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Sat, 16 Apr 2011 01:13:18 -0400

> If the answer is "no", then it seems to me the simplest path is to change "identity claiming responsibility for introduction of a message into the mail stream" to "identity claiming some responsibi…

Good question.

I believe its depends on the intermediary type and what constitutes a 
new message. IMO, the mere act of stamping a message with a 
DKIM-signature is not a new message. An altered message at the header 
level, but still the same message.

Maybe another way to consider this is if its reasonable to suggest 
there are theoretical three levels of DKIM responsibility?

     Creator
     Signer
     Sender

My OP was raising the point the sender is a passive transport process, 
blind of the payload content or DKIM signature information.

On the other hand, we have the viewpoint of the receiver and the 
sender is generally viewed the initial responsible source for sending 
the mail and yet from an MUA (user) it may the FROM: as a responsible 
party.

So we have Z-Order responsibility chain of technologies:

    SPF    targets responsible senders
    DKIM   targets responsible signers
    MUA    targets responsible creators

I guess when UIs begin to show signer info, the DKIM trust theory (and 
hope) is the user beginning to shift to viewing the trusted signer as 
the responsible party for the message and perhaps being to turn a 
blind eye on the creator - the Cat's Meow for Direct Marketers.

Personally, I think its safer to view the SDID as the responsible 
identity for stamping a statement of authenticity and trust. 
Responsibility is really in the eyes of the beholder - receiver, DKIM 
verifier and user.

So maybe the text could be reduced to:

     A single domain name that is the mandatory payload output of DKIM and
     that refers to the identity claiming responsibility for signing the
     message.

This would allow DKIM-BASE to remove itself from the subtle 
differences in responsibility party claims.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 16 Apr 2011 01:43:09 -0400

> Hence, no change should be contemplated.

Dave, the SDID is not always the responsible identity for transporting 
a message.

2.5 implies the SDID is responsible for moving the message.

Using your criteria, I believe it falls closer to #2, but closer to an 
functional error.

Maybe an example will help when viewed from a receiver or MUA standpoint:

Non-list:

    Sender: Dave @ somewhere.com
    From: user @ hosted-user-domain.com
    To:   Dave @ somewhere.com
    DKIM-Signature: d=trustme.com

List:

    Sender: list-admain @ list-galore.com
    From: user @ hosted-user-domain.com
    To:   Dave @ somewhere.com
    DKIM-Signature: d=trustme.com

Who introduced the message into the mail stream in both cases?

Certainly not the SDID trustme.com.

A small fix to section 2.5 clears up the SDID transport responsibility 
ambiguity:

-- 
HLS