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.
I would hardly call "security by obscurity" intriguing.
Your comment "can only succeed in an environment where the
application/pkcs7-mime part is not interpreted" is, in fact, false.
When processing multipart/alternative, when the display of the
"preferred" part fails, processing moves to the "next most preferred"
part. Thus, when processing application/pkcs7 fails, the MIME agent
simple moves on and displays the part anyway. Multipart/signed does not
have this liability.
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).
As I just stated above, the behavior of S/MIME in multipart/alternative
and multipart/signed is, in fact, different in environments where the
protocols are supported.
Further, unless a MIME agent has some specialized builtin functionality,
users sending application/pkcs7 must take explicit action to create the
multipart/alternative option for all their recipients. Multipart/signed
does not have this liability, either.
Jim