ietf-dkim
[Top] [All Lists]

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

2006-12-22 16:51:17
Tony Hansen wrote:
I left off a sentence in Point 7.

Tony Hansen wrote:
Michael Thomas wrote:
Dave Crocker wrote:
: there are things in the
 real world which will cause more message signature to fail if we
make this change. You're not in favor of that are you?
Two lines of argument.  You were invoking the 'installed base'
argument and I was noting that it is not valid to use that, at this
stage, for this type of issue.
No I was not. My code up until very recently was making the same
mistake. What is strongly implied in the current draft offers
*superior* robustness in the real world. That is, it is immune to
additions *and* deletions of trailing CRLF's. That is not an appeal
to installed base, it's an appeal to a more robust spec. As it
happens, the spec merely needs to make more obvious what the
normative text already says and we will have an improved spec.
Michael, I don't see where you see the "new and improved algorithm" is
more robust in the face of deleted CRLFs than the proposed fix to the
dkim-base text?

Point 1:
        The original dkim-allman-base and dkim-ietf-base text called for
        trailing CRLFs to be deleted.

Point 2:
        The change to the text introduced in base-04 called for a
        CRLF to be added to a message that doesn't have a CRLF on its
        last line of text. In the process, it changed what happens when
        there is a message that only has trailing CRLFs. That base-04
        included a change to the existing behavior for handling such
        messages was missed by many people, myself included, until now.

Point 3:
        The discussions that led to the change in base-04 did not
        include any intent to change the default behavior when there
        are only CRLFs in the message body. Those discussions were only
        about what should happen with a message whose last line didn't
        end in CRLF. (Such messages are only possible when you are using
        a binary MIME content-transfer-encoding and a binary transport
        protocol.)

Point 4:
        The proposed text changes restore the behavior for when you have
        blank messages, as well as maintaining the change in semantics
        necessary to handle messages whose last line doesn't end in
        CRLF. (This includes the messages that have lost a trailing CRLF
        in transport.)

Point 5:
        No matter which option we choose, someone's going to have to
        change their implementation.

Point 6:
        My preference is to use the algorithm that's compatible with
        what was in dkim-allman-base-* and dkim-ietf-base-00 thru 03,
        while maintaining the change to handle messages with no final
        CRLF.

Point 7:
        Another way of expressing this algorithm that people may find
        easier to understand is:

        "If the last line of the message does not end with CRLF, CRLF is
        added. Then, CRLF 0*CRLF is reduced to a single CRLF."

        "If the body only consists of a CRLF after this reduction, that
        too is removed."
I have to say that this is even more opaque to me then what is in the
current draft.

I went through Charles' cases and I specifically didn't see the one that
I'm actually interested in:

before:

Last-Header: foo
<CRLF>
<CRLF>

becomes:

Last-Header: foo
<CRLF>

in transit. What I do know is that the current draft handles this case,
even though it's not entirely clear and could use an informative note
to make it more obvious. What's not clear to me is whether anything
new 1) has that property and 2) is any clearer than just adding informative
text to the current draft. Redoing normative text at this point shouldn't
be done lightly, IMO, and I really don't see what the gain is even if
your text works for this case.

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

<Prev in Thread] Current Thread [Next in Thread>