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