Re: PGP MIME INTERNET DRAFT considered harmful.

[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

-----BEGIN PGP SIGNED MESSAGE-----

> 
> [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.

I as you should know, I have never said that base64 should never be used.
I merely say that signatures should be taken over the original binary data.
Base64 can be used for transport as needed, but it should be a convention
that the any base64 is removed before signatures are checked.

Using this convention, it is easy to see that the node that strips encryption
could add base64 without invalidating the signature, because of the
convention that the base64 so added will be removed before the signature
is checked on the original binary data.

> 
> 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.

It should allow users to use it in such a fashion! PGP MIME should
respect the wishes of the users! Software should not view users
as tools to accomplish some goal predetermined by developers, but it
should rather make it easy for the user to accomplish what the user
wants! This attitude of service causes software to be in harmony with
market forces and leads to success! (Market forces apply to freware/guiltware/
copylefted/public domain software as well as software for sale or licence.)

By existing in a context of service, PGP MIME can make encryption
easy to use and become widespread. By doing so, it can entrench
the widespread use of encryption, making it politicly impossible to
regulate it! Thus, it can confound the evil plans of those dark forces
that seek to enslave us all!

As my examples show, some users may have legitimate reasons for
wishing to attach a generally useful PGP signature to a MIME message.

Not all users are technically sophisticated, it would be nice if PGP_MIME
could accommodate such wishes.

Digital signatures are an unrevokable record of what a person believes
and attests to at a given time. Belief is an attribute of persons, that
is not subject to command, certainly not by a piece of software.

PGP MIME should allow users to sign those documents the user wishes
to sign, faithfully transmitting those signatures to the receiver. It should 
not dictate that a user will sign an unintelligible artifact of a data 
transmission system.

> 
> > 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.

You are ignoring an already exiting binary transport, that exists right now.
Namely, PGP provides a BINARY datapath for its plaintext!

In the future, other binary transports will become more common.
7 bit datapaths will become less common.
Pressure will build for PGP MIME to support binary datapaths.

PGP MIME will have to go through a complicated migration path
to phase in this transition. All this complexity can be avoided by
doing the right thing now.

Make the method of representing the data for signatures independent
of the representation of the data for transport!

It might take some effort for PGP-MIME annalists and developers now.
But that effort, will be more than repaid by saving people the hassle
of having to clean up an intolerable mess later!

I do not see exactly how this should be done for multipart messages
in detail right now. That is why I have not made a specific proposal.
But I do see that it should be possible to come up with such a representation.

That is why I say that the draft should be withdrawn and sent back
for further study.

> 
> 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 does not necessarily know the difference between
a .gif and a .jpg file. He only knows he wants to send this pretty picture
on the screen.

Users should have a policy of only attesting to statements by digital
signature, that they know _of their own personal knowledge_ is true.
Any other policy is to court disaster.

If Malley ( the active message hacker ) hacks the content-type
MIME line, all that will happen is that the message to be sent
to the .gif viewer rather than the .jpg viewer, causing the message
to be lost. But Malley already had the ability to loose the message,
after all, he hacked it didn't he? In general, the content type line
should not be signed.

If some technically advanced user wants to sign the content-type
line, his wishes should be accommodated. But it should not be made
a requirement that technically unsophisticated users attest to things
they have no hope of understanding!

> 
> > 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"]

I have gotten the impression that you guys have stopped listening.
Everyone seems hell-bent on standardizing this inferior system that
will lockin a poor design. I hoped that by appealing to a larger
audience I could get more articulate and respected people to
persuade you to rethink. Perhaps some of the cypherpunks can
say something that will provoke an attack of sanity that will
stop this inexorable march toward a bad standard.


> 
> 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.

In the specific case I mentioned, (signed & encrypted) it is not necessary
for transport. It is only necessary for transport under your mis-designed
system whereby signatures must be taken over entities designed for
transport.

> 
> me

- -- 
Paul Elliott                                  Telephone: 1-713-781-4543
Paul.Elliott@hrnowl.lonestar.org              Address:   3987 South Gessner #224
                                              Houston Texas 77063

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: cp850

iQCVAgUBMaOd5PBUQYbUhJh5AQE6IwP9EjScv5K1CjOUvwBwbW0ovD5iwa/37/5q
WxI7rR8k2jArKQpBm8KKySMQs7YxQD28JU5FjS8IUJBRMkQRBkBZwUvTrWjW0Rs+
EKdyimgjd4KrsmVmHPxfAOhPjjNqUD2DVOWlRNfzc+0f+RW2Bxn3R4/XJQ3sFf5n
0kBISWaYHeg=
=HknB
-----END PGP SIGNATURE-----

--Boundary..3941.1071713579.multipart/signed
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On May 22, paul.elliott@Hrnowl.LoneStar.ORG (Paul Elliott) wrote:
> I as you should know, I have never said that base64 should never be used.
> I merely say that signatures should be taken over the original binary data.
> Base64 can be used for transport as needed, but it should be a convention
> that the any base64 is removed before signatures are checked.

However, this method does not allow for any verification of the content-type
headers for that part.

> As my examples show, some users may have legitimate reasons for
> wishing to attach a generally useful PGP signature to a MIME message.

> PGP MIME should allow users to sign those documents the user wishes
> to sign, faithfully transmitting those signatures to the receiver. It should 
> not dictate that a user will sign an unintelligible artifact of a data 
> transmission system.

Your last two comments really illustrate the divison that we've previously
seen on the pgp-mime list.  On the one side you have those who want to
include the MIME headers in the digital signature, and on the other are those
who want the signature to be over the data in it's "binary" (unencoded)
form.  I _do_ see merit in the latter.  However, that was not the goal of
my draft.  What I've been trying to get across is that my draft does not
preclude you from writing your own draft on how to transmit detached
signatures along with your message (perhaps something like
multipart/pgp-signed).

> Pressure will build for PGP MIME to support binary datapaths.

When this occurs, I will glady remove that restriction.

> PGP MIME will have to go through a complicated migration path
> to phase in this transition. All this complexity can be avoided by
> doing the right thing now.

Complex migration path?  How so?  Implementations that accept both
7-bit and 8-bit PGP messages but only generate 7-bit messages will
not suffer in the least if one day we decide it's ok to generate 8-bit
signed messages.  They will still accept either.  Newer versions of
the software can make use of the 8-bit path and it will interoperate
perfectly with older versions.

> Users should have a policy of only attesting to statements by digital
> signature, that they know _of their own personal knowledge_ is true.
> Any other policy is to court disaster.

This argument, which while true, doesn't make your approach any safer.  Any
software used is a proxy, and no matter how brilliant or naive the user
is, it's still a proxy.  There is some amount of trust that the software
is doing the "right thing."  It doesn't matter if I'm signing a PGP/MIME
message in my e-mail client or running PGP to encrypt a .gif or .jpg.

> I have gotten the impression that you guys have stopped listening.
> Everyone seems hell-bent on standardizing this inferior system that
> will lockin a poor design. I hoped that by appealing to a larger
> audience I could get more articulate and respected people to
> persuade you to rethink. Perhaps some of the cypherpunks can
> say something that will provoke an attack of sanity that will
> stop this inexorable march toward a bad standard.

No, we haven't stopped listening.  We've just heard these arguments arguments
over and over again for the past six months and nobody from that camp has
proposed an alternative.  Again, I do not believe the two methods are
mutually exclusive.  PGP/MIME is not meant do what I term "object security,"
it's meant for "transport security."

I think perhaps it's not so much PGP/MIME that you don't like, but the
whole multipart/security architecture in general.

me
-- 
Michael Elkins <elkins@aero.org>		http://www.cs.hmc.edu/~me
PGP key fingerprint: EB B1 68 32 3F B5 54 F9  6C AF 4E 94 5A EB 90 EC


--Boundary..3941.1071713579.multipart/signed
Content-Type: application/octet-stream; name="pgp00003.pgp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="pgp00003.pgp"
Content-Description: "PGP signature"

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogMi42LjIK
CmlRQ1ZBd1VCTWFQamtHTjlvV0JnaFBESkFRSHc3UVArSUhtblpjY1VZeVdo
bmtsb1hjM253cS96ampBbjFLR0oKMmpYVkJkQjBDVWR1UHhDOU00Y1NJdzVm
N2pzd2NhSFlOWUV5ZlRtNUZGem9vdWFYMU5tRWZMdE9MWkxwZW13OApXaEJa
OU1sM0VXSjM0cVVENFBPaU1JeHZ2WFNLcTBadjVjM0lXSFZvdFR3V0x4S09Z
djMybFloQlU2NWlVSzN2CktnOVNwNTFENGxrPQo9V01mUAotLS0tLUVORCBQ
R1AgU0lHTkFUVVJFLS0tLS0K
--Boundary..3941.1071713579.multipart/signed--

-----BEGIN PGP SIGNED MESSAGE-----

 
> Your last two comments really illustrate the divison that we've previously
> seen on the pgp-mime list.  On the one side you have those who want to
> include the MIME headers in the digital signature, and on the other are those
> who want the signature to be over the data in it's "binary" (unencoded)
> form.  I _do_ see merit in the latter.  However, that was not the goal of
> my draft.  What I've been trying to get across is that my draft does not
> preclude you from writing your own draft on how to transmit detached
> signatures along with your message (perhaps something like
> multipart/pgp-signed).

OK, it's not PGP MIME's department. Still, I hope that someone will
develop a spec for doing the other, because as my examples show,
some users may need that ability. If specs & software for easy of
use with PGP & mail and widely available, it will tend to entrench
the use of PGP and encryption.


> 
> > Pressure will build for PGP MIME to support binary datapaths.
> 
> When this occurs, I will glady remove that restriction.

The problem is that the transision will occur gradually.
At what point do you tell one class of users that they
are out of luck, in order to better serve another kind of
user? Ten percent? Five percent? One percent? A tenth of a percent?
They will scream bloody murder.

What if you want to send signed mail to a mailing list that includes
users of both kinds of users. Your message will go to a
large number of people, so there is reason for efficiency. Do
you want to send two kinds of messages to users depending
on what kind of transfer they have available?

It is time to invent  transfer-encoding-independant signatures!

We are assuming that the user trusts the pgp-mime software
to specify what will be signed, so that my previous objection
to signing arbitary objects has been ruled out of order.

We want to invent a method of "signing" a complex mime object
that will detect any modification of the information the user is trying
to convey, but will allows us to change the transfer encoding
of a body part without invalidating the "signature".

What we need is a computable map M from the class of mime
objects to a class of "binary signature objects". (Which are basicly
streams of bytes which can be fed into PGP to generate or check a 
signature). ( Don't tell me there is this wierd machine that can not
represent a stream of bytes. PGP assumes that many of its files
are streams of bytes, so that such a machine can not run PGP
to generate or check a signatures and everything with respect
to signatures becomes mute.)


      CLASS OF
      MIME OBJECTS    ======= M ========> BINARY SIGNATURE
                                                    OBJECTS.

M should have the following properties:

 1) Any change in the "message" that the user wants to convey
       will change the object that it maps to under M.
 2) We can change the way a body part is transfer-encoded without
       changing the signature object it maps to under M.

Note: These binary signature objects are not going to be used to
transfer data. They are not going to be used to display information.
They are only going to be used to generate and check signatures.

Given such an M, is is possible to define a method of signing
a MIME object, that will detect any change to the "message",
but not invalidate the signature when changing how a body
part is transfer encoded.

To generate a signature, apply M and generate a PGP binary signature
on the result. To check a signature, apply M and PGP signature
check the result. It should work.

Is it possible to define such a map M? I think so, but I am not
100% certain on the details. Something approximately similar to
the following should work:

Go thru the object copying header lines as a stream of ascii bytes,
seperated UNIX style with linefeeds. Except, do not copy the transfer-encoding
lines or the delimiter fields. Or any other field that only serves to tell how
the object is transfer encoded. Convert the body parts themselves to
a stream of bytes as specified by the transfer-encoding field and
included in the outgoing stream. For text encoding, trailing white
space could be handled as per the draft. Other text canonicalization
as PGP does it. I believe that this method has the two properties 
mentioned above. Perhaps it needs to be somewhat modified.

I am sure that such a map M can be defined if smart people think about it.
- -- 
Paul Elliott                                  Telephone: 1-713-781-4543
Paul.Elliott@hrnowl.lonestar.org              Address:   3987 South Gessner #224
                                              Houston Texas 77063

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: cp850

iQCVAgUBMaUbTPBUQYbUhJh5AQEsLQQAnugKr8rQdJi1F6EKxG9slMjVaQcVl9i4
N0azwKH46sIStm7/t8aWu2QnvosFLszt0/jD+NvQqgRU2XwlB/ynDChiMz9yANvy
1rd44r8rVIFZF3zyP9zxgJR+L8liQ/YdwLfEJTHk6Z1pFRMCoYz6Hs7nqvMDSvoc
jmhZQ7Z26AU=
=iKTw
-----END PGP SIGNATURE-----

On May 22, 11:11pm, Paul Elliott wrote:
} Subject: Re: PGP MIME INTERNET DRAFT considered harmful.
}
} > > 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.
} 
} It should allow users to use it in such a fashion! PGP MIME should
} respect the wishes of the users! Software should not view users
} as tools to accomplish some goal predetermined by developers, but it
} should rather make it easy for the user to accomplish what the user
} wants!

PGP/MIME is not software!  PGP/MIME is a *spec* for *one part* of what
comprehensive secure email software should provide!  PGP/MIME is not
required to specify the entire software system, and should *not* be
interpreted as limiting the system to only the part it discusses!

I think that's enough exclamation points.  If you want a spec for the
kind of usage described above, one can be created.  Then, if it seems
necessary, yet a third spec can reference both PGP/MIME and your new
spec, and say that a mail system conforming to PGP security standards
shall provide both PGP/MIME and this other usage, and any other that
you happen to think of.  There's no reason to expect PGP/MIME to *be*
that all-encompassing third spec.  That's not what PGP/MIME is for,
which is what Michael has been trying to say all along.

} PGP MIME should allow users to sign those documents the user wishes
} to sign, faithfully transmitting those signatures to the receiver. It
} should not dictate that a user will sign an unintelligible artifact of
} a data transmission system.

Sigh.  The *point* is to use PGP to verify or secure the transmission
system -- not merely to secure the content being transmitted.  How can
that be done without including some "artifact" of the transmission within
the signed or encrypted content?

} > 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 does not necessarily know the difference between
} a .gif and a .jpg file. He only knows he wants to send this pretty picture
} on the screen.
} 
} If Malley ( the active message hacker ) hacks the content-type
} MIME line, all that will happen is that the message to be sent
} to the .gif viewer rather than the .jpg viewer, causing the message
} to be lost. But Malley already had the ability to loose the message,
} after all, he hacked it didn't he? In general, the content type line
} should not be signed.

I put forth this very issue on the IMC resolving-security mailing list
some weeks ago.  I encourage anyone who wasn't involved in the IMC
secure email discussions to check out the archive at:

    http://www.imc.org/workshop/mail-archive/

Briefly, the important thing to remember is that the content type is
not the only interesting thing that may appear in the MIME headers.
The headers may include checksums, part identifiers for external parts,
and so on.  There *is* a difference between securing a MIME body part
and securing the data contained in the part; RFC1847 applies in those
cases where securing the body part is important, and PGP/MIME applies
when you want to use PGP as the security mechanism.  That's it.

} If some technically advanced user wants to sign the content-type
} line, his wishes should be accommodated. But it should not be made
} a requirement that technically unsophisticated users attest to things
} they have no hope of understanding!

By that argument, users shouldn't be signing GIF or JPEG images either,
unless they know they're not just a pretty picture.

However, the thing to wrap your brain around is that IT IS NOT BEING
MADE A REQUIREMENT that the MIME headers be signed.  PGP/MIME specifies
*how* you sign (or encrypt) the MIME headers along with the content
*when that is the intent*.

The non-technical user doesn't need to know what the headers he's
signing are, any more than he needs to be able to read GIF format.
He does need to understand whether he's signing a simple data object
or a specific transmission of that object.  That's up to his software
to make clear, but it's *not* up to the PGP/MIME specification.

} I have gotten the impression that you guys have stopped listening.

So far all your arguments seem predicated on misunderstanding of the 
goals and scope of the thing you're arguing against.  That makes *us*
the ones who've stopped listening?

} In the future, other binary transports will become more common.
} 7 bit datapaths will become less common.
} Pressure will build for PGP MIME to support binary datapaths.
} 
} PGP MIME will have to go through a complicated migration path
} to phase in this transition. All this complexity can be avoided by
} doing the right thing now.

Actually, the migration path is simple, obvious, and almost completely
compatible with the current specification.  The only migration required
is to lift the 7-bit constraint in PGP/MIME section 3, and to apply the
<CR><LF> canonicalization in section 5 only to parts whose C-T-E is not
`binary'.

Michael, what do you think about adding a remark about handling of
the `binary' C-T-E to section 5, with the stipulation that it is there
in anticipation of a future version of the protocol?  The section 3
restriction is obviously desirable at this time, but a lot of spurious
objections might go away if the transition plan were laid out.

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts           http://www.ncdsoft.com/ZMail/