In message <v04003a0bb0f55a766a11(_at_)[38(_dot_)168(_dot_)136(_dot_)14]>you
write:
i would like some clarification on this as well, including, but not
limited to, whether this is relevant to the following circumstance:
person A receives a message & attachment signed by person B (perhaps
from a previous email) and forwards this along to person C. of course,
person A wants to put his own signature on the entire email, so person C
is sure where the forwarding message came from.
in general, how does a user forward a message such that the recipient
can prove that (a) the original message came from the purported original
sender, and (b) that this forwarded message and any additional
text/attachments are from the purported forwarder/intermediary.
There's a mime-type called message/rfc822 for embedding messages in
other messages. This is available in Exchange through the
Insert->Message option, and presumably in Messenger by some means that I
can't immediately find, and it is for this purpose. If you attach a
signed message your own and secure your message, then whatever
processing activates when the recipient opened your message should
activate when they open the attachment. The obvious issues about
forwarding encrypted mail apply.
As regards securing individual attachments, I'd have reservations about
expecting users to correctly interpret a message with differently
secured sections. They have enough trouble understanding that a message
encrypted to them hasn't neccesarily come from the claimed sender.
Getting them to deal with a message whose component parts, though
secured, may have an insecure relation to each other seems more trouble
than it's worth. Certainly, no-one's ever asked us for this.
After a bit of searching, I found some email on this, from Ned Freed, on
4th February 1996:
----
In a subsequest offline discussion, it was suggested that we promote
the model where each body part in a multipart message is encrypted
separately thereby creating a separate S/MIME body part for each
original body part. Although this increases the overhead in the
replication of the key management information, it has the advantage in
remote access situations (eg. IMAP) that each resulting S/MIME body part
is self-contained and can be downloaded and processed independently.
Sigh. How many times do we have to go over this?
This is pretty marginal in the case of encryption and absolutely
unacceptable in the case of signatures. The problem in the encryption
case is that internal message headers and structure are exposed. This
can be a very significant exposure in some situations.
The problem with signatures is far worse. The standard example is the
three part message with a first that says, "The first attachment is the
version of the contract to use, the second is the crappy one that should
never have seen the light of day." The parts can be swapped without
detection if they are signed separately. Enough said.
Ned
----
Andrew.