All the details are fuzzy now. This is back far enough that I mostly
thought of you as some guy who's kid my girlfriend (now wife of 9
years) used to babysit :-)
What's really unclear to me is why any of this applies in any way to signed
messages using the security multiparts scheme. The signature appears AFTER the
message, not before. The only thing that appears at the beginning is the
boundary marker, which can be reduced to only one line -- not a big deal.
As such, the "lots of stuff at the beginning of the message" argument does
not seem to apply to the security multiparts scheme.
You also seem to assume that putting things into the main message headers hides
them somehow. This may be true on many, if not most, modern user agents, but
unfortunately there are plenty of agents out there that present the message in
toto. (In fact it is the existance of these agents that leads directly to the
summary removal of header fields from messages.) Your scheme is no better than
classic PEM in this instance, whereas the security multiparts scheme's
placement at the end of the body does avoid the clutter people dislike so much.
BTW, another advantage of the multipart approach over the headers
approach is that it has a lower likelihood of being destructively
mucked with by gateways to non-Internet mail systems.
That is true, but seems rather uncommon. In fact, I've had the
Subject: header get garbled far more often than the X-PGP-Signed
header.
Dream on! There are MANY list servers out there that think nothing of stripping
any header field they do not recognize. I see this happen to messages on a
daily, if not hourly, basis. Fortunately most of these critters have started to
respect content-type, MIME-version, and content-transfer-encoding fields. But
it took them five years to get this far. I'd just as soon not wait another
five years for security services, thank you very much.
In any case, this point suggests some circular reasoning. If the mail
systems to which you refer followed community standards, the problem
that you're suggesting wouldn't exist. That they're not suggests that
the standards shouldn't be overly influenced by them.
On the contrary, the point reflects substantial real-world experience and is
not circular at all. Removal of unrecognized header lines, especially
nonstandard X- headers, is actually quite common. It has taken a lot of
widespread community effort to get MIME's own headers into the "standard" set
for most of these systems. This is not an undertaking I plan to repeat -- I'd
much rather move forward with the mechanism we have already defined.
Ned