The S/MIME Message Specification (8/29/95) does not speak to content
transfer encodings when using multipart/alternative. So, either it is
encoded, which may result in an unreadable message if an opaque
encoding (base64) is chosen, or it may result in a clear-text message
that does not correspond exactly to the signed message if no encoding
is used. If quoted printable is used for email that might not
otherwise make it through the network unscathed, the message will be
readable and will emerge at the other end of the pipe intact.
Your concern that a message might not make it through the network
"unscathed" is the same one I have about MOSS. Doesn't MOSS compute
the signature on the *encoded* data, the same data that won't make it
through unscathed?
Yes, but you're ignoring two important points here. FIrst of all, since the
encoded form is designed to be transferred without damage, it intrinsicly
avoids constructs *in the encoded format* that are likely to be changed by poor
transfer agents. Second and more important, the damage we're most concerned
about here doesn't come from poor transfer agents, it comes from powerful
agents that exercise user agent authority to convert messages from one format
to another. MOSS provides a clear indicator that such agents are supposed to
keep their hands off. There is no such indicator attached to the alternative
format used by S/MIME, nor can there be one as long as multipart/alternative
is used. In order for there to be one you'd have to use a different subtype
of multipart or add a parameter, which effectively duplicates the
multipart/signed approach.
Ned