ietf-dkim
[Top] [All Lists]

Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

2006-12-20 06:34:26
Charles Lindsey wrote:

No, I don't think that is what Tony was claiming the majority of
implementations did (I think it is what the current wording says to do,
but I think Tony was saying all those should result in an empty body to
be hashed).

Anyway, here is some wording:

   The "simple" body canonicalization removes empty lines from the end
   of the body until either the last line is non-empty, or no lines 
   remain. An empty line is a line of zero length after removal of any
   terminating CRLF. If the body is not now empty and the last line is
   not already terminated by CRLF, a CRLF is added to it.

      INFORMATIVE NOTE: Following [RFC 2822}, the CRLF which separates the
      header fields from the body is NOT part of the body, and therefore is
      never presented to the signing or verification algorithm. In the case
      of a pure binary message (such as one with a
      Content-Transfer-Encoding of 'binary') the concept of "lines" may not
      be meaningful. Nevertheless,
      wherever the pair of octets that represent CRLF happens to occur,
      that is to be considered as the end of a "line" for the purposes 
      of this canonicalization algorithm.

Now, you are all invited to find some way of misinterpreting that :-).

I can live with the above.

I was going to suggest ABNF, but that's where we got into trouble last
time. :-) If we *were* to add ABNF to the above, it would have to have
two cases.

Next, for body length counts which, as I now see from 3.4.5, are to be
applied _after_ canonicalization. (BTW, I misinterpreted those counts as
line counts rather than byte counts in an earlier message).

Here is another example to amuse you:

Last-header: foobarCRLF
CRLF
----------------
12345678CRLF
12345678CRLF
12345678
----------------

Now sign that with l=29 :-)
(don't forget to add the CRLF to the last line first)

The text on when l= counts should be applied hasn't changed meaning,
thankfully. It's very specific: it's an octet count applied after
canonicalization.

Canonicalization produces:

----------------
12345678CRLF
12345678CRLF
12345678CRLF
----------------

and l=29 produces:

----------------
12345678CRLF
12345678CRLF
12345678CR
----------------

        Tony Hansen
        tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html