While we're on the topic, could you refresh my (our) memory about the
reason for having encrypted done as a multipart rather than a single
body-part?
The reason is quite simple -- consider what happens when you have
multipart/mixed in the first part of multipart/encrypted.
Encryption services tend to use some form of symmetric encryption with a
per-session key to secure the actual content. This per-session key (I believe
PEM and MOSS call it the interchange key, or IK) is then itself encrypted using
some other mechanism, typically (but not always) a public assymetric scheme.
The key interchange protocols vary widely, but the underlying interchange
service does not -- DES is the most common right now and I expect that either
triple-DES or Blowfish will become the method of choice in the future. (IDEA
seems an unlikely candidate given its patent status.)
Suppose you are sending an encrypted message to mutiple recipients. Suppose
further than they do not all share a common security service. Some use MOSS,
others use PGP, and still others use a service based on private symmetric keys
(i.e. a shared secret).
Simple encapsulations require that you encrypt the message once for each
service and send out separate copies to each group of recipients. This can be
very expensive to do, especially as the number of services grows (as it
seems inevitable it will). The overhead in terms of message copies is also
high, and this is getting to be a major factor given the growth in average
message size.
But now consider what happens with multipart/encrypted where the various
underlying services all support a common interchange service. Now all you have
to do is generate a single interchange key, package it up in mutiple forms
using the various services, build a multipart/mixed element that encapsulates
all of this information, and finally encrypt the message once for all of the
recipients and send it.
This is why we defined multipart/encrypted the way we did. We were looking
towards a future where enough of the services shared common interchange
technology that this could be made to work. And such a future may not be as
far off as you might think -- I've heard talk that PGP will support triple-DES
as an option in the future, and I suspect MOSS will do so as well. In any
case, adding support for multiple symmetric schemes at the interchange level
so as to achieve interoperability is a much simpler thing than reconciling all
the higher-level details, which often as not is flat-out impossible.
I understand (and very much like) having signed done as a multipart,
since
it factors out the security goo into a separate body part, leaving the
clear and readable message to be processed in usual mime fashion.
For encrypted, such separate processing isn't possible since the message
is opaque. What is the reason, then, for keeping the security control goo
separated into a different mime body part from the encrypted data goo?
See above. The counter-argument is that the multipart/encrypted scheme exposes
too much information -- its more comfortable for some people for the encrypted
material to simply be an anonymous, opaque blob. With all due respect to Phil
Zimmerman, who first advanced this notion to me, its nonsensical. Relying on
the blob effect to hide what's key and what's data is nothing but security by
obscurity. And as for hiding the use of encryption, the requirement that we
label things for what they are so that automatic processors can deal with them
pretty much blows that away at the outset.
In spite of having suggested the generic approach for using multipart, I
don't remember the reason for applying it to the encrypted mode. Folks ask
me periodically and it's embarassing not to know. A 10-second tutorial for
me(us) would be helpful.
Again, see above.
I am sympathetic to the use of formats where the encrypted data cannot be
easily teased loose from the rest. In this case I advocate using a
multipart/encrypted with a blank first part. Its ugly and its loses most of the
benefits of multipart approach, but at least you don't have to add additional
dispatch capabilities to your MIME agent when new subtypes are defined.
Ned