Date: Fri, 05 May 1995 17:16:44 -0700 (PDT)
From: Ned Freed <NED(_at_)SIGURD(_dot_)INNOSOFT(_dot_)COM>
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.
That is the unnecessary encapsulation to which I'm referring. The
body part of a message has previously been used to contain the body of
the communication. The header part of a message has previously been
used to contain annotations about the communication. A digital
signature is an annotation about the body.
Now, encrypted security multiparts do have a fairly large part
with a bunch of lines in it before the actual data. But so what?
I have not argued against any aspect of encrypted security parts.
> 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 . . . .
Thank you for the clarification.
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.
Perhaps. I've tended to view MIME as a necessary evil for dealing
with extensions beyond the original scope of 822. Digitial signatures
don't qualify, however, which in my mind makes a MIME role an
*unnecessary* evil, i. e. something to be avoided.
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.)
My headers conform to 822 and I was under the impression that MIME
also conformed to 822. If MIME is not 822 conformant, then I stand
corrected.
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.
I would choose to charactize them as avoiding MIME in a situation
where it is not needed, rather than modifying the nature of the MIME
content. There is no need for `MIME content' to be involved in the
situation at all.
. . . such conversion processing is guarateed to destroy the
signature in any but the most trivial of cases.
What I have been addressing throughout this thread is that the
security multiparts proposal turns a trivial case into a complex one
unneccesarily. I have been addressing the trivial case *because*
there is no need for the added complexity.
I seem to be outside of the MIME philosophy, primarily, because I
believe that complexity for it's own sake is not progress.
Rick