Subject: [ietf-dkim] draft-ietf-dkim-rfc4871bis-03: issues with 'z= Copied header fields'

From: Mark Martinec <[email-masked]>
Date: Fri, 11 Mar 2011 19:08:46 +0100

Section 3.5. of draft-ietf-dkim-rfc4871bis-03 describes the 'z' tag.
I have two comments on this tag.

issue #1. When dealing with an implementation, I realized that the
specification text has nothing to say on the *order* of header fields in
the 'z' tag. It does say that any header fields may be included, and that
this list has no direct correlation with a list of signed header fields,
i.e. the 'z' may include more, or less or different header fields than
the 'h' list.

As this tag mainly serves troubleshooting and statistics purposes, the
unspecified order may not be a serious issue. It is also not common
to include multiple occurrences of header fields, but that may just
as well be useful, e.g. Resent-*, Received, X-* fields.

It would be beneficial if the rfc would at least recommend one order.
It may seem obvious that a top-down order comes naturally, but
considering that a signing algorithm walks through multiple occurrences
of header fields bottom-up, the top-down order may no longer appear
so natural.

issue #2: The text for the 'z' tag includes the following:

  Header fields with characters requiring conversion (perhaps from
  legacy MTAs that are not [RFC5322] compliant) SHOULD be converted
  as described in MIME Part Three [RFC2047].

I find this confusing. If the purpose of this paragraph is to remind us
that a mail message header section must not be malformed, i.e. must
adhere to the 7bit ascii, etc., then I don't think this text belongs here.
A mail header section should be sanitized / converted to QP or
whatever is needed before signing, so there is no issue for rfc4871
or its 'z' tag here.

If however the above paragraph is to be understood that, despite knowing
that a mail header section contains improper characters, the DKIM signer
should QP encode them on its own for the purpose of forming the 'z' tag,
knowing that the actual mail header will not be sanitized, then I find it
clearly wrong. The purpose of the 'z' tag is to convey the actual text of
header fields as presented to a signing algorithm. Passing a sanitized
form to 'z' and unsanitized to the signer goes against the purpose of
the 'z' tag.

In short, I think the paragraph should just be removed.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 11 Mar 2011 10:14:58 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Martinec
> Sent: Friday, March 11, 2011 10:09 AM
> To: IETF DKIM WG
> Subject: [ietf-dkim] draft-ietf-dkim-rfc4871bis-03: issues with 'z=
> Copied header fields'
> 
> [...]

[as participant, not co-editor]

I tend to agree, since this way one could definitively detect header field re-ordering.  Even though, via the "h=" semantics, DKIM is fairly resilient to re-ordering, it might be helpful during diagnostic work to be able to detect for certain that it has occurred.

> [...]

Agree here too.

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 11 Mar 2011 11:07:10 -0800

>> It would be beneficial if the rfc would at least recommend one order.
...
> I tend to agree,
...
>> In short, I think the paragraph should just be removed.

On the theory that quick exchange might represent the beginnings of consensus, 
I'll anticipate our doing a change.

That prompts asking what the revised wording should be?

d/
-- 

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