[Fwd: Re: [ietf-dkim] canonicalized null body and dkim]
Bill.Oxley at cox.com
Bill.Oxley at cox.com
Wed Dec 20 06:18:42 PST 2006
This sounds fine
From: ietf-dkim-bounces at mipassoc.org
[mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Tony Hansen
Sent: Wednesday, December 20, 2006 8:06 AM
To: Charles Lindsey
Subject: Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]
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
> but I think Tony was saying all those should result in an empty body
> 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
> header fields from the body is NOT part of the body, and
> never presented to the signing or verification algorithm. In the
> of a pure binary message (such as one with a
> Content-Transfer-Encoding of 'binary') the concept of "lines"
> be meaningful. Nevertheless,
> wherever the pair of octets that represent CRLF happens to
> 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
> 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
> line counts rather than byte counts in an earlier message).
> Here is another example to amuse you:
> Last-header: foobarCRLF
> 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
and l=29 produces:
tony at att.com
NOTE WELL: This list operates according to
More information about the ietf-dkim