check your public ring and automatically sign/encode outgoing mail to eligible users

As a general rule, mere presence of a key on a keyring should not indicate that this person wishes to receive encrypted mail. There should be a separate installation for that, either by an enhanced alias file or similar. There are many for whom reading encrypted mail is not always desirable, because the effort required to download it and decrypt it is more time than the content is worth. I myself fall into this category, unfortunately. I mean, if you encrypted if there was a key for someone, and sent mail to David Sternlight, he wouldn't be able to read what you wrote! :-) Eric

As I see it, the main problems PGP-MIME would be (1) The lack of MIME capable readers available for PC's and MAC's (the preferred platforms for anyone concerned about PGP security). But more importantly, (2) it's not obvious how to make a painless transition from PGP-2 to PGP-MIME.

check out the PCPINE package, it does mime. It can read mail out of an mbox, or a remote mailbox using IMAP or POP (assuming you have a network connection).

brad

...

For PGP to really make use of MIME, it could use "multipart" types to separate the objects being encrypted and/or signed from the signatures and encrypted session keys associated with them.

No, this is WRONG. Take a look at the PEM-MIME Internet Draft. You *do not* want to separate the signature from the body of text being signed, since then you lose the delimiters of the signed message, and MIME can do anything with the data (like transfer tabs to spaces, etc.) This is BAD.

If the signed object where of type text/*, then yes it might be altered with impunity. But MIME would not alter a body part type such as application/pgp-object or message/external-body would it? There's a definite advantage in using multipart/* to separate signatures from the plain-text they apply to because then you can easily encode the signatures with base64 while encoding the text in "7bit" or "8bit".

If you keep the message and signature together, it will work better. > MIME still does funky things, however, some times.

Then we need to get the MIME do's and dont's nailed down in the next RFC (if they arn't already) specifying exactly which type can be altered, and to what extent.

Currently, you can easily use MIME as a transport mechanism for PGP > messages. However currently there is no way to use PGP security for a > MIME message. Hopefully we can take what the PEM-MIME effort has > learned and apply that to PGP..

But I can put a MIME message headers in a PGP message. And (though I haven't tried it), I should be able to specify that application/pgp messages will be piped through a command like "pgp -m|metamail" or "pgp -m|mhn -file /dev/stdin". Unfortunately, I've had problems redirecting pgp's stdin and stdout. I'm not sure that it opens /dev/tty every time it wants to talk to the user. Also, since you bring up PEM-MIME, what could be done to bring PGP and PEM closer together? I'm not suggesting changing the web of trust model or using DES instead of IDEA. Just make the formats similar enough so that an application implementing one could be painlessly modified to implement the other. A common format wouldn't seem to be all that difficult to implement. Since some folks want to use triple DES and others IDEA, add this info to the RSA encrypted portion of the message. This has the advantage of hiding not only the key used to encrypt the body of the message, but the algorithm as well. As for the trust models, there not so different in theory, just in practice. PEM is planing on using X.509 type certificates, and they are having problems figuring out how to map X.500 Distinguished Names (DN's) onto e-mail addresses (I think they're making the problem allot harder than it is). Perhaps the model for future PEM/PGP systems is to keep both private key rings, and public key rings with the latter being found in the (Internet) X.500 directory. This would nessesitate being able to sign a private key with a public key, and vice versa. brad