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/

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