rfc2633bis and multipart/encrypted

[Marc Mutz <[e-mail]>]

-----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 <[e-mail]>, 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 <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE80pJ13oWD+L2/6DgRAqo+AKCEVWA8PCuwWhL9qqFHOWSGplgLVwCgxFDX
MEmwcc1Np37bsO8hTutUTSY=
=iZh1
-----END PGP SIGNATURE-----