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

[Jan Schneider]

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

That's at least what I would (and already tried long ago) start with.
 
> 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.

Yes.
 
> 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?
> that appears before the body of the message)  Or should the user be asked
> first before viewing any message?

I would verify signed messages on the fly and show encrypted messages as 
they are. You'll have to ask for the passphrase anyway before showing them 
decrypted. Where to place a link is all yours, I think. We can move it 
elsewhere later. But I won't put it at the same place as the charset link 
because this may become confusing.
 
> 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...)

I would rather create it as a driver-like Horde library. Horde_Crypt:: in 
lib/Crypt.php and Horde_Crypt_GPG in lib/Crypt/GPG.php. We can then easier 
add other crypto plugins later.
 
> 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?

It is always a _huge_ security concern to store private keys at a public 
place even if they are passphrase encrypted. And you already noticed in 
your follow up that we need to store the private key in the preferences.

I'm not glad with this situation, but I think, someone who already knows 
how to use GPG or encryption in general should also know about this issue. 
And we should put a BIG RED message on the screen where the users will 
upload their private key. Perhaps we can use the <blink> tag? :-)

Another step to more security may be that we enable private keys (upload 
and usage) only if we have a https connection. I won't be able to test it 
then, but... 

One thing we have to discuss is, if it is less secure to store unencrypted 
private keys on a public sql/ldap server or to pass the clear text 
passphrase from the browser every time we use a private key.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft