* on the Thu, Oct 17, 2013 at 01:37:36PM +0200, Stephan Platz wrote: > for those interested, I started working on GnuPG-Support for trojitá a few > days ago. The current development can be found on gitorious > (http://gitorious.org/trojita/paalsteeks-trojita/source/gpg). > > Currently I have implemented rudimentary signature verification and it's > far from stable. Please note that caching breaks the verifiaction.
Awesome! This is what I've been waiting for. If you want to create the best
PGP support in any existing email client, please consider the following:
1.) Support both PGP/MIME and also Inline PGP for both incoming and outgoing
mail
2.) When composing a message, allow the user to toggle between using PGP/MIME
or inline. Intelligently choose which to default to per message, by taking
the following into consideration:
a.) A user specified default from the preferences
b.) What has been previously used when contacting that recipient
c.) What the recipient previously used when contacting the user
d.) A preference that was explicitly specified by the recipient
using the signature/cert "preferred-email-encoding" notation.
For example, my preference for receiving PGP/MIME encoded email
over Inline, is encoded within the signature of this message.
See GnuPG's "show-notations" argument to the --verify-options
option.
3.) When composing a message, if a Draft is going to be saved in an IMAP folder.
Allow the user to choose between several different options on how to deal
with this situation:
a.) Save to a local Drafts folder rather than to the IMAP server
b.) Encrypt before saving to the Drafts folder
c.) Don't save a Draft
4.) When sending an email to somebody who doesn't have a PGP key, we can't
encrypt. This is less than ideal, from a privacy perspective. However,
that doesn't mean we also have to save the "Sent Items" version
unencrypted. An option to encrypt anything that gets added to the
"Sent Items" folder with the users own public key, would be great.
5.) An option for making Trojita automatically and transparently replace
any unencrypted email on the server with an encrypted version.
If you don't understand why I want number 4 or number 5, please read the
following blog post I wrote a couple of years ago, and its follow up:
https://grepular.com/Automatically_Encrypting_all_Incoming_Email
https://grepular.com/Automatically_Encrypting_all_Incoming_Email_Part_2
6.) When encrypting an outgoing mail, automatically encrypt with the users
own public key as well.
7.) A setting which can be toggled to automatically sign all outgoing mail
8.) A setting which can be toggled to automatically encrypt all outgoing
mail for which we have the public key.
9.) A warning if we try to send an unencrypted email in response to an
encrypted email. And *also* a warning if we receive an unencrypted email
that was in reply to an encrypted email, so we notice if some information
we didn't expect to be leaked was leaked.
10.) Don't restrict encrypting ability to the UIDs in the key. For example
this email will be sent from [email protected], but will be
signed using a key which doesn't have a [email protected] UID
11.) Expect to see keys with multiple signing subkeys and multiple encrypting
subkeys. Some of which may have been revoked or expired. Expect to see
keys with UIDs that have been revoked.
12.) If there is a photo attached to a public key, display it within the
trojita GUI, along with the message.
13.) Take advantage of PKA records. For example, you can automatically look
up what the corresponding PGP key for my personal email address is without
talking to any key servers:
mike@glue:~$ dig +short txt mike.cardwell._pka.grepular.com
"v=pka1\;fpr=35BCAF1D3AA21F843DC3B0CF70A5F5120018461F\;uri=http://grepular.com/0018461F.pub.asc";
mike@glue:~$
14.) Support PGP at any layer of MIME depth. For example, you might have
an ascii armored inline pgp signed message that is an attachment
within a PGP/MIME encrypted email. You might also have a single part
email which contains some unencrypted and unsigned text, followed by
some ascii armored signed or encrypted text, followed by some other
non encrypted/signed text.
I can probably think of a tonne of other features. But at least these should
give you some ideas and things to think about. I'm looking forward to testing
and breaking your implementation ;)
Regards,
Mike
--
Mike Cardwell https://grepular.com/ http://cardwellit.com/
OpenPGP Key 35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F
XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4
signature.asc
Description: Digital signature
