"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
Yes, the only problem we are dealling with here is confidentiality.
On the 'replace other headers', the problem there is that we end up back in
the rat-hole. People will propose all sorts of random headers ad infinitum.
And others will counter that there are integrity problems and then we have
the interop issue, etc.
I don't think that the problem is big enough to require a whole new S/MIME
spec to solve, just a minor tweak to implementations.
I agree that this is a problem for email clients, but I also believe
that this could be solved by implementation recomendations. Always
wrapping the intended mail as a message/rfc822 part inside the
encrypted part could be a solution. The problem with this seem to be
that most clients doesn't handle message/rfc822 in any intelligent
way.
While we are on the topic of MIME and encryption -- does anyone know
the history behind S/MIME not using multipart/encrypted of RFC 1847
for encrypted data? This decision causes some pain when implementing
a client that supports both PGP and CMS; S/MIME encryption becomes a
special case. Multipart/encrypted doesn't seem to have been discussed
here, judging by the mail archives at least.