Subject: [ietf-dkim] Issue 1288: definition of 'signing address'

From: Jim Fenton <[email-masked]>
Date: Thu, 08 Jun 2006 17:07:19 -0700

The term 'signing address' is used several places within -base, so it
might warrant being defined in section 2.  Since the first mention of it
is in the introduction, I'd propose that we add a forward reference in
the introduction.  So the second paragraph of section 1.2 would become:

INFORMATIVE RATIONALE: The signing address (defined in Section 2.x)
associated with a DKIM signature is not required to match a particular
header field because of the broad methods of interpretation by recipient
mail systems, including MUAs.

And then add the following new section, probably after 2.2:

2.x Signing Address

The signing address for a given signature is the address specified by
the i= value of its DKIM-Signature header field, or in the absence of
the i= tag, by its default value as specified in the description of the
i= tag in Section 3.5.

How does this work for everyone?

-Jim

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Jun 2006 17:32:00 -0700

> the introduction.  So the second paragraph of section 1.2 would become:

Your suggestion seems fine to me, but I find myself once again reflecting on our
terminology.

A domain name is often -- but not always -- an address. However it is never an
email address.

In the context of DKIM, which is in the context of email, the signing is being
done by an identity -- indicated by a domain name -- rather than by an email
address (or even necessarily an IP Address; there is no requirement that the
signing domain have one.

Any chance folks would consider:

signing address
   ->
signing domain

?

d/
-- 

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

---

From: Jim Fenton <[email-masked]>
Date: Thu, 08 Jun 2006 17:37:40 -0700

> Any chance folks would consider:
Calling it a signing domain means that it would never have a
local-part.  The local-part is needed in order to allow the recipient to
match the signing address against other header fields to determine the
role of the signature:  Is it on behalf of the author (From address), a
resender, or perhaps a mailing list, in the case where these roles
happen to reside within the same domain?

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Thu, 08 Jun 2006 17:46:27 -0700

>address (or even necessarily an IP Address; there is no requirement that the

   We do have d= which is the signing domain which is what seems to me to
   line up with what you are saying. But i= requires the local part 
because of
   its relationship to g= in the selector, as well as its relationship 
to (eventually)
   SSP.

>Any chance folks would consider:
  By this do you mean removing the local part of i=?

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Jun 2006 18:03:09 -0700

>>> the introduction.  So the second paragraph of section 1.2 would become:

DKIM uses a domain name as the key.  Domain names do the signing.

That DKIM has additional information and constraints is good and useful, but
does not turn any of those additions into an email address doing the signing.

At the least, this exchanges demonstrates that the concern I am raising is
significant.

d/

-- 

  Dave Crocker

---

From: John Levine <[email-masked]>
Date: 9 Jun 2006 04:02:52 -0000

I took another look, and I see I didn't realize this section
is just about signers, not about forwarders, so:

I suggest we change the last sentence of section 4 to:

 Signers SHOULD NOT remove any DKIM-Signature header fields from
 messages they are signing, even if they are unable to verify
 those signatures.

Then perhaps add an informative note:

 INFORMATIVE NOTE: A message forwarder may remove DKIM-Signature
 header fields if it modifies a message in a way that makes it
 implausible that a subsequent verifier could verify the
 signature, e.g., if it reorders the MIME parts in a message
 or flattens an HTML message to plain text.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Thu, 08 Jun 2006 21:14:20 -0700

> or flattens an HTML message to plain text.
What does "implausible" mean? And I disagree about this in general;
the forensics of signatures are as worthwhile as the ultimately unverifyable
received headers which no RFC suggests that you remove.

       Mike

---

From: John L <[email-masked]>
Date: Fri, 9 Jun 2006 00:27:21 -0400 (EDT)

> What does "implausible" mean?

It means the same thing it does anywhere else.  I realize you think that 
verifiers can undo any change a mailing list may do to a message.  You're 
wrong, but I don't want to get hung up on that again.  That's why I used 
examples where the message bits are completely mangled.

> And I disagree about this in general; the forensics of signatures are as 
> worthwhile as the ultimately unverifyable received headers which no RFC 
> suggests that you remove.

It says "may".  Depends on what you expect to be downstream of you.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Fri, 09 Jun 2006 01:02:11 -0700

John L wrote:

 > It means the same thing it does anywhere else.  I realize you think 
that verifiers can undo any change a mailing list may do to a message.  
You're wrong, but I don't want to get hung up on that again.  That's why 
I used examples where the message bits are completely mangled.

The problem here is that you suffer from a lack of imagination of what
is "plausible", and I don't want that lack to become enshrined in the
standard.

 >> And I disagree about this in general; the forensics of signatures 
are as worthwhile as the ultimately unverifyable received headers which 
no RFC suggests that you remove.
 > It says "may".  Depends on what you expect to be downstream of you.

Having had quite a bit of experience at this at this point, I'd rather you
never decide what's best for me downstream, and most especially in the
case of mailing lists, etc, which you're just an intermediary
and you have no clue as to what my capabilities are.

Stripping means no forensics, period. The current text says that a
DKIM-SIGNATURE is a trace header. Stripping should be as
uncommon as  stripping received and other trace headers which
is as  far as I ever  heard is extremely frowned upon. The current
text in the draft conveys that sense but this does not.

-1

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 09 Jun 2006 15:19:10 +0100

Jim,

> How does this work for everyone?

Ignoring the actual definition (which is ok, as would be singing domain,
or signer), it seems a bit cumbersome to have pointers from 1.2 -> 2.X
-> 3.5 like that. Can't it all be put in one place? e.g. just define
the thing fully in 3.5, reference that from 1.2 and either omit 2.X or
else make 2.X consist only of a pointer to 3.5.

S.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 09 Jun 2006 13:46:55 -0700

> else make 2.X consist only of a pointer to 3.5.
I did it the way I did, in large part, because section 3.5 is so big. 
We could say it's defined in the description of the i= tag in section
3.5, I suppose.

Here's where I punt the decision to the document editor...

-Jim