[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