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

[Hector Santos]

Except when its from a trusted source? <g>

** Happy Holidays **

---
HLS


Bill.Oxley at cox.com wrote:
> You are correct l=N should be avoided at all costs :-)
> 
> 
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org on behalf of Hector Santos
> Sent: Fri 12/22/2006 7:39 PM
> To: Charles Lindsey
> Cc: DKIM
> Subject: Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]
>  
> Charles Lindsey wrote:
>> On Thu, 21 Dec 2006 17:55:41 -0000, Hector Santos 
> 
>>> if l=2,  that means two <CRLF> were hashed.
>> But that case cannot arise with the text proposed.
> 
> But what if it is l=2, what if that is what the VERIFY sees?  It means 
> whether truly BYTES exist or not, these two hashable bytes must be 
> <CR><LF>.
> 
>>> if l= missing, that means at minimum two <CRLF> were hashed.
>> No, it means whatever the canonicalization produced would be hashed, 
>> which would be <empty> in this case.
> 
> Ok, again, we are talking VERIFICATION here. If no l= tag is specified 
> as part of the DKIM-Signature: header, the specs says the "entire" body 
> is hashed. Therefore, according to what I am reading, if the body is 
> indeed DKIM-NULL (empty after any <CRLF> trimming) then 2 bytes <CRLF> 
> will be hashed.
> 
> Are you saying there SHOULD be no hashing and therefore no b= tag?
> 
>>> If l=0, no hashing was done.
>>>
>>> It sounds to me, that technically, the bottom line the SIMPLE c14n feed
>>> must end with <CRLF>, period.  If missing, it is added to the feed.
>> No!
> 
> No?
> 
>  > Magically appearing empty line with CRLFs are _precisely_ what we
>  > are trying to avoid.
> 
> No line is magically appearing here.
> 
> Based on the current SIMPLE c14n specs, it would be FEED into the 
> HASHING ENGINE if it didn not exist as part of the original feed.  It is 
> not added to the original source.
> 
> What I am now hearing is this, given 50 REAL bytes
> 
> 12345678<CRLF>
> 12345678<CRLF>
> 12345678<CRLF>
> 12345678<CRLF>
> 12345678<CRLF>
> 
> if l=25, then the hashing feed is:
> 
> 12345678<CRLF>
> 12345678<CRLF>
> 12345
> 
> and it does not include the expected final <crlf> which would currently 
> required during a SIMPLE c14n signing process.
> 
> If the CRLF is part of the final feed, then the l=25 text would be:
> 
> 12345678<CRLF>
> 12345678<CRLF>
> 123<CRLF>
> 
> No?
> 
> ---
> HLS