Frank Ellermann wrote:
Hector Santos wrote:
I'm not grasping the problem.
Apparently the canonicalization of "no body" (no CRLF CRLF) is
different from "empty body" (only CRLF CRLF). It's odd enough
to mention it in the spec. (maybe as note or example).
I think the issue is being overblown.
If your implementation treats "no body" like "empty body" and
other implementations don't we've to agree on one way to get
this right. Or rather Eric has to describe it unambiguously.
Doesn't both translate to a <CRLF> for the SIMPLE c14n?
From a signing standpoint, the signer implementation can decide for
itself if it wants to sign a DKIM NULL MESSAGE (one that canonicalizes
to <CRLF> only). So here, you will have either l=0 or l=2.
From a verification standpoint, the verifier has the design option to
look at the l=X value to check for any DKIM NULL MESSAGE consideration.
l=0 no hashing, bh= should be blank or not available
l=1 SHOULD NOT HAPPEN. invalid verification
l=2 DKIM NULL MESSAGE (see note 1)
Note 1:
The question here is whether we *SHOULD* allow a DKIM NON-NULL MESSAGE
to have a l=2 value. It is kinda ridiculous and it is the worst case
scenario for the Truncation Threat that is already documented in the
threats document. Example, even is a body canonicalizes to:
12345678<CR><LF>
12345678<CR><LF>
12345678<CR><LF>
12345678<CR><LF>
<CR><LF>
is a l=2 acceptable which means only the first 2 bytes are feed into the
hashing engine?
Maybe we can't do anything about this and it is what it is.
In any case, algorithm wise, I think it is clear at this point, with
Eric's additional changes.
---
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html