Hello,
> but i'm not sure yet whether an abstract encryption plugin with drivers
> for different encryption mechanisms (gpg, s/mime, ...) would be useful.
> i simply don't know s/mime enough, but i fear that key management etc
> differs to much from gnupg to create an abstract layer for both.
I want to implement gpg's features on the users side {With FireGPG}. (I
personaly think it's better (storage of the private key, etc.)).
So an abstract layer whould be good as I could query the user with javascript
and a specific protocol. That mean we should think about a abstract layer who
can as the user (and not a server-only layer) :p
About the strucutre of this layer, we simply need (at last) 4 {6} functions:
encrypt(text, keys), decrypt(text), sign (text, privatekey), verify(text). And
optionnaly, {signandencrypt(text, keys, privatekey), import(text),
export(key)}. For key management, if need (should we or not ?) listkey and
listprivatekey too.
For the layer who manage mails, you will probably need need to:
- Decrypt an inline encrypted mail
- Decrypt an openpgp/mime encrypted mail
- Verify an inline signed mail <- this part is painfull. Realy. Every mail
client has is own logics...
- Verify an openphp/mime signed mail
- Encrypt or sign a mail in openpgp/mime standards
- Modify data of the mail to encrypt or sign it with inline.
Regards,
On Thursday 30 July 2009, Jonas Meurer <[email protected]> wrote :
> On 27/07/2009 Braxton Ehle wrote:
> > Hello,
> > I'd be interested in helping out with this as well. I've done some high
> > level mapping out of what all said plugin would need to do in terms of
> > functionality and what database setup could be useful, loosely based off
> > of the Thunderbird's Enigmail extension. I was also waiting for the
> > plugin API to really start working on this, which if it's already
> > available(in some form), is good to hear. Should we start a thread on the
> > forum to map out how this could work?
>
> hey braxton,
>
> great to hear that you already made some thoughts about the plugin
> design. have you already written down these thouhgts?
>
> i suggest to use a wiki page for discussion about the plugin.
> unfortunately I seem to have no rights to create new wiki pages in the
> roundcube trac wiki. maybe someone could create a page with a name like
> 'wiki:PluginRepository/Encryption' and then we discuss any further
> questions there.
>
> now back to topic, i'll try to write my thoughts down:
>
> so far i don't know yet how to best implement the user management of
> gnupg. i guess that a webserver-writable directory is required that keeps
> secring.gpg and pubring.gpg for every roundcube user. the gnupg plugin
> then will set $GNUPGHOME accordingly.
> maybe a mysql table with user id, key id, key type (sec or pub) and key
> fingerprint would be useful to double-check that nobody compromised the
> pupring.gpg and secring.gpg files. sha256sums of the files should be
> stored in the db and checked at every operation as well.
> best would be to not make keyrings writeable to the webserver, but I
> don't see how to do that.
>
> another issue is that the gnupg pecl module needs to be installed by the
> server admin, just like the gnupg binary. my motivation to use a php
> library was to make the roundcube plugin work on webspace where you
> neither have root access nor can request binary/library installations at
> all. i fear that i'll have to
>
> i also like the idea by thomas to create a gnupg encryption plugin
> with support for different drivers (i.e. gnupg binary, gnupg pecl
> module, ...).
>
> but i'm not sure yet whether an abstract encryption plugin with drivers
> for different encryption mechanisms (gpg, s/mime, ...) would be useful.
> i simply don't know s/mime enough, but i fear that key management etc
> differs to much from gnupg to create an abstract layer for both.
>
> greetings,
> jonas
>
>
>
> --- 8< --- detachments --- 8< ---
> The following attachments have been detached and are available for
> viewing. http://detached.gigo.com/rc/Mv/6uNnyJbn/signature.asc
> Only click these links if you trust the sender, as well as this message.
> --- 8< --- detachments --- 8< ---
--
Maximilien Cuony [The_Glu]
http://theglu.org
--- 8< --- detachments --- 8< ---
The following attachments have been detached and are available for viewing.
http://detached.gigo.com/rc/Qv/b6BBJBPc/signature.asc
Only click these links if you trust the sender, as well as this message.
--- 8< --- detachments --- 8< ---
_______________________________________________
List info: http://lists.roundcube.net/dev/
