-- [ From: Blake C. Ramsdell * EMC.Ver #3.0.01 ] --
Date: Monday, 18-Sep-95 06:42 PM
From: Ned Freed \ Internet:
(ned(_at_)sigurd(_dot_)innosoft(_dot_)com)
Subject: Re: Re[3]: MOSS question
You can work around this, sort of, by doing what the S/MIME specification
recommends -- duplicate the entire content and use multipart/alternative.
However, this is NOT the same as providing direct access to the cleartext
--
all this does is make an additional copy of the cleartext and present that
.
The distinction is quite important because it gives rise to the two
problems
I have already described: (1) 100% overhead and (2) Serious potential
vulnerability because of the split between what is signed and what is
actually read.
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. 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 "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.
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).
Blake
--
Blake C. Ramsdell
Project Lead
ConnectSoft, Inc.
http://www.connectsoft.com