GPG/PGP signing key should be on identity not account

[MarcusWolschon]

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

[Valodim]

Absolutely 👍

[danwdart]

This affects me in that the default signing key is always picked incorrectly

[Valodim]

sign/encrypt default choice should be part of this as well

[yuv]

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.

[Valodim]

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.

[yuv]

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

[Valodim]

I'm not sure I understand your comment, then. This issue is about setting signing keys per identity. I thought you wanted something different?

[yuv]

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.

[msebald]

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.

[philipwhiuk]

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

[msebald]

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.

[MarcusWolschon]

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.

[msebald]

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?

[yuv]

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

[philipwhiuk]

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.

[yuv]

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

[philipwhiuk]

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.

[yuv]

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.

[philipwhiuk]

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.

[Valodim]

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.

[deviantollam]

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. :-(

[MarcusWolschon]

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

[deviantollam]

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

[Valodim]

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?

[Valodim]

I finally have a concept for this issue and started working on this, so this is now in the more immediate pipeline. Yay.

[sylph1o]

Hi ! Is this still being considered? I don't wish to press, I'm simply very interested in this feature. If no one has time to work on it any more, I'll simply look for another solution. I don't have the skills to help, unfortunately =(.

[CueHD]

I also would appreciate being able to assign an openPGP key per identity. In addition being able to select from a list of OpenKeychain private keys instead of relying on the autoassignment is needed. Currently when I try to assign a key, the key that I want to use is not listed. While I am able to go to OpenKeychain from the dialog, I do not see any way to actually select my key. I hesitate to sumbit a bug report since I would rather that this gets fixed when implementing per identity key instead of per account key.

My use case is different than the ones already described, so I will state it here:
My email provider (Fastmail) allows for unlimited identities. This is accomplished by using subadsressing. For example, an alias is emailaddress@domain.TLD. I am able to send and receive email using anything@emailaddress.domain.TLD. I use this often though I do not want to add every possible email address to my key. I prefer to use one key for all of these email addresses.

[peter64]

Hey Guys, I'm having a hard time understanding if I need this feature or not to explicitly associate keys with a given identity. Other comments like @CueHD's (and several others) #2815 Seem to imply that if I create keys in for each email address K-9 will communicate with OpenKeychain to select the correct key and use it.

This however is not my experience. I need to associate a key with the base account otherwise I get an error "No key configured for this account! Check your settings". However I can only associate one key with the base account and this means that single key needs to include all possible email addresses.

I attempted to associate a single dummy key to the base account in hopes that at the time of sending an email using a different identity it might pull in the correct key. Unfortunately this was not the case. It used the key associated with the base account and not the key in OpenKeychain that corresponded to the email address of the chosen identity.

I'm left thinking that what I want to do just doesn't work presently. Perhaps @CueHD you are maintaining all email addresses under a single key associated with a single account. And perhaps the user who filed #2815 has multiple accounts and it was simply a matter of K-9 chosing the wrong key from the wrong account when sending emails (and that bug subsequently being resolved).

Please correct me if I'm wrong but I just want to make sure there is no way to get K-9 to pull in keys from OpenKeychain on a per identity basis via the email or identity display name. I attempted making keys in OpenKeychain with names that corresponded to K-9 email addresses and K-9 display names and neither approach worked.

This feature would be really great as currently I can't use PGP with my multiple identity system. Thanks!

[CueHD]

Perhaps I was unclear.
The auto-assignment attempt is currently per account not per identity. What we are asking for in this issue is per identity assignment of keys.

[mrmelon54]

My comment is going to be marked as off-topic, but if this is never worked on then only topic of this thread is people continually asking for the feature.
At that point this comment is perfectly on-topic.

Anyway, I would assume this is really easy to implement. I might be mistaken on that front.
Maybe I'll give it a go one day and submit a PR?

[ghost]

Any news on this feature ?
The "workaround" is to keep changing the account-specific key to that of the respective identity writing the current email. This is very painful.

BTW: marking comments as "off-topic" simply for asking about the status after 8 years of having this as an open issue is an "interesting" way to give answers, to say it politely. If you don't intend to implement it, that's fine. Just close this issue so that everybody knows.

[Flux3PO]

Yeah... for me, I no longer care about Email encryption.

[mrmelon54]

BTW: marking comments as "off-topic" simply for asking about the status after 8 years of having this as an open issue is an "interesting" way to give answers, to say it politely. If you don't intend to implement it, that's fine. Just close this issue so that everybody knows.

Personally I think its a very rude way to handle those sorts of comments especially because the issue has been open for 8 years. Would be so much better if they responded with the status of the development of the feature.

[cketti]

See https://github.com/bradfitz/issue-tracker-behaviors#any-update and
https://cketti.de/2020/07/07/why-i-hide-github-issue-comments/

[ghost]

See https://github.com/bradfitz/issue-tracker-behaviors#any-update and https://cketti.de/2020/07/07/why-i-hide-github-issue-comments/

The link that you gave says, literally:
"(if it's been a year, sure. But we don't need somebody pinging the bug for updates daily or weekly.)"

My guess is that 8 years probably qualify, too. But feel free to feel insulted. 🙄

[mrmelon54]

See https://github.com/bradfitz/issue-tracker-behaviors#any-update and https://cketti.de/2020/07/07/why-i-hide-github-issue-comments/

Yep, I understand why you do this but it would be more helpful to point users in the direction of a timeline or other useful information about the issue. Maybe people asking for updates about this issue because this issue isn't even on the roadmap in Github projects or maybe because there doesn't seem to be any active development on resolving this issue.

I don't see a PR referenced which begins to resolve the issue, or a branch dedicated to rewriting the GPG/PGP handling to support multiple identities properly.

If there was evidence of further information, a timeline or active development on this issue then there would be a higher chance that people wouldn't be leaving comments every few years asking for updates on this project.

I totally understand why you don't like off-topic comments, but at the end of the day there is a reason why they are being posted.

Just a reminder that the last on-topic comment, before the spew of off-topic ones was back in 2019. I think this definitely qualifies for being over a year.

[ghost]

i really Wanted to insuscribe

…

On Mon, Jul 24, 2023, 7:18 AM Melon ***@***.***> wrote: See https://github.com/bradfitz/issue-tracker-behaviors#any-update and https://cketti.de/2020/07/07/why-i-hide-github-issue-comments/ Yep, I understand why you do this but it would be more helpful to point users in the direction of a timeline or other useful information about the issue. Maybe people asking for updates about this issue because this issue isn't even on the roadmap in Github projects or maybe because there doesn't seem to be any active development on resolving this issue. I don't see a PR referenced which begins to resolve the issue, or a branch dedicated to rewriting the GPG/PGP handling to support multiple identities properly. If there was evidence of further information, a timeline or active development on this issue then there would be a higher chance that people wouldn't be leaving comments every few years asking for updates on this project. I totally understand why you don't like off-topic comments, but at the end of the day there is a reason why they are being posted. Just a reminder that the last on-topic comment, before the spew of off-topic ones was back in 2019. I think this definitely qualifies for being over a year. — Reply to this email directly, view it on GitHub <#942 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2EIALVT3YVQWROQQCQ2TBDXRZYZRANCNFSM4BWK625A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Anti-Apple4life]

It has been another year with no developments on this issue. Is it still being worked on?

[mrmelon54]

The first beta for Thunderbird for Android has now been released. I guess this issue is classified as an incompatibility between the Android and desktop software. Is it possible to have any updates on this issue and potentially even a fix.

[46cv8]

Hey @mrmelon54, you mentioned above you might try your hand at a pull request. Did you make any progress? Is the Thunderbird for Android a rebranding of K-9? Or a totally new client?

[mrmelon54]

@46cv8 I have unfortunately been too busy to even think about attempting a PR.

This is a little off-topic for this discussion
As mentioned in the April 2024 official blog post, the two apps share the same source code and will provide both branded apps.