-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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:
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
- --
Marc Mutz <mutz(_at_)kde(_dot_)org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE80sFJ3oWD+L2/6DgRAifHAKCiuoPG4tIoErrapAH26P5sRBRiIQCfUS3r
R++N3nYDzvGfdHUXlPD+l+A=
=ZZbO
-----END PGP SIGNATURE-----