ietf-dkim
[Top] [All Lists]

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

2006-12-19 13:48:13
Stephen Farrell wrote:

How about this:

Informative Note:

The canonical text can be thought of as a virtual representation of the
actual input. In particular, a body without any lines (ie, a null body) is
canonicalized as a single CRLF, which its canonical length set to 2 (l=2). Note that the canonical length still applies to the canonical text so an input
of:

Last-Header:<CRLF>
<CRLF>

Would result in a length of 2 and a canonical body of <CRLF>.

If the l= parameter is specified and is set to 0,  the canonical text is
null. That is, the canonical text is virtually created, where the first
length octets (if specified, otherwise all octets) are presented to
the hashing algorithm.

      Mike

Ok, so we've this and we've that. Who's volunteering to
craft new text for the document?

S.

Michael Thomas wrote:
Tony Hansen wrote:
Michael Thomas wrote:
Tony Hansen wrote:
That's why the issue was raised.

I firmly believe that we *intended* to canonicalize each of these
cases into the empty body

Well, that may or may not have been the intent, but the current spec
does say that and it's my claim that what the current spec is doing
is *useful* given the mangling that happens in the infrastructure.
That is, we're getting better pass rates when we implement the spec
as it is written now.

Ah, but several of us are convinced that the current spec does *not* say
that and we want a clarification added one way or the other.

There's no one disputing that the current spec isn't useful.

If I read your message correctly, your implementation implements
canonicalizing a body with nothing but CRLFs into an empty body. Or is
there a missing "not" in your statement and I'm wrong?

My previous implementation did the same as Arvel's (given his recent
mail), which is the same thing that I think that Murray's  is doing. But
to be pedantic:

null body:

Last-header: foo<crlf>
<crlf>

l=2; canon-body: <crlf>

single crlf:

Last-header: foo<crlf>
<crlf>
<crlf>

l=2; canon-body: <crlf>

two trailing crlf's

Last-header: foo<crlf>
<crlf>
<crlf>
<crlf>

l=2; canon-body: <crlf>
*My* implementation does so. Arvel's does so.

But another implementation I know of changes it into a CRLF. Sigh. So we
are NOT currently getting compatible implementations with the current
wording.

Right. That was my reason to bring this up.
Back to intents: I believe the intent of the extra CRLF rule was to
handle transport modifications to the body that added an extra CRLF to
the end of the message. This was considered such a common modification
that we wanted to reduce the affects of it even in the simple
canonicalization mechanism.

Note that as I read the current draft, it also allows for the _removal_ of
trailing CRLF's too. Which is what I've seen in the field too. Note that
this isn't even a controversial point except for the question of null bodies, but the draft seemingly covers that too with its null rule, though it's not
very clear.

      Mike
Adding such an extra CRLF during transport could generate any of these
cases:

Last-header: foobarCRLF
CRLF

Last-header: foobarCRLF
CRLF
CRLF

Last-header: foobarCRLF
CRLF
CRLF
CRLF

and they MUST be treated identically because you can't tell which of
those CRLFs were original and which were added later.

So, I believe that the intent was: 1) to strip out all trailing CRLFs.
2) If there *is* body content other than those CRLFs, the last
non-CRLF-only line would be guaranteed to have a CRLF at its end.

And 3.4.3 needs to be adjusted to guarantee that intent.

    Tony Hansen
    tony(_at_)att(_dot_)com

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


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

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