Again you have things backwards. Sure, it is possible to secure the non-MIME
subset of RFC 822 messages using your scheme. But what about when I want to
secure a MIME message? Your scheme doesn't work well, if at all, in this
case.
an example of this would be useful at this point in the debate.
Any composite MIME message provides a useful example. Take your pick. The
one in Appendix C of RFC1521 will do nicely.
Let's suppose I want to secure this entire message. Let's say I use security
multiparts to do it. I end up with something basically like this:
MIME-Version: 1.0
From: Nathaniel Borenstein <nsb(_at_)bellcore(_dot_)com>
To: Ned Freed <ned(_at_)innosoft(_dot_)com>
Subject: A multipart example
Content-type: multipart/security; type=signed; boundary=unique-boundary-0
--unique-boundary-0
Content-Type: multipart/mixed;
boundary=unique-boundary-1
This is the preamble area of a multipart message.
Mail readers that understand multipart format
should ignore this preamble.
If you are reading this text, you might want to
consider changing to a mail reader that understands
how to properly display multipart messages.
--unique-boundary-1
...Some text appears here...
[Note that the preceding blank line means
no header fields were given and this is text,
with charset US ASCII. It could have been
done with explicit typing as in the next part.]
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
This could have been part of the previous part,
but illustrates explicit versus implicit
typing of body parts.
--unique-boundary-1
Content-Type: multipart/parallel;
boundary=unique-boundary-2
--unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64
... base64-encoded 8000 Hz single-channel
mu-law-format audio data goes here....
--unique-boundary-2
Content-Type: image/gif
Content-Transfer-Encoding: base64
... base64-encoded image data goes here....
--unique-boundary-2--
--unique-boundary-1
Content-type: text/richtext
This is <bold><italic>richtext.</italic></bold>
<smaller>as defined in RFC 1341</smaller>
<nl><nl>Isn't it
<bigger><bigger>cool?</bigger></bigger>
--unique-boundary-1
Content-Type: message/rfc822
From: (mailbox in US-ASCII)
To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable
... Additional text in ISO-8859-1 goes here ...
--unique-boundary-1--
--unique-boundary-0
Content-type: application/pem-signature
... Signature data (which can be fairly long) goes here ...
... ...
... ...
... ...
... ...
... ...
... ...
--unique-boundary-0--
Now, this secured message has some nice characteristics:
(1) Its appearance isn't significantly different at the begininng from the
original, which is nice for readers that support neither MIME nor
MOSS (or any other security service).
(2) It will be properly handled by properly configured MIME readers and
gateways, regardless of whether or not they support MOSS (or whatever
security service you happen to have chosen).
(3) Security services support, if available, can be added in a modular way to
MIME agents. Additional security services are simply additional plug and
play modules.
(4) Individual parts could have been secured separately if desired.
(5) Variant forms can be used to secure and/or obscure portions of the
header if desired.
Now consider the alternative. I won't bother with the entire thing, but
it starts like this:
MIME-Version: 1.0
From: Nathaniel Borenstein <nsb(_at_)bellcore(_dot_)com>
To: Ned Freed <ned(_at_)innosoft(_dot_)com>
Subject: A multipart example
Security-blah:
... Signature data (which can be fairly long) goes here ...
... ...
... ...
... ...
... ...
... ...
... ...
Content-Type: multipart/mixed;
boundary=unique-boundary-1
This isn't nearly as nice, because:
(1) The begininng is much uglier. Ugliness at the end is nicer.
(2) The signature will be trashed by MIME gateways and will be unsupportable
in many, if not most, MIME readers. The only way to fix this is to add
specialized code to each gateway and to either add code or a special
front end processor to each reader. Moreover, the code will be completely
different depending on the actual security service used, so new code
will be needed every time a new security service is defined. (I do not
believe that PEM, MOSS, and PGP represent the end points in the evolution
of security services. In fact I see them as just a good start and not
much more. I have similar feelings about most currently defined media
types in MIME, for that matter.)
(3) Security services are completely ad hoc and cannot be built as modules.
(4) There's no way to secure individual parts.
i may well be forgetting something, but i thought that a MIME message
has to be 822-compliant (modulo ESMTP 8-bit transport).
MIME messages are indeed RFC 822 compliant, but so what? Its not exactly clear
what you are trying to say, but I'm guessing that you believe that since MIME
messages are a subset of RFC 822 messages, any scheme that can secure all of
RFC 822 has to work on MIME as well. If so, your reasoning is entirely
specious. The simplest counterexample is the fact that MIME agents currently
exist that process MIME messages in ways that are fundamentally incomptatible
with the needs of security services (i.e. they perform operations that
would break signatures).
As such, security services have to be made visible to such agents so they can
be properly handled. And since the only things that are generally visible to
such agents are MIME service elements, this argues very strongly for MIME
security services to be embodied as MIME service elements rather than as
generic RFC 822 service elements.
There's also the issue that the enhanced services MIME provides argue strongly
for comparable enhancements in security services, e.g. the ability to secure
only a part of a message.
what does securing the MIME message itself vs. securing the
822 body get you?
Well, for one thing, it gives you the ability to secure the headers of the
message as well as the body, if that interests you.
all i can think of is the ability to
decode a message that's been saved without it's headers.
that's not too exciting. so i must be missing the
better explanation that you have in mind.
See above.
Ned