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

[Michael Thomas]

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.com
>