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

[Tony Hansen]

Hector Santos wrote:
> 
> 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?

No.

The canonicalization is done *FIRST*. Then exactly l= octets of that are
presented to the hash algorithm.

> What I am now hearing is this, given 50 REAL bytes
>
> 12345678<CRLF>
> 12345678<CRLF>
> 12345678<CRLF>
> 12345678<CRLF>
> 12345678<CRLF>

ok

This is canonicalized using SIMPLE into:

> 12345678<CRLF>
> 12345678<CRLF>
> 12345678<CRLF>
> 12345678<CRLF>
> 12345678<CRLF>

which is the exact same thing that went in. The last line already has a
CRLF at its end, so no additional CRLF needs to be added.

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

The octets shown here are exactly what would be fed to the hash.

> If the CRLF is part of the final feed, then the l=25 text would be:
>
> 12345678<CRLF>
> 12345678<CRLF>
> 123<CRLF>

No, the CRLF being discussed is the one that's added as part of the
canonicalization process if the last pre-canonicalized line did not have
a CRLF present. It's *NOT* one added after the canonicalization is
completed. So what you're showing here would NOT be what is fed to the
hash algorithm.

	Tony Hansen
	tony at att.com