Marc:
I recall a discussion about maintaining backward compatibility with S/MIME v2.
Russ
At 03:36 PM 5/3/2002 +0200, Marc Mutz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
I wonder why rfc2633(bis) doesn't mention (= doesn't allow) the rfc1847
way of
_encrypting_ mime entities, but describes mp/signed as _preferred_.
In message <ilu66752z6b(_dot_)fsf(_at_)dhcp128(_dot_)extundo(_dot_)com>, Simon
Josefsson wrote back
in December:
> 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
detection.
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
preferred
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
- --
Marc Mutz <mutz(_at_)kde(_dot_)org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE80pJ13oWD+L2/6DgRAqo+AKCEVWA8PCuwWhL9qqFHOWSGplgLVwCgxFDX
MEmwcc1Np37bsO8hTutUTSY=
=iZh1
-----END PGP SIGNATURE-----