I recall a discussion about maintaining backward compatibility with S/MIME v2.
At 03:36 PM 5/3/2002 +0200, Marc Mutz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
I wonder why rfc2633(bis) doesn't mention (= doesn't allow) the rfc1847
_encrypting_ mime entities, but describes mp/signed as _preferred_.
In message <ilu66752z6b(_dot_)fsf(_at_)dhcp128(_dot_)extundo(_dot_)com>, Simon
Josefsson wrote back
> 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.
There was no reply.
The only references I could find about mp/encrypted and rfc1847 were some
comments about gateways breaking rfc1847, which is probably what the
respective comments in the final rfc reflect.
But given the rules for determining whether a given message is an S/MIME
message, anything that could conceivably be done to a mp/encrypted at
gateways would downgrade to the "filename extension" rule of S/MIME message
Thus, I don't see a reason to not use mp/encrypted - esp. as mp/signed is the
preferred mode for signing.
Can someone enlighten me?
If there are no reasons against it, I'd propose to include it as the
method of encrypting and define a new mimetype app/pkcs7-encrypted.
It will degrade gracefully since old MUAs should treat unknown multipart
subtypes as mp/mixed and by the file-extension rule, the app/octet-stream
with filename *.p7m will be recognized as part of a S/MIME message.
Marc Mutz <mutz(_at_)kde(_dot_)org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----