RE: the 8-bit dilemma
Michael Elkins (elkins@aero.org)
Wed, 28 Feb 1996 14:21:21 -0800
On Feb 28, "Edward A. Russell" <erussell@ftp.com> wrote:
> Reply to message sent by Michael Elkins on 2/28/96 at 1:15:52 PM
> >If you don't do that, then the content-type of the object that you are trying
> >to protect is visible. This is NOT acceptable.
> >
>
> It is to people who want to support IMAP download of known content types (even if the
> content itself is encrypted). Perhaps an optional parameter which allows hiding the content
> type or not.
There isn't a way to do that under the RFC1847 scheme. Also, you'd have to
encrypt each leaf object separately in order to accomplish that (sort of
like a C-T-E).
IMAP is a problem for what you want to do with it. However, you won't be
able to control what people _send_ to you, so having an optional parameter
will not help. I can guarantee that you will receive mail with the
Content-Type hidden.
> >A lot of people here have this same opinion but I haven't seen anyone
> >suggest
> >an alternative that _works_. I'd like to see how you propose to define a
> >security system that workd irrespective of MIME (i.e., outside of a MUA).
> >What you are suggesting sounds a lot to me like the current state of PGP
> >with
> >detached signatures. The problem with doing things this way is that you
> >have
> >absolutely no way of signing the content-type that corresponds to the object
> >you are signing.
>
> Do you mean signing the fact that this is an audio object for example? So I would know if
> someone changed the type from audio to video? That seems like a fairly esoteric benefit
> when weighed against the fact that I am unable to save encrypted or authenticated objects
> to disk and then use them outside of my mailer. I DO use the seperate signature and it is
> quite nice because I can save both the disk and authenticate them anytime outside of my
> mailer. You are correct, I would not be able to authenticate the original MIME type. Doesn't
> feel like a big deal, but I admit I may only be seeing my own viewpoint of the world.
It _is_ a big deal for any automated message processing, and even for a lot
of MUAs. You could receive an altered piece of mail that gets ignored...
Suppose, for example, I send you a very urgent piece of information and its
labeled text/plain. Along the way, someone intercepts the message and decides
that it would be disastrous for them if you read my message. So they alter
the message content-type (knowing that they can't alter the message) to
audio/basic. Now, your ultra-cool-snazzy-MUA has built-in audio and when
it sees the audio/basic it sends off the text/plain data to the sound player
instead of displaying the message to you... Hence, you've been denied
access.
I agree that for certain data it is quite nice to have a separate signature.
However, the problem comes in that it is difficult to keep the binding
between the signature and data when in transport. I believe that this sort
of thing needs to be handled _separately_. For example, if I wanted to send
you a binary that was signed, I would create a detached signature and send
you a multipart message which consisted of the binary and the signature. Then
you'd be free to extract those from the MIME message and use them outside
the MIME infrastructure.
But suppose I put the binary on an anon-ftp site. Then I could send you
a multipart message that consisted of message/external-body and a signature
that you could use to verify that the binary was not modified. Or I could
have the signature reside on the anon-ftp server as well and send you
pointers to both files.
I'm dubious of an attempt to define some sort of MIME type to bind a
signature to an arbitrary file in this manner. Such a mechanism would fail
to meet you criterion of working outside the MIME framework. However, I
hope my example illustrates what I mean by the differences between OBJECT
and MESSAGE (or TRANSPORT) security.
> I always thought of transport security as being handled by Secure Socket Layer. We are
> moving the concept of "transport" up a little into the application space. I'm not sure what
> OBJECT security would be seperate from PGP, etc. I would hope not yet another wrapper of
> security.
This would be nice, but alas, not everyon has SSL availible. I suspect it
will be quite some time before we can ignore connection insecurity.
--
Michael Elkins <elkins@aero.org> http://www.cs.hmc.edu/~me/index.html
PGP mail preferred. Key availible via web or 'finger -l me@cs.hmc.edu'
Key fingerprint = EB B1 68 32 3F B5 54 F9 6C AF 4E 94 5A EB 90 EC
"I could be wasting my time more productively than this." --me