From: elkins@aero.org (Michael Elkins)
Date: Tue, 21 May 1996 15:05:27 +0800
To: pgp-mime@purpletape.cs.uchicago.edu
Subject: Re: PGP MIME INTERNET DRAFT considered harmful.
In-Reply-To: <832582505snx@hrnowl.lonestar.org>
Message-ID: <199605201710.KAA23072@muddcs.cs.hmc.edu>
MIME-Version: 1.0
Content-Type: text/plain


[Note: CC'd to the pgp-mime list.]

Paul Elliott writes:
> [Encrypted & Signed binary data.] 
> Now when there is a data path for PGP's cyphertext, PGP provides a
> binary data path for its plain text. Thus, the inner base64 that PGP
> MIME internet draft requires is totally unnecessary. It will cause a 30%
> increase in the size of those messages that are encrypted and signed and
> large amounts of CPU time will be used applying & removing the base64.

This design decision actually serves a purpose.  The scenario is as
follows:  Suppose you are a company which has west-coast and east-coast
offices, and the only connectivity which exists is via the open Internet.
Suppose further that you wished to send out a company memorandum to all
the employees.  Obviously you will want to sign and encrypt your message.
However, one it reaches your offices, you would like to have the encryption
"layer" stripped leaving just the signed message.  Now, if when you generated
that message you did not restrict yourself to 7 bits, there is a likely
probability given todays software, that you are not going to be able to
transmit that message over an SMTP framework.

Now, this does present some bloat for people who do not strip the encryption,
but it seems far better to design the protocol such that this case will
work.

> [Signed binary data.]
> Now let us consider the question of what PGP-MIME draft requires users
> to sign. Suppose we want to send a signed .gif file to a sysop. The
> sysop wants to store the .gif in his download section. Suppose the sysop
> wants to store the signature as a detached signature so that people who
> download it can check the authorship. But the signature proposed by the
> PGP-MIME draft is useless for this purpose. It has MIME headers attached
> and it has been base64'ed. People who download such a file from a BBS
> have no use for it, unless they have MIME.

[...several other examples deleted...]

PGP/MIME is _not_ meant to be used in this fashion!  It never was!  PGP/MIME
is only to be used for transport, not for long term storage.  If you need
a persistent signature, you should generate a detached signature as an
attachment.

> If users get in the habit of signing binary files which represent
> multimedia data, and which can not be examined with commonly available
> inspection tools, it is inevitable and predictable that sooner or later
> this will cause some kind of negative security event.

By this argument nobody should bother signing e-mail or news posts.  I
haven't seen any good tools to handle this easily for PC's and Macs.
New proposals have to be made before the tools become available.  This
draft is the result of experience with what does and doesn't work.
For example, the application/pgp content-type which many people like
is horribly broken for what it's probably used for 95% of the time.

> There is no good reason to sign the base64 rather than the original
> data. Once a file has been base64ed, the file can not be examined
> with the usual inspection tools.

Yes, base64 is just another stream of bytes, but there are FEW places on
the Internet SMTP framework that can support BINARY transport.  BINARY
streams often contain very long lines which existing software simply can't
handle.

There is also another reason to sign the encoded version.  Remember that
it also includes the content headers of that part.  This is very important
especially for automated processing of messages.

> The typical user of MIME software is not necessarily technically
> sophisticated. When the deficiencies and disasters associated with
> software patterned on this draft become apparent, not everyone will know
> exactly which software component is at fault. The problems associated
> with the draft (or its successors) may adversely affect the reputation
> of PGP.

Bad implementations can always adversely affect your reputation, even if
the theory behind it is solid.  The average non-technical user which you
have been describing in this message will should not even be aware of
the underlying details if the implementation is done correctly.

> The draft should be withdrawn. People should rethink and create a better
> plan to combine the benefits of PGP and MIME.

You are more than welcome to submit your proposal the the pgp-mime mailing
list.  [send mail to pgp-mime-request@lists.uchicago.edu with a subject of
"subscribe"]

We've seen a lot of different proposals go by, and none of them have stood
up to PGP/MIME.  From my point of view, most of the problems that people
have with the draft is their failure to understand what it is to be used
for.  Many people have the impression that PGP/MIME is meant to be the
end-all-be-all for PGP.  But it's not!  PGP/MIME is meant to securely
transmit messages across the Internet in a manner which all platforms
can use.  PGP/MIME is text based because most transport systems in use
are.  Nowhere is anyone saying "thou shalt not use PGP without MIME."
I think if more people understood that, we wouldn't have so many
objections to it.

> It should not require any additional space overhead  (more than that
> which may be necessary for transport) when signing and encrypting.

The note in parens is interesting.  What you consider overhead I consider
necessary for transport.

me