[Top] [All Lists]

Re: rfc2633bis and multipart/encrypted

2002-05-03 09:57:25

Hash: SHA1

Maybe I should introduce myself first:
I'm a KMail ( developer and responsible for the next-generation 
message handling code that will creep into KMail over the next months.
As such, I'm partly remotely, partly directly involved in the Aegypten Project 
of the German government (, which aims to bring S/MIME 
support to the well-known OpenPGP imlementation GnuPG, and incorporate 
support into OSS mail clients, chiefly KMail and mutt.

On Friday 03 May 2002 16:15, Peter Gutmann wrote:
Marc Mutz <mutz(_at_)kde(_dot_)org> quotes:
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?

Politics AFAIK.  The encryption stuff in RFC 1847 was part of the MOSS
worldview, and MOSS != S/MIME.  At the time, RSADSI and the RSA patent were
a bigger hammer, so S/MIME won.

The few arguments for using an application subtype for encrypted/signed data 
and CRLs are handwaving at best.
Now we implementors are stuck with a - let's say - suboptimal solution and the 
clean solution is disallowed by not even mentioning it in the RFC.

What are arguments against including
multipart/encrypted; protocol="application/pkcs7-encrypted"
with a "MAY create / SHOULD understand" in the successor of RFC 2633?

This would at least open the door for adoption in the future.
Then S/MIMEv2 -> S/MIMEv3 transition seems to have had some potentially much 
more grave disruptions than introducing mp/encrypted.

(Having said that, multipart/encrypted is pretty clunky (signed data is a
 different issue). 

- From an implementor's POV, multipart/encrypted is by no means "clunky". Yes, 
it adds an outer and an inner body part of hot air around the interesting 
stuff, but the headers of the "hot air" body parts are what counts. They 
contain the information used by the MUA to dispatch the content to the right 
backend crypto engine. What's more, it allows MUAs to guess (rightly so) that 
what comes back from the crypto engine is only another mime entity (something 
that needs further processing by the MUA itself), while that isn't at all 
clear when using application/pkcs7-mime. There, the MUA doesn't even know 
whether it's an CRL, a signed document, an encrypted document or simply 
CMS-wrapped data without cryptography. :-( (Without particular knowledge of 
S/MIME, that is.)

I understand that some (to me obscure) gatewaying and backwards compat issues, 
paired with politics, have prevented the inclusion of an elegant solution. 
app/pgp has been deprecated - and successfully so. Time to try the same with 
app/pkcs7-mime, I'd say.

OTOH given the perpetual-motion-machine nature of
debates over this in 1995-1996, it's arguable that any decision would have
been regarded as bad by some subset of people).

Back at politics, then... :-(


- -- 
Marc Mutz <mutz(_at_)kde(_dot_)org>
Version: GnuPG v1.0.7 (GNU/Linux)


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