[dev] PGP support for IMP - A start...

Chuck Hagenbuch chuck@horde.org
Wed, 27 Mar 2002 12:43:44 -0500


Quoting Michael M Slusarz <slusarz@bigworm.colorado.edu>:

> 1.) I think it is best to support GnuPG, and GnuPG only.  Unlike
> 'regular' PGP, GnuPG can be distributed in any country, and is 
> (essentially) the same as 'regular' PGP.

This is fine.

> 2.) PGP messages are embedded in a text/plain encoding, so the best
> place to put in any hooks for PGP is into the IMP_MIME_Viewer_text 
> class.  We can just search for a '-----BEGIN PGP SIGNED MESSAGE-----' 
> string and if found, and maybe if we have a PGP preference and it is set 
> to on, we enable PGP processing.

Sometimes signatures are in attachments, though, right? Those should have 
Horde-level MIME_Viewer drivers. But yeah, hooks can go in 
IMP_MIME_Viewer_text.

> 3.) How do we display results?  When receiving messages, for instance,
> do we display the undecrypted message and then have a link on the page 
> to decrypt (and where would this link be?  in the attachment field area 
> at the top of the message?  Or more like the "different character-set" 
> message?

For signatures, adding a header - something like "this message is PGP 
signed, and verified", verification failed, should be fine. For encrypted 
messages, how about saying "this was PGP encrypted" and then displaying 
the decrypted message if we can decrypt it, and displaying "decryption 
failed" and then the encrypted message if we can't?

> 4.) All PGP support should be put into its own IMP_PGP class (unless
> anyone can think of a better class to stick it into...)

This should definitely be at the Horde level - Horde_Crypt_GnuPG, etc., 
with the api defined by Horde_Crypt.

> 5.) Since I believe one of the purposes/goals of IMP is to have a fully
> featured client without ever needing shell access, this means that all
> PGP keys must be stored in the prefs framework.  This doesn't seem to be 
> a problem with receiving messages since we are only using public keys
> (Keep all keys in a serialized field?).  We may have a problem with
> composition since this requires private keys - what kind of security 
> concerns do we have with a preference framework for storing private 
> information?  Leave it up to the user to decide with a warning message?

Something I thought of a while ago was having Turba know about a 
special "public_key" field, which IMP could use to retrieve the keys of 
people in your addressbook. I'd like to do it that way, instead of storing 
keys in preferences - seems a bit nicer.

For storing private keys, there are a lot of half-measures that can be 
done. I definitely wouldn't store someone's decrypted private key (make 
them enter the passphrase, at least in each IMP session (we can encrypt 
the passphrase in the session store like we do the password). We can have 
Horde encrypt people's passphrases in their preferences with an encryption 
key, but that just means you need that key... not sure if there's a good 
way around saying "you need to keep this server secure" ...

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
"A dream which helps you to live your reality with dignity
 and justice is a good dream." - Tariq Ramadan