Ned writes:
S/MIME has a major security hole in it -- a hole so big that people can
practically drive a truck through it
Thanks for the objective, technical comment that is so characteristic of
the discussion on this list. (Just like old times).
I expect to see lots of environments use remote verification services for
signatures, where messages are forwarded to a remote verifier.
I suspect that this will not be the case, but alas, the market will decide
for both of us. Also, I can't imagine why a remote verification service
can't return to the client the verified text. Perhaps you have some
additional insight into how such remote verification services will work.
While we're on the topic of multipart/signed versus multipart/alternative,
I'd like to bring up the next point that was made during the architecting
of the S/MIME spec.
The multipart/alternative construct was deemed more useful for backward
compatability to non-MIME readers. This is because the "alternative" part
is in readable ASCII. The use of multipart/signed infers a requirement
that the "signed" text be transported from sender to recipient intact. In
practice, this would cause a tendency to encode the text for transport
rendering it unreadable by non-MIME readers.