At 14:41 10.07.98 -0700, Ned Freed wrote:
I think a better way to resolve this problem is to define a different
canonical
form for use in computing hashes. (The key characteristic of the new form
needs
to be that the hash of part data is done under the encoding.) This could be
indicated in the micalg field by a different hash name. I've been meaning to
write an RFC defining such a thing for quite some time but haven't managed to
find the time to do so. This is also hard to deploy, but has the added
benefit
of resolving a different problem, specifically that message stores have to
store both encoded and decoded parts when handling multipart/signed. Many
people believe this is a far more serious problem than an occasional
signature
mismatch caused by poor encoding choices, enough that we might just possibly
get some buy-in and some resulting deployment of such a mechanism.
by "under the encoding" you mean that the hash is computed across
the canonical form of the body part, and thus can only be applied to
leaf body parts, and leaves headers unprotected? Or something different?
One version that would have a chance of "solving a different problem"
would be making the signature into a variant of the "packing list" scheme
found in some other mail systems, sort of like:
Content-type: application/grotty-signature-scheme
1 header 310874609872134
1.1 header a1349563876bc3f
1.1 body 7bit a38483413467
1.2 header 109875660924
1.2 body 8bit 1934710966
which would allow an MUA to say things like:
"The headers of the enclosed message (part 2) were damaged in transit.
The content of part 2 is FUBAR, probably because the idiot sender
sent it in 8bit and the brain-damaged firewall downgraded it even
though the RFCs say you can't".
Security-wise, it allows you something like "a little bit pregnant".....
Harald A
--
Harald Tveit Alvestrand, Maxware, Norway
Harald(_dot_)Alvestrand(_at_)maxware(_dot_)no