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

[Michael Thomas]

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.com
>>>   
>>
>> _______________________________________________
>> NOTE WELL: This list operates according to 
>> http://mipassoc.org/dkim/ietf-list-rules.html
>>