Excerpts from info-mime: 26-Jun-94 Re: Initial comments on dra.. Steve
Dorner(_at_)qualcomm(_dot_)co (953*)
The ONLY (tiny) check on the integrity of base64 is the number of = signs
on the end. If you allow people just to add a bunch of equal signs, you've
removed even that. And I'm not real happy about allowing random characters
in the middle of things, either. Who needs to do that?
Well, as far as I know this is what the spec has always said.
My current procedure is to warn users if these things occur.
I have no problem with that. If these things occur, there's almost
certainly a mistake somewhere.
content-MD5 is all very well and good, but it assumes the sender is going
to make two passes over the data; once to figure out the checksum and once
to send the data. (One of the nice things about the Mac BinHex format is
that the checksums come at the end, not the beginning.)
Yes, it would have been MUCH better to put the checksum at the end of
the base64 encoding. However, the design of base64 goes back to the
earliest versions of PEM; I'm not sure, but it possibly even pre-dates
MD5!
It is interesting, however, to put these two threads together. Since
everything after the = signs is ignored, we could conceivably define a
backwards-compatible extension to base64 in which there *was* a checksum
at the end, where older decoders will just ignore it..... This idea
intrigues me as an extension & future RFC, but NOT as a last-minute fix
to the final standard version of MIME. -- Nathaniel