[Top] [All Lists]

rfc2633bis and multipart/encrypted

2002-05-03 06:37:28

Hash: SHA1


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 

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 Mutz <mutz(_at_)kde(_dot_)org>
Version: GnuPG v1.0.7 (GNU/Linux)


<Prev in Thread] Current Thread [Next in Thread>