...
100% overhead is not an issue in some people's minds (including mine, now that I'm on a T1) ;). Modern mail UAs work just as fine with 4K messages as they do with 2K messages. Modern servers can store lots of stuff. Modern networks can transmit lots of stuff.
MIME is multi-media mail. Sometimes folks forget that. While the 1K and 2K text-based message will be with us far into the future, MIME makes it possible to send PostScript files, spreadsheets, images, sounds, etc., and any of these could easily bring the size of a message up to 10K, 100K, a meg, or more. Doubling and then some the size of these messages is significant. Then there's the problem of users wanting to forward signed messages in toto and sign the forwarded message, perhaps with additional content, themselves. Very easy and with little overhead with MOSS. With S/MIME, this doubles and then some the message again.
The number of messages you receive a day had better not add on more than a minute or two to the transmission time (with 30+ messages), even over a 14400 dialup. And that's only if *everyone* used S/MIME for *every* message.
The contents of messages will become richer and richer, larger and larger. Maybe not all messages, but enough to sway the average. Once the infrastructure is in place, why wouldn't folks sign most, if not all, messages by default? Assuming there's no observable penalty for the signer, wouldn't most people just click the "sign by default" button in their setup screen and be done with it? Much better than forgetting to sign something that must be signed. Set and forget is the way most folks like it. We've set up our admin people with our software and watched. Programmers and other tinkerers are the minority. As more user agents, especially the pointy-cliky kind, become MIME aware, the size of messsages is going to grow quickly. Just look at the WWW to see what I mean. Doubling the size of large messages will be noticeable.
The "split between what is signed and what is actually read" is more of an intriguing issue. I think what you're suggesting is that the plain text part of the multipart/alternative S/MIME message can be modified to violate the integrity, which can only succeed in an environment where the application/pkcs7-mime part is not interpreted. However, this same problem exists in other environments *including* multipart/signed, since the plaintext in these environments is also available. It's the nature of the beast.
While it's true that the signature on a multipart/signed might be invalid, and a person without MOSS-aware software may not know that, the underlying message does not change based on the software used. Social factors aside, without software to verify a signature, a signature is meaningless. The problem with S/MIME is that two recipients of the same message may see totally different message bodies using the multipart/alternative scheme. I suppose that's always a problem with multipart/alternative, signed or no, but in the signed case it takes on a special significance.
So it seems that both multipart/signed and S/MIME have the same limitation - - in an environment that does not implement the protocol, you can have modified content. However in both cases, if you have an environment that supports the protocol, you will be assured that the content is the same that was sent (in the case of S/MIME, however, the message text will be extracted from the opaque application/pkcs7-mime part).
But in the S/MIME multipart/alternative case, the recipient of a signed message, being able to verify or not, doesn't know what the contents will look like to someone in the other boat. There are many tricks someone might play with a message. The duplication of the message body without a signature in S/MIME opens the door to additional tricks. Mark
binpKQClMcJd9.bin
Description: application/moss-signature