[ietf-dkim] canonicalized null body and dkim

Eric Allman eric+dkim at sendmail.org
Sun Jan 7 10:49:50 PST 2007


I have (finally) managed to slog my way through all the messages on 
this topic.  Let me start out by saying that I don't see the 
ambiguity in the current text:

        If there is no trailing CRLF on the message, a CRLF is added.
        It makes no other changes to the message body. In more formal
        terms, the "simple" body canonicalization algorithm converts
        "0*CRLF" at the end of the body to a single "CRLF".

So if the message ends without a CRLF (which should only be possible 
using CHUNKING) one gets added.  In particular, this is important 
because if a message is sent using CHUNKING through one relay and 
DATA through another, the CRLF will have to be added to get the 
<CRLF>.<CRLF>.

Based on the subject of the original message in this thread, the 
issue is actually what happens if the <CRLF><CRLF> separating the 
header from the body is missing.  Even that is (I think) well 
defined.  The first <CRLF> terminates the final header field and is 
required by 2822 --- that is, if it is missing then the message is 
malformed.  There is no reason that we should define this.  The 
second is the blank line that separates the header from the body, but 
it is not part of either.  If it is missing, then there is no body, 
equivalent to a body length of zero.  That clearly has no trailing 
CRLF, so one is added.  See the examples at the end of this message.

In an attempt to clarify this, I added the following at the end of 
3.4.3:

        Note that a completely empty or missing body is canonicalized
        as a single "CRLF"; that is, the canonicalized length will be
        2 octets.

The l= tag doesn't come into it, since the body is canonicalized 
before l= applies.  There does seem to be some confusion about this, 
so I made a one word change to section 3.7:

        In hash step 1, the signer/verifier MUST hash the message
        body, canonicalized using the body canonicalization algorithm
        specified in the "c=" tag and then truncated to the length
        specified in the "l=" tag.

Specifically, I added the word "then" to try to clarify that you 
canonicalize first, then truncate.

There was some discussion of back compatibility with DK, but this 
seems irrelevant given the addition of bh=, since that's a new, 
separate hash.

eric


Examples using DATA:

    INPUT                               OUTPUT (BODY MARKED)

    Field: foobar<CRLF>                 Field: foobar<CRLF>
    .<CRLF>                             ----
                                        <CRLF>
                                        ----

    Field: foobar<CRLF>                 Field: foobar<CRLF>
    <CRLF>                              ----
    .<CRLF>                             <CRLF>
                                        ----
    Field: foobar<CRLF>                 Field: foobar<CRLF>
    <CRLF>                              ----
    <CRLF>                              <CRLF>
    .<CRLF>                             ----

    Field: foobar<CRLF>                 Field: foobar<CRLF>
    <CRLF>                              ----
    .<CRLF>                             <CRLF>
                                        ----
    Field: foobar<CRLF>                 Field: foobar<CRLF>
    <CRLF>                              ----
    <CRLF>                              <CRLF>
    <CRLF>                              ----
    <CRLF>
    <CRLF>
    .<CRLF>
                                        ----
    Field: foobar<CRLF>                 Field: foobar<CRLF>
    <CRLF>                              ----
    baz<CRLF>                           baz<CRLF>
    <CRLF>                              ----
    <CRLF>
    .<CRLF>

Examples using BDAT (CHUNKING):

    INPUT                               OUTPUT (BODY MARKED)

    Field: foobar                       <error: undefined>

    Field: foobar<CRLF>                 Field: foobar<CRLF>
                                        ----
                                        <CRLF>
                                        ----

    Field: foobar<CRLF>                 Field: foobar<CRLF>
    <CRLF>                              ----
                                        <CRLF>
                                        ----

    Field: foobar<CRLF>                 Field: foobar<CRLF>
    <CRLF>                              ----
    baz                                 baz<CRLF>
                                        ----



More information about the ietf-dkim mailing list