PGP support for IMP - A start...

[Michael M Slusarz]

All,
I've been mucking around with this for a few days, and before I get too far 
into it, I thought I would ask a few questions so that I don't go designing 
something that will be completely counter to IMP's framework/goals.

So, to integrate PGP into imp, this is what I have come up with so far. 
(For right now, I am just dealing with viewing of PGP messages, not with 
composition.  That can be worked on later).

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.

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.

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?

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

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?

I would definitely appreciate thoughts/concerns/criticisms before I hunker 
down and try to do too much.

thanks,
michael

______________________________________________
Michael Slusarz [slusarz@bigworm.colorado.edu]
The University of Colorado at Boulder