Mailer hooks for PGP

I've now uploaded and made PGP.  It looks mondo cool, but also kind of a
pain to use because the existing interface requires one to perform encryption
and decryption manually.

I'm considering writing patches for Elm 2.4 that would allow it to (a)
check your public ring and automatically sign/encode outgoing mail to
eligible users, and (b) automatically decode incoming mail.

Elm is a very popular mailer.  If I could get these patches into the
distribution, the hassle barrier to widespread use of PGP would drop
significantly.  And the prospects for that are good; I'm friendly with
the Elm development group moderator.  Also, there's precedent for Elm
to delegate message decoding --- it has MIME hooks that shell out to
metamail.

(That brings up another point.  Has anyone worked on getting armored
PGP registered as an official MIME encoding type?  Getting pgp support
into metamail would be a massive win --- probably better than hooks in
Elm itself.  If no one else is working this angle, I'd be willing to
get in touch with Nathaniel Borenstein and use whatever zorch I have
with him to make it happen.)

Now, before I begin hacking.  Has anything like this been done before?
Are there any known design problems or pitfalls in integration with a
mailer such as Elm?  And, finally, if prz is listening, would you be
willing to accept minor hacks for this purpose such as the addition of
a new pgp interface mode tailored for use from mailers?
-- 
						>>eric>>

Isn't there already a version of elm with pgp patches?

-- Ray Cromwell        |    Engineering is the implementation of science;    --
-- EE/Math Student     |       politics is the implementation of faith.      --
-- rjc@gnu.ai.mit.edu  |                         - Zetetic Commentaries      --

>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

> (That brings up another point.  Has anyone worked on getting armored
> PGP registered as an official MIME encoding type?  Getting pgp support
> into metamail would be a massive win --- probably better than hooks in
> Elm itself.  If no one else is working this angle, I'd be willing to
> get in touch with Nathaniel Borenstein and use whatever zorch I have
> with him to make it happen.)

I agree.  MIME is taking the Internet by storm and for PGP or PEM
to reach wide audiences, it will need to be integrated with MIME,
and be able to draw on MIME's features.

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.

This could facilitate using MIME's features for external body parts
where part of the message is stored on an anonymous ftp site or
retrievable from a mail responder.

One could encrypt a document or other file on an ftp server, then
send out PGP-MIME messages with the RSA encrypted session key to
decypt the file.  MIME handles retreving the file and PGP deals
with how to decrypt it.

MIME of course deals with ascii armor on any body part leaving PGP
free to use binary data wherever needed.

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.

Any thoughts?


brad

> 
> 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 you keep the message and signature together, it will work better.
MIME still does funky things, however, some times.

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

-derek

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