Subject: Re: rfc2633bis and multipart/encrypted

From: [email-masked] (Peter Gutmann)
Date: Sat, 4 May 2002 02:15:39 +1200 (NZST)

Marc Mutz <[email-masked]> 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.

(Having said that, multipart/encrypted is pretty clunky (signed data is a
 different issue).  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).

Peter.

---

From: Marc Mutz <[email-masked]>
Date: Fri, 3 May 2002 18:56:41 +0200

Maybe I should introduce myself first:
I'm a KMail (kmail.kde.org) 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 (www.gnupg.org/aegypten), 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:
> 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.

>  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

- -- 
Marc Mutz <[email-masked]>

---

From: "Blake Ramsdell" <[email-masked]>
Date: Fri, 3 May 2002 13:35:39 -0700

----- Original Message -----
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, May 03, 2002 7:15 AM
Subject: Re: rfc2633bis and multipart/encrypted

> bigger hammer, so S/MIME won.

This is mostly true.  Another part of this is that we ended up adopting
multipart/signed, and deliberately chose not to adopt multipart/encrypted
for some reason (which I think is what Russ pointed out as backward
compatibility).  I think the general argument was that it didn't add
anything to the protocol or the processing of the data, and the only thing
that it might add in our case is a potential clue to the processing agent
that "this thing is encrypted".  I thought there was a thread about this,
but I couldn't find it.

Blake