1666507 - [OpenPGP] Support changing the expiry date of keys with a complex structure

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, enhancement, P1)

Description

[Kenny]

Attachment: change-key-expiry.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Safari/605.1.15

Steps to reproduce:

I double-clicked on my private key in the "OpenPGP Key Manager" window and clicked the "Change Expiration Date" button.

Actual results:

I got the message "This is a key with a complex structure, changing its expiry date isn't supported."

Expected results:

As has previously worked with Enigmail, I expected to be able to change the expiration date of my key that consists of less than 10 user IDs and contains subkeys that are in line with the default subkey structure generated by GnuPG.

Comment 1

[Kai Engert (:KaiE:)]

At this time we have chosen to avoid more complex user interface for this functionality, and start with a simple implementation.
I consider this a (potential) future enhancement.
The workaround is to export your private key, import it into GnuPG, change the settings, then import the private key back into Thunderbird.

Comment 2

[Kenny]

"The workaround is to export your private key, import it into GnuPG, change the settings, then import the private key back into Thunderbird."

Wow, so Thunderbird's OpenPGP implementation is becoming more and more unusable. I don't see why Mozilla thought that it has progressed far enough to be rolled out to the public and replace Enigmail.

Comment 3

[estolle]

I migrated to TB 78.7.1 just yesterday because of its release in Ubuntu repository. I have two keys that originally had an expiry date and I changed each to none. However, after migration its key manager displays the original expiry dates and I can't change them because of the error message "This is a key with a complex structure, changing its expiry date isn't supported."

Migrating the key to GnuPG, as Kenny suggests, won't work because that's where the keys come from, isn't it?

Comment 4

[estolle]

(In reply to estolle from comment #3)

Migrating the key to GnuPG, as Kenny suggests, won't work because that's where the keys come from, isn't it?
Sorry, it was Kai Engert's comment - not Kenny's.

Do I get it right that after expiry date I won't be able to use the keys any longer in TB 78 despite the fact that the keys actually don't have expiry date anymore?

Comment 5

[Nickolay Olshevsky]

Hi, could you please export your public key by GnuPG, and paste the result of 'gpg --list-packets yourkey.asc', removing all the personal information it may expose? RNP should correctly pick the latest expiration date set, but there could be some corner cases.

As a possible workaround you may try to use gpg --edit-key, and then issuing clean or minimize command followed by save, then export key and import it to the Thunderbird. Also I'd backup a key before doing that.

Comment 6

[estolle]

Attachment: Output of gpg list_packets

(In reply to Nickolay Olshevsky from comment #5)
> Hi, could you please export your public key by GnuPG, and paste the result of 'gpg --list-packets yourkey.asc', removing all the personal information it may expose? RNP should correctly pick the latest expiration date set, but there could be some corner cases.

I have just recently removed the expiry date on Feb 3. It is a key with one alias. Here is the output:

Comment 7

[estolle]

Attachment: Output of gpg --list-packets

Comment 8

[estolle]

(In reply to Nickolay Olshevsky from comment #5)

Hi, could you please export your public key by GnuPG, and paste the result of 'gpg --list-packets yourkey.asc', removing all the personal information it may expose? RNP should correctly pick the latest expiration date set, but there could be some corner cases.

I uploaded the output. It is a key with one alias. I just recently changed expiry date to "never".

Comment 9

[Nickolay Olshevsky]

Thanks. Log shows that you changed expiration time for the primary key (and both of aliases), but didn't change it for the subkey.
If you open OpenPGP key manager, double click on your key, and navigate to the 'Structure' page, does it show correct expiry times for the key/subkey?

Comment 10

[estolle]

OpenPGP key manager show no expiry date for the primary key and the unaltered expiry date for the sub key (I don't have two aliases). Using Kleopatra, there is only one entry for an expiry date and this is empty. I used Kleopatra for changing the expiry date.

Comment 11

[Nickolay Olshevsky]

So looks like in the OpenPGP key manager window subkey's expiration date is displayed.
Kaie, is this expected behaviour?

Comment 12

[estolle]

Just wanted to ask if I should open a new bug ticket because this one is labeled enhancement? I don't see this being an enhancement because I would expect TB to mark my keys invalid after Oct 29 / Oct 31 which they definitely aren't because of the extension of expiry dates. So this "enhancement" essentially is about neglecting a change in expiry date.

Comment 13

[Kai Engert (:KaiE:)]

Sorry that I couldn't follow-up earlier.

This is a tracking bug for the missing feature to extend complex keys.
Implementing this feature will require some user interface that allows the user to decide how to exactly handle the differences in the existing key.
This needs some design work and good decisions, and is the reason why it wasn't done yet.

Yes, we shouldn't hijack this bug to track other problems, we should use another bug.

I've filed bug 1711443 to track the issue reported in comment 3 and later. Please let's continue all further discussion on that problem in bug 1711443.

Comment 14

[niklas.larsson]

Hi,

I've tried to change the expiry on the key using external GPG but when i import it back into thunderbird it still has the old expiry date.

GPG:
sec rsa4096/Redacted
created: 2019-12-15 expires: 2023-10-19 usage: SCA
trust: ultimate validity: ultimate
ssb rsa4096/Redacted
created: 2019-12-15 expires: 2023-10-19 usage: E
[ultimate] (1). Redacted
[ultimate] (2) Redacted

In TB (91.3.0) :
The key expired on 2020-11-20

I've tried deleting it completely from TB then importing again but same result. Tested installing TB on another system and importing, that got the new expiry date. So TB must keep data the key somewhere even after deleting in order to get the old expiry date?

Comment 15

[klaus]

(In reply to niklas.larsson from comment #14)

I've tried to change the expiry on the key using external GPG but when i import it back into thunderbird it still has the old expiry date.

Similar behavior for me with Thunderbird 91.5.0 on Ubuntu 20.04. I have the "old" expiry date in Thunderbird on the first import. So expiry date is 2023 in gpg and 2021 in Thunderbird.

Comment 16

[henry.gomersall]

(In reply to klaus from comment #15)

(In reply to niklas.larsson from comment #14)

I've tried to change the expiry on the key using external GPG but when i import it back into thunderbird it still has the old expiry date.

Similar behavior for me with Thunderbird 91.5.0 on Ubuntu 20.04. I have the "old" expiry date in Thunderbird on the first import. So expiry date is 2023 in gpg and 2021 in Thunderbird.

Only for the last couple of days I've had Thunderbird refuse to sign my emails despite Thunderbird thinking the key expired months ago. Gpg (correctly) thinks it hasn't yet expired. I guess an update or something caused Thunderbird to decide the (incorrect) expiry date should be honoured, but I'm surprised it didn't do that previously.

There needs to at least be an "Refresh the keys from gpg database" if it's not going to do it automatically.

Comment 17

[henry.gomersall]

You can solve the problem by deleting the key and then reimporting it in the accounts from the secring. It appears to me that at this point the key is no longer managed by gpg, which is a significant failure in my opinion. It's now necessary to manage the key in two locations, one of which doesn't even nod to publishing key changes publically. It's also not clear the same password protections apply (that aspect is completely hidden from view). It feels like a real regression from enigmail, which actually worked, albeit a bit clunkily.

Comment 18

[Kai Engert (:KaiE:)]

Note that this is off-topic for this bug report (different issue).

Is my understanding correct that you edited your own key in GnuPG, and then you noticed that the key in Thunderbird still uses the previous expiration date? This is expected, because Thunderbird uses its own key, and doesn't synchronize it from external GnuPG. But maybe we could improve that, if our preferred communication mechanism with GnuPG, GPGME, is configured and working. I've filed bug 1762834 to track that idea.

Comment 19

[estolle]

(In reply to Kai Engert (:KaiE:) from comment #18)

Is my understanding correct that you edited your own key in GnuPG, and then you noticed that the key in Thunderbird still uses the previous expiration date?
This is at least not true for my reporting (comment #3) because I first extended the expiry dates and then imported the keys.

Comment 20

[Kai Engert (:KaiE:)]

Everyone, this bugzilla ticket has turned into a confusing mess of different reports.

As the subject of this bug suggests, this ticket is about potentially enhancing Thunderbird to actively modify keys of a complex structure.

Several of you have now reported complaints about how your keys are treated. This is offtopic for this ticket. Please file a separate ticket for your separate issue. When you do, please provide a copy of your public key (attachment or by email to me with bugzilla ticket number), so it can be analyzed.

Comment 21

[Kai Engert (:KaiE:)]

As of today, thunderbird allows changing the expiration if:

• there is exactly one subkey
• both primary key and subkey have roughly the same expiration date

Maybe the logic could be extended to say:

• if there are multiple subkeys, but all non-revoked subkeys are for a different usage (sign, encrypt, certify), and all subkeys have roughly the same expiration date, then we could change the expiration date of all of them.

However, if the subkeys use a different expiration date, or there multiple subkeys of the same type, then the user apparently has specific needs and wants to control the subkey expiration dates on their own.

In this scenario, I think it would be necessary to ask the user to change the expiration dates of keys individually.

Suggestion:

• if we detect that we don't want to change the expiration date of all subkeys in the same way, inform the user of the other "new" mechanism to change the expiration date of keys individually. That could say "click the structure tab, select a key, and then click the "change expiration date" button again.
• if the "structure" tab is open, and the user has clicked exactly one key (primary or subkey), then the button will modify that key, only.

Comment 22

[Kai Engert (:KaiE:)]

Let's see if we can get this done for 128, we have one more week for the needed string.

Comment 23

[Kai Engert (:KaiE:)]

Justification for making this a priority:
It will remove the need to use an external tool, using a complicated multi-step procedure, which is also known to introduce other issues (e.g. people only importing the extended public key, and that not working).
I saw several complaints on social media during the past year that asked for a solution, I'm perceiving this as a pressing issue.

Comment 24

[Kai Engert (:KaiE:)]

When explaining this need to Alessandro, he suggested to perform the key selection inside the change expiration dialog, by offering a dropdown list. I agree this is better.

I have an implementation.

The intention is that the dialog remains completely as is for all users to simple keys.
(Simple keys are the ones we have always allowed to edit. They consist of a primary key and a single subkey, and both have rougly the same expiration date.)

The dialog will look and behave differently for complex keys, only.

The dialog shows some additional explanations. To ensure the user has all the information required to select the key, we use a string that lists multiple pieces of information, similar to the attributes shown in the structure tab of the key details dialog.

The user is required to select a key from a list, initially there will be no selection. The intention is to ensure that the user reads the dialog text and makes an explicit selection of a key, prior to being able to perform an action and press the OK button.

Comment 25

[Kai Engert (:KaiE:)]

Attachment: simple-key-classic-appearance.png

Comment 26

[Kai Engert (:KaiE:)]

Attachment: complex-key-step-1.png

Comment 27

[Kai Engert (:KaiE:)]

Attachment: complex-key-step-2.png

Comment 28

[Kai Engert (:KaiE:)]

Attachment: complex-key-step-3.png

Comment 29

[Kai Engert (:KaiE:)]

Attachment: Bug 1666507 - Support changing the expiry date of keys with a complex structure. r=aleca,mkmelin

Comment 30

[Kai Engert (:KaiE:)]

I will attach an example secret key that can be used to test this bug.

Comment 31

[Kai Engert (:KaiE:)]

Attachment: mixed-expiry-secret-key.asc

Comment 32

[Kai Engert (:KaiE:)]

Attachment: primary.png

Alessandro asked for a different visual presentation, so I'm marking the previous screenshots as obsolete.

This new screenshot shows the dialog when opened, which will automatically show the primary key selected.
(There will no longer be a blank line in the dropdown.)

The dropdown for the example key will have two entries.
I'll attach another screenshot that shows the dialog after selecting the second entry.

I think the display of the additional properties of the selected key could probably be styled in a nicer way, but maybe this could be slightly postponed (at least to next week), so we can get the string change landed together with this patch by tomorrow?

Comment 33

[Kai Engert (:KaiE:)]

Attachment: subkey.png

Comment 34

[Kai Engert (:KaiE:)]

Attachment: tweaked-blue-intro.png

I wasn't happy yet with the text in the blue introduction box.

I changed it again. Here's my latest suggestion, as implemented in the patch.

Comment 35

[Magnus Melin [:mkmelin]]

Should there be an "all" option? I'd naively imagine one would usually want to change them all to have the same expiry.

Comment 36

[Kai Engert (:KaiE:)]

If someone has differing dates, they have deliberately decided to do so.

For example, someone might have wanted their encryption subkey expiring earlier than their primary signature key.

Comment 37

[Kai Engert (:KaiE:)]

I think in this scenario, it's reasonable to ask the user to make individual decisions for their subkeys.
If they want to restore the simple state, they can use the new dialog to set the same expiration date for them.

Comment 38

[Kai Engert (:KaiE:)]

(In reply to Kai Engert (:KaiE:) from comment #36)

For example, someone might have wanted their encryption subkey expiring earlier than their primary signature key.

Look at Patrick's key 4F9F 89F5 505A C1D1 A260 631C DB11 87B9 DD5F 693B

He has an old encryption subkey that he let expire in 2018, and then created a new one.
If we added an "all" option, he could very easily shoot himself in the foot.

In my opinion, if someone has gone the extra mile to configure a key in that complex way, that they want differing dates, it's fair to ask them to make a few manual steps, to ensure they precisely do what they want now.

Comment 39

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/bc8aa6186410
Support changing the expiry date of keys with a complex structure. r=aleca,mkmelin