Some more comments...
* 3.4.3 goes to great lengths discussing security implications of
the body length limit. I wonder if much of that discussion
shouldn't be part of the security considerations section.
In that discussion, cutting off a final MIME delimiter line
before the final "--CRLF" is suggested as a way to make sure that
additional MIME parts can be added, but that existing parts can't
be changed.
An attacker could add more characters to the delimiter line. That
would make the message invalid MIME (boundary parameters must not
include within a multipart's body), but I would expect many
implementations to just take these data as part of the final body
part. This may open up the way for attacks in the spirit of the
one described in 9.1.2.
* 5.2.2 says that MIME headers SHOULD be included with the
signature. That is good advice, but I would recommend turning
it into a MUST: When there are no MIME headers at all (but a
body length limit), then an attacker could add them and start
replacing messages (similar to the attack I described in January);
when there are MIME headers, then they are what controls the
interpretation of the message. Signing the body without the MIME
headers is an exercise in futility.
* 5.2.3 says that "Message attachments in MIME format MUST be
included in the content which is signed"; this immediately after
text that says that DKIM affords no special consideration to MIME
bodies.
The term "message attachment" is meaningless in a MIME context;
the sentence should be stricken.
(Note that attachments imply the existence of a single top-level
multipart/something MIME body, and that's already covered by the
previous sentence of the spec.)
I also wonder how 5.2.3 relates to the discussion in 3.4.3 about
not signing the content at all, or about signing just parts of it.
* 6.4 talks about MUAs "visually" marking unverified parts of
bodies, "in a distinctive font or color." Not all MUAs are
visual. I'd suggest to just say that MUAs may want to warn users
about what parts of a message are verified and what parts are not,
without starting to discuss the mechanisms by which this signaling
might be done.
Regards,
--
Thomas Roessler, W3C <tlr(_at_)w3(_dot_)org>