Date: Wed, 03 May 1995 19:11:36 -0700 (PDT)
From: Ned Freed <NED(_at_)SIGURD(_dot_)INNOSOFT(_dot_)COM>
> In reading through the document, I didn't notice any mention of the
> reasoning behind forcing the signature on a 7bit ascii message into
> the body. This seems like a case where multiple parts are unnecessary.
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. 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.
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?
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? 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.
Rick