There are several reasons for using a separate part. For one
thing, having different mechanisms depending on message structure
complicates matters rather than simplifying them.
Ok, that part makes sense. I'm not sure that it qualifies as an
overriding concern. All other things being equal, I would agree that
simplicity is better than complexity. On the other hand, I've always
found it annoying to have a plain ascii message wrapped up in
unnecessary encapsulation.
As I have already said, I completely fail to see where all this "unnecessary
encapsulation" is in the case of security multiparts. All that has to appear
before the body is a signed security multipart is the boundary marker and a
couple of blank lines. Compare this to your scheme, where you add two or three
additional header lines (MIME header fields don't count because you need them
either way.) Security multiparts can actually have less extra stuff at the
beginning that your scheme does, and will have comparable numbers at best.
Now, encrypted security multiparts do have a fairly large part with a bunch of
lines in it before the actual data. But so what? You can't read an encrypted
message without decrypting it first, so who cares what it looks like when you
don't have the necessary decryption software? You can't read it anyway!
This was something that caused a lot of
people to complain when NSB introduced encapsulation into the CMU
community when Andrew Messages was gaining popularity. If the
encapsulation actually improves the situation, that's a Good Thing.
Otherwise, it seems more like unnecessary bulk.
It can actually improve things by reducing the up-front bulk a bit.
But to my mind the biggest issue is the ability to process in a
single pass. You cannot do this if you use a header. You can if
you use a separate part.
I don't understand? A single pass from the beginning to the end of the
message could collect the signature before encountering the body and
could then verify the body as it is encountered. Am I missing
something?
Yes you are. You're only thinking about message reading and verification.
Messages have to be created and signed before they can be read and verified,
and the security multiparts scheme lets you create messages in a single pass.
You can even perform simultaneous encryption and signature in a single pass. As
a matter of fact you can perform multiple, simultaneous signature and
encryption operations, nested to any depth, applied at any point or points in
the MIME tree, all in a single pass. (My implementation actually supports this
sort of thing.)
Speaking as someone who has implemented support both for the content-md5 header
and for MOSS, where content-md5 works the way your proposal does, let me say
was considerably more difficult to deal with content-md5 in my implementation,
even though the actual underlying service is far simpler. (And has no real
value from a security standpoint.)
In my package, I collect both and then call out to PGP, but I would do
the same thing if I were implemented the security multiparts style.
How does the approach outlined in the IETF draft improve on the
approach which the X-PGP-Signed header uses?
See above. It operates in a single pass on both sides, for both signature and
encryption services.
My answer to the
opposite question is that it preserves the tradition role of the body
-- to hold the body of the message -- and of the header -- to provide
annotations that provide information about the body; who it's From,
what the Subject is, what the Date was when it was sent, etc.
You may be in line with some kind of traditional RFC822 usage (whatever
that is), but you could not be more out of sync with MIME philosophy if you
tried.
The MIME philosophy is to provide all significant additional services by
defining new content types. Existing MIME processors are designed so that its
extremely easy to add support for new content types. Since the security
multipart services appear as new content types adding support for them is
fairly simple.
It is far more difficult to add support for new services that manifest as new
header fields. (I should also point out that your proposal is actually in
violation of the formal MIME rules for such things since you used headers that
do not begin with "content-". This is, however, just a cosmetic issue, not a
substantive one.)
A much more serious and substantive issue, however, is that your proposal uses
new headers to effectively modify the actual nature of the MIME content in a
significant way. And this is very very bad indeed. For example, suppose I'm
operating a MIME<->X.400 gateway. I can easily tell such a gateway that a
multipart/signed or multipart/encrypted object should be left alone and
transferred as a monolithic entity -- any decent gateway implementation
provides for this sort of instruction on a type by type basis. But now you have
hidden this information in a new header field, a field a gateway will know
nothing about and, short of significant code changes, will simply be ignored
like any other nonstandard header.
The result will be that the contents of your signed objects will be converted
by the gateway, and such conversion processing is guarateed to destroy the
signature in any but the most trivial of cases. (A single part text/plain
message in the us-ascii character set with no "controversial" characters like
dollar sign might survive, but anything more complicated is likely to be
summarily trashed by either conversion to generaltext, conversion of
multipart structures into corresponding X.400 structures, or any one of
several other conversion steps mandated by RFC1496 and its brethren.)
Ned