Charles Lindsey wrote:
The example of interest is
C DATA
S 3xx end with dot
C Subject: lots of headers here, but I an just showing one<CRLF>
C .<CRLF>
S 2xx valid message received
That is a valid messge with an empty body. Stupid but valid and
therefore DKIM-base should tell us how to sign it.
So your notation was the SMTP client transmission. Forgive me if I
missed this.
Nevertheless, the storage is whats important, and based on our server
experiences, it could be one of the following depending on the server
idiosyncrasies:
headers:<crlf><crlf><crlf><eof>
headers:<crlf><crlf><eof>
headers:<crlf><eof> (Probably less likely)
I don't see the problem with SIMPLE c14n hashing any one of these.
Hashing the headers
is no problem; what to hash for the body?
In terms of the SIMPLE cl4n, they all yield a "<CRLF>" for hashing.
Isn't this the key point?
The alternatives are to hash <empty> which, with sha-256, gives
47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU
or to hash <CRLF>, which gives
frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY
But the first one isn't following SIMPLE c14n rules. Right? That would
be a
There are two questions:
1. Should absence of a body and an empty body result in the same thing
being hashed? I would have thought the answer to that would be a
resounding YES.
Sure, so whats the problem either way? I believe your question is
whether the originality of a single byte message is important?
2. Should the thing hashed in those two cases be <empty> or <CRLF>?
From my understanding, for SIMPLE c14n, they both have a <crlf> FEED to
into the hashing engine.
My preference would be <empty> (in both cases). I gather that
is what DK does, and what some implementations of DKIM do.
Then the DKIM implementations are not following the SIMPLE c14n rule.
No problem. Its all ALPHA ware, so they can fix it before production.
So, if <empty> is to be hashed, you can only write l=0.
If <CRLF> is to be hashed, you can write l=0, l=1 or l=2.
Which was part of my questions before about all this. I don't think l=1
is valid for a SIMPLE c14n algorithm.
The question is really about how important it is in preserving the
originality of the body data for a SINGLE <CRLF> byte message or lack
there of from a SMTP CLIENT transmission.
Regardless of how it is stored by the receiver, from a SIMPLE c14n
normalization standpoint,I don't see the issue as it is written and Eric
cleared up. The message body when canonicalized, all return <CRLF>
Maybe it would be clearer to have a dedicated section in the specs that
defines two new terms
DKIM MESSAGE
DKIM NULL MESSAGE
For semantic reasons, NULL or EMPTY is the same in terms of how the
message c14n. The difference with DKIM MESSAGE and 2822 MESSAGE is
that the DKIM MESSAGE is canonicalized. I think that a DKIM NULL
MESSAGE will have a constant hash (using your base64 output) of:
frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY
The section can describe that when L=2, then is exactly what the SIMPLE
hash should be.
Also, in 3.4.3, the sentence
It makes no other changes to the message body.
Should be changed to:
It makes no other changes to the HASHING algorithm feed.
In any case, I think it is overblown, because each SERVER will handle
the SMTP-DATA empty message in their own ways, and in my opinion, the
SIMPLE c14n rule does handle each one the same.
From my standpoint, I want to optimized the verification overhead. So
just consider the logic depending on L=X is:
L=0 no hashing of DKIM MESSAGE
L=1 indeterminate
L=2 DKIM NULL MESSAGE
---
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html