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