[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