thunderbird
GPG/PGP signing key should be on identity not account
Currently the user has to set the signing key per account. It should be that the signing key is set per identity instead.
As the identity and key are tied to an email address but the account is not, this is the natural order of things. It also allows the user to use multiple signing keys based on his current role (answering private mails, company mail or customer mail from the same account).
This affects me in that the default signing key is always picked incorrectly
Also: My K-9 seems to forget the assigned signing key all the time. Every time I want to sign something, it says "no signing key assigned" and every time I have to assign it again. I'm however not on the Google Play Store releases since my Android Wear support still is not part of any release yet.
@MarcusWolschon: This issue is about an enhancement. You're now talking about one, possibly two, bugs. Please create new issue(s) with a reference to the Git HEAD commit of your build.
I'm just pointing out that the issues with the signature-key may be much broader. Anyone changing to how signing keys are stored should know what else to look out for in that part of the code.
Please consider that while an identity has a one-to-one relationship to an email address, tying a key to an email address is an unnecessary limitation. Please allow users to select the key manually based on its fingerprint. Thanks.
I don't think having multiple keys for the same identity is a valid use case. Adding this flexibility comes with a real cost in ui complexity, which I don't think is worth it.
What might be a way to do this is allow multiple identities with the same e-mail address. Anyways I didn't look at this in detail yet, so not sure.
This is not about having multiple keys for the same identity. This is about selecting an arbitrary key to sign messages from any identity without the constrain that the identity's email is also the key's emails. Enigmail does it well in Thunderbird: in Account Settings / OpenPGP Security I can either use email address of the identity to identify the OpenPGP key, or use a specific OpenPGP key ID. All it boils down to is:
- add one field to enter a key ID
- if the field is empty (default), select key based on the identity's email address
- else use the key ID to select the key
I'm not sure I understand your comment, then. This issue is about setting signing keys per identity. I thought you wanted something different?
It's the how, not the what. You can set signing keys per identity based on the email address, but this is limiting. Or you can set signing keys per identity based on the Key ID, which is in my view the right thing to do.
Yes, this has to be changed. I use one key per mail address, so I need a different key per identity. This id the biggest issue (I call it issue as I only can use PGP for the main mail address of my account) for me for the current alpha 5.108 - and besides some minor usability/frontend things the only real issue.
I would also say that keys should be set by key id, not mail addresses as there could be more that one valid private key per mail address, as it is for my case.
I think both are probably valid uses (the later implies some aspect of control over the distribution of your 'public keys' availability which is not actually enforced on a security level but might be on a practical level) but definitely a key per email is the more common one I think.
Besides which, I'm not sure K-9 does a very good job with secondary addresses per account, let alone the PGP/MIME sub-module. We probably want to formalise that better, first.
The default needs to be a default key attached to the default email address being automatically selected using opportunistic mode (sign, encrypt if possible).
We can then add better support for secondary sending addresses in K-9 and attaching OpenPGP keys to them as that secondary email's default key. (the issue for this issue).
We could then add an advanced options setting to enable you to select an arbitrary key at some point (@yuw). This would be off by default.
What we don't want to do is over-complicate the 90% case of 1 email address for 1 account with 1 key. That has to be simple and straightforward
I think my reply on this issue was not very clear, also because you first wrote something different and changed it later. ;-) But it is also not an easy thing to talk about and as already mentioned, there are so many different ways to handle keys, mail addresses and so on.
In my case it is not that straight forward as I thought. I just checked my PGP keys. In most cases I use one key for one mail address (but I also have old additional keys with the same mail addresses still in my keyring, e.g. to be able to decrypt old mails - maybe that was a bit confusing in my post yesterday). But I also have two keys where I have more than one mail address identity in it. I use these two keys for my company where I reply with different mail addresses which depends on the case why I get/send a mail (customerservice@, postmaster@, msebald@ ...).
I think the easiest way to really bind a key to a mail address and/or identity in K-9 is to use the key id. The id will never change - even if I add or change the key later. No idea if this way is more complicated to implement, but it would be great to have it that way. I know this from Thunderbird (Enigmail addon) where I can manually set a key for an identity (if not, Enigmail will guess by the sender mail address which key to use).
Sure, using an automatic procedure makes it more easy for users and maybe also to implement this into K-9, but it will only work for simple setups. My guess is that people who use PGP will not have a simple setup in most cases, unfortunally.
So:
- let the user choose 1 keyID for each K9-Identity.
- open a different feature request for "allow multiple identities with the same sender-email-address"
default key: There already is a default identity and thus a default key (if the user has chosen one).
choosing by KeyID instead of email address: Choosing a KeyID instead of an email that identifies a key gets rid of serveral issue. Most of all key-rollover, where you have an old key and a new one associated with one email address.
I was able to setup two identities with the same sender address with the newest alpha version 5.108 - I was surprised as this was not working before. So either it is an accident or a new feature.
So, setting a key id per identity is for sending, right? Then everything is set and ready to go. When receiving or opening old mails the key is chosen by the information from the mail - I would guess. Then also old key ids would taken from the private keyring?
@msebald: The subject of this bug report is sending, not receiving. The logic by which a key is chosen when receiving or opening old mails is surely important and you may want to open a different feature request if there is an issue in that area.
@MarcusWolschon: Yes, I believe that your data structure of one keyID for each K9-Identity is the simplest and easiest way to satisfy all reasonable use cases expressed in this thread.
The UI logic can and should IMHO follow @philipwhiuk principle of not over-complicating things, so compared to the K9 version that is currently on my phone via F-Droid.
Settings:
(1) Move the Cryptography setting from Account settings to Account settings > Sending mail > Manage identities > %K9-Identity%
(2) Replace Auto-sign boolean setting with a Signature setting that has the following choices:
- Off (default, though debatable)
- Automatic: use opportunistic mode, in @philipwhiuk 's words)
- Manual: show a drop down with the list of keys from the OpenPGP Provider and let the user select one manually.
(3) Account settings > Sending mail: add an "Always show cryptography" Boolean similar to the existing Always show Cc/Bcc, Off by default
Compose:
(1) Default, when Always show cryptography is off, use opportunistic mode, i.e. automatically sign if a keyID exists for the selected K9-Identity
(2) When Always show cryptography is on, show the current UI line with the two check boxes for Sign and Encrypt
That would be sufficient for the signing function, i.e. for the subject of the current feature request. It would leave some analysis and logic gaps for the encrypt function:
(1+) when using opportunistic mode, for each recipient: (a) if there is no key for the recipient in the key ring, don't encrypt (b) if there is a single key for the recipient in the key ring, encrypt (c) if there is more than a single key for the recipient in the key ring, ask which one to use
(2+) when in manual mode: show the current UI line and if the Encrypt check box is checked at the time of sending, follow the same logic as in (1+)
I believe the above reduces complexity for all users while increasing flexibility for the more sophisticated scenarios, and is described in sufficient detail to start implementation.
If somebody can point me to the actual files and line numbers in the code where this happen, I may spare some time and make my first attempt at patching an Android app.
Much of this has changed in the current beta/dev. The auto-sign/auto-encrypt setting doesn't exist any more. There's a padlock dialog which is displayed in the compose view if an app and key is setup, which defaults to opportunistic: https://github.com/k9mail/k-9/wiki/Crypto-Design-Thoughts
Right now the key is selected on an account basis in activity/setup/AccountSettings using an OpenPgpKeyPreference.
For it to be identity based means adding new settings to activity/EditIdentity.
For composing this means the RecipientPresenter (which should really be renamed now it does more than present recipients...) uses the key to set the availability of cryptography.
@philipwhiuk I don't have much time now nor in the next 14 days to look at things in detail. However, I must remark that the link in your comment above describes received emails while this feature request is about sending emails. I fail to see how the Crypto Design Thoughts linked above are relevant in the context of this feature request and I strongly recommend keeping the analysis and design of receiving and sending crypto function separated, if only for one major difference: I cannot control what I receive, but I can control what I send and how I send it.
I forgot it only covered received icons when I wrote that. My point was the UI has changed somewhat. Here's screenshots from the beta.
In any case @Valodim is spearheading the PGP/MIME project. I'm mostly bug-fixing right now.
Thanks for the screenshots. I assume that if I tap on the padlock icon next to the From line on the first screen shot, the dialog in the second screen shot. I assume that the dialog offers me four choices (sliding from left to right along the four icons), although from the look of it there could be six options if I am to tap on the text too.
If I have four choices on that dialog, what do they stand for?
I venture on thin ice with the following remarks, mainly because I have only partial information. It seems to me that whoever has designed / coded the screenshots and functionality (is it you, @philipwhiuk ?) has mixed together two crypt function: signature and encryption.
Signature:
- relates to the sender
- uses the sender's private key
- can be fully controlled within the Compose dialog
- its symmetric function when receiving emails is Verification (off-topic in this feature request and more generally in the Compose dialog)
Crypt:
- relates to the recipients
- uses each recipient's public key
- must rely on the availability of the public key on the user's keychain
- its symmetric function when receiving emails is Decryption (off-topic in this feature request and more generally in the Compose dialog)
I strongly advise clarity and separation between Crypt for Sending (Sign/Encrypt) and Crypt for Receiving (Verify/Decrypt).
To the specific dialog, if the options are really four different ones on a line, I would suggest removing the passive text header and indeed letting the user choose with a four position slider. However, if the four options are just the result of a combination of two binary choices, the slider is the wrong visual metaphore to use. A better one would be two toggles. Two icons, one for Sign and one for Encrypt. Gray = off, Colored = on. And I would use Black as a color, not Green, because the dialog is not indicating success, partial success, or failure (which would justify the use of Green/Yellow/Red), but just activation / deactivation. Moreover, the dialog is just a mere overriding of a default choice, so please bring back the default choice in the settings.
Please correct me if I am mistaken.
Following discussion - there's a mailing list for all this.. @Valodim and @cketti and others did the implementation.
The four options are:
- Never sign, never encrypt.
- Always sign, never encrypt
- Always sign, encrypt if possible
- Always sign, always encrypt
It's not binary. Encrypting without signing is not quite pointless, but not far off.
And implying they are separate is not useful either. E-mail is a two-way protocol - it's not helpful to ignore that the hard part of PGP is key distribution - failing to provide a signature for return mail would only worsen the problem.
As for default choice, I find myself disabling entirely it quite a bit right now - sending PGP data to people who don't have compatible clients and when adoption is so low is counter productive. I would rather have to turn it on than always turn it off. But we are miles off topic.
I recommend you install the beta if you want to feedback further - me reproducing it in screenshots is kind of labour intensive when it's an open program.
I hope we can now stick to the issue in this issue for this issue and raise other issues separately.
Indeed, please don't derail our issues. We appreciate that you want to contribute your thoughts, but describing how the interface looks in the alpha we released in the play store is not a good use of our time.
i am not running an alpha, but rather the official release from the Google Play store. i just upgraded to version 5.201 this morning and this was the absolute first thing that i noticed.
i have only one mail account but 9 sender identities, 7 of which have their own PGP keys. i hate having to send out, say, business mail from a business identity but then it gets signed (or even encrypted as the case may be) as my personal (primary) identity. it's horribly unprofessional, and now i have to either dig out a prior version of k9mail from an Android backup or stop sending business mail from my phone until this gets fixed. :-(
So do we have a concensus on how to implement signature keys per identity? Who can implement it? (I'm currently occupied with 3 other projects.)
@MarcusWolschon i will gladly offer up any bounty payment that you care to name if this gets handled, either by you or by anyone you can convince to fix it.
Setting signing/decrypting keys by Identity as opposed to by email address or any other strange designator would be the biggest thing preventing me from using the latest version of K-9 Mail.
(Then we can go about addressing all of the other weird UI changed that happened in the new milestone, hah!)
Seriously, I dug an old version out from my last phone backup and that's what I've got at the moment. And the device is constantly trying to get me to upgrade to the new version, which I have to keep preventing, since it breaks the entire way that email and signatures should be handled. :-(
Sorry for sounding so harsh. But seriously, this is something I would gladly do ANYTHING to encourage others to address.
When you say you have one mail account buy 9 sender identities, do those identities have different mail addresses? Using different keys with the same mail address seems like a weird scenario to me, if that's what you're doing can you say what the idea is there?
I have three IMAP accounts configured in K-9 mail. Two of which basically never send/receive messages... they are used for shared message archiving or just keeping tabs on some company operations.
So, that basic overview could be thought of as...
IMAP #1 Personal (the EVERYTHING account)
IMAP #2 Stored Old Stuff (shared by some other folk with access to same account)
IMAP #3 Other Business That I No Longer Run
Now, as far as identities are concerned, this is how the structure looks...
IMAP #1 [email protected] (has PGP key #1, most used) [email protected] (has PGP key #2, used for family emailing) [email protected] (doesn't use PGP at all, no key) [email protected] (has PGP key #3, used for internal chatter) [email protected] (has PGP key #4, used for client communication) [email protected] (for misc. whatnot, no PGP key at all) [email protected] (for misc. whatnot, no PGP key at all) [email protected] (for misc. whatnot, no PGP key at all)
IMAP #2 [email protected] (has PGP key #5, rarely used for anyything)
IMAP #3 [email protected] (no PGP)
... it is not feasible for me to split up all of those IMAP #1 identities. I send and receive and reply to and (most of all) file into folders all of that mail in a common-use fashion. And almost all of those sender identities are tied to forwarder addresses, so there's no fully-featured IMAP account by which I could send mail on a server somewhere logging in as [email protected], let's say.
So all of them are set up as sender identities under IMAP #1 and that works well.
The latest K-9 mail client, however, seems to want to insist on ONLY ever using PGP Key #1 for signing ANY messages. As you can imagine, if [email protected] is sending email to a client, signing it with "Deviant's PGP key" is totally unprofessional.
(Not to mention that the whole UI is totally complicated and hard to follow anymore, with the colored padlocks and three dots and all that... it used to just be two simple checkboxes. Sign and Encrypt. It was totally unambiguous. Now we've got some slider-bar and colored dots and "always, sometimes, never" choices. Ugh.)
i see that @yuv is of the same mind that I am...
the slider is the wrong visual metaphore to use. A better one would be two toggles. Two icons, one for Sign and one for Encrypt. Gray = off, Colored = on. And I would use Black as a color, not Green, because the dialog is not indicating success, partial success, or failure (which would justify the use of Green/Yellow/Red), but just activation / deactivation. Moreover, the dialog is just a mere overriding of a default choice, so please bring back the default choice in the settings.
two separate toggles would be much clearer, not to mention it more closely parallels every other encrypted email client I've ever seen, all of which treat "Sign" and "Encrypt" as two distinct buttons/toggles.
This issue is about identities, please keep on topic.
Thanks for your feedback on your identities use case, I'll get back to it later.