Re: States and the 8 bit dilemma

Brad Knowles (brad@azathoth.ops.aol.com)
Thu, 29 Feb 1996 20:44:07 -0500 

On Feb 29,  2:09pm, A. Padgett Peterson P.E. Information Security wrote:

> Derek RIP (rites in part)
> >	1) I am sending a complete multimedia message and I want to
> >sign the whole shabang.  In this case the best way to do it is to
> >format the message and sign the whole MIME content (c.f.
> >multipart/signed).  This is message security.  I want the recipient to
> >be able to verify that this is the message that I intended to send.
> >Complete.

    Right.  Wrap this up as a MIME object, then sign (and/or encrypt)
that object and put it into a multipart/{signed|encrypted}.

    If you just want to sign and/or encrypt a particular object (say a
picture) and you don't care about the rest, then wrap up the picture
as a MIME object, then sign and/or encrypt it and put that into a
multipart/.


    In other words, an entire MIME message (all originating headers
included) should be able to be considered as a single MIME object that
can be signed and/or encrypted and wrapped up in a "multipart/" type
which can further be enclosed as a MIME object in another message.

    If you sign a whole MIME message, then when you decrypt and/or
verify the signature, the internal headers should be used to replace
the external headers.


    This implies that a MIME object/message must be seven-bit
transformed before either being transmitted via SMTP or included as
part of an enveloping MIME object/message.

> When we talk about multimedia, most of the elements range from not-very-
> compressable (GIFs) to pretty compressible (text) to highly compressible 
> (JPEGs).

    But JPEGs have their own internal (lossy) compression algorithm,
which eliminates most if not all of the external compression (RLE, LZ,
whatever) that you could apply, don't they?  I thought that ASCII text
was pretty much the most compressible type of object we were ever
likely to see....

>          When considering total bandwidth, this is important. The prime
> factor is that both compression and encryption stages result in a container 
> that is highly random. Therefore, an ASCIIrizer transport mechanism to be
> efficient, should not use MIME which is optimized for formatted text, but 
> rather something optimized for use with random binary.

    Compression should definitely (IMO) be used before encryption, but
I think we want to avoid it (for obvious reasons) on data that has
only been signed.  However, we'll need to also consider algorithm
entanglements with patents and licensing issues.  Perhaps gzip could
become the standard compression algoirhtm, if we could get certain
parts of the copyleft modified?

-- 
Brad Knowles                           MIME/PGP: BKnowles@aol.net
    Mail Systems Administrator          <http:www.his.com/~brad/>
    for America Online, Inc.                   Ph: (703) 453-4148