Closed Bug 1634561 Opened 4 years ago Closed 4 years ago

Support extending the lifetime of an OpenPGP key (change expiry)

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

Product:
MailNews Core
Component:
Security: OpenPGP
Type:
enhancement

Tracking

(thunderbird_esr78 fixed, thunderbird79 fixed)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 80.0
Tracking Flags:
Tracking Status
thunderbird_esr78 --- fixed
thunderbird79 --- fixed

People

(Reporter: KaiE, Assigned: KaiE)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 3 obsolete files)

key-details-personal-key.png
58.01 KB, image/png
Details
Bug 1634561 - Support extending the lifetime of an OpenPGP key (change expiry). r=PatrickBrunschwig
47 bytes, text/x-phabricator-request
wsmwk
: approval-comm-beta+
wsmwk
: approval-comm-esr78+
Details | Review
expire-new.png
34.54 KB, image/png
Details

Often, OpenPGP keys are configured with an expiration date. If you set an expiration date, and lose access to your own secret key, then you you'll suffer only until the defined expiration date. (Suffering is defined as: Other people send you encrypted email which you can no longer decrypt.)

However, if you still have the secret key, you probably want to continue to use your existing key - which other public already know, and are already willing to use/accept.

That means, you typically don't want to start from scratch after expiry. Instead, you want to edit your existing key, and extend its lifetime, by defining a new expiration date.

Because past Enigmail has allowed to do that, we should assume that a significant amount of past Enigmail users will require the ability to change the expiry date.

RNP has recently added an API to do so.
As a first step, we should have a mechanism in key manager to perform the expiration change.

Now it's getting complicated...

You need to know that your personal key is actually a set of multiple keys. Usually just tow keys, one restricted to signing/certification operations, and another one for encryption operations.

In the simple scenario, the user doesn't need to worry. When creating a new key, we automatically create both, one primary and one sub key. (So you have two secret keys and two public keys, that is the structure that builds your full personal key. You can see primary and sub key in key manager, detail view, if you click the structure tab.)

In the simple scenario, both keys have the same expiration date, and you'd want to change the expiration date on both keys.

Unfortunately, advanced users have full flexibility and create very complicated scenarios. You can keep your signing key, extend it, and let your encryption key expire, and create a new encryption key. (You'd need to use advanced GnuPG functionality to initially define and manage such a key, but Enigmail was able to work with such keys.)

While Enigmail doesn't seem to offer to create complex key structures, it at least allowed some flexibility when changing the expiration date of a key. It offered the user to change the expiration of your "sub keys" individually.

We need to decide what level of complexity we'd like to offer.
If we want to offer full complexity, then we'll need a complex UI !

I'd prefer to start with a simple approach, that allows user to extend their key, only if it's a simple key. For complex keys, I propose to start by saying "sorry, we cannot edit this key, because it has a complex structure."

I suggest to accept the following scenarios as "simple" keys:

  • a structure that uses a single key for all purposes (rare but exists)
  • a structure that uses one primary and one sub key, and both keys have the same creation date and the same expiration date

If there are more than one sub key, or if the date/expiration of the sub key differs from the primary key, I'd reject it as "too complex".

With this, we'd only require a very simple user interface. We'd offer the user to define the new expiration date, in days, months or years from now (or define it as never expires).

This approach avoids the complexity that Enigmail offered (which had a grid, listing all sub keys, and a checkbox in front of each primary and sub key).

Years ago, when I created the key manager, I thought that I need to implement everything that GnuPG allowed to do. The key manager was meant as a front-end for managing GnuPG. I would not repeat this anymore, but instead focus on scenarios that users understand, and tailored to the needs of email security.

There are a few users who will want to modify the expiry of individual subkeys, but the majority of users doesn't even know that there are subkeys. The power users can still export the keys, do the modification in GnuPG and re-import the key in Thunderbird. All other users will be fine with a simple dialog that allows to change the expiry date, and Thunderbird would do the "right thing".

Summary: Support extending the lifetime of an OpenPGP key (expiry) → Support extending the lifetime of an OpenPGP key (change expiry)

I suggest to add an "Change Expiration Date…" button to the keyDetailsDlg, to the right hand side of the expiration date display.

The button would be visible for secret/personal keys, only, and only if the key hasn't been revoked.

When clicking that button, a sub dialog would open, that could show the following text:

This key is configured to expire on <date>.
After a key expires, it's no longer possible to use it for encryption or digital signing.

If you wish to use this key for a longer period of time, you must change its expiration date,
and then share the public key with your conversation partners again.
You can share it by attaching it to the emails you send.

Current expiration is in x years y months z weeks.

New expiration date: n months

When viewing the details of a secret/personal key, a new button will be shown on the right hand side to the expiry information.
"Change Expiry Date…"

Attached image key-expiry-dlg.png (obsolete) —

If the button is clicked, this dialog will open.

The first line is dynamic, and can have one of three different states.

The bottom edit fields are dynamically enabled/disabled based on the radio selection.

The motivation for having a "keep" radio selection:
I'd like to avoid that users open the dialog and simply click OK, and trigger a modification of the key.

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

When viewing the details of a secret/personal key, a new button will be shown on the right hand side to the expiry information.
"Change Expiry Date…"

Good positioning.
Would be better to use the openpgp-key-man-change-expiry string we already have, which is Change Expiration Date and is already used in the e2e UI

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

Created attachment 9160445 [details]
key-expiry-dlg.png

The initial text is a bit too cramped and there's no rhythm to it.

We should put an emphasis on the expiration time, something like:
This key will expire in 8 days, on 2020-07-09.
It's better to use the YYYY-MM-DD format to avoid confusion with US users which put the month before the day.

The message After a key expires... should be wrapped around the blue info container we use in the new Key Wizard.

Let's include the accountManage.css file in this dialog to inherit the correct styling.

The 2 bottom radio options should respect the order and styling of the new Key Wizard.

For the date formatting we should format according to the user settings, like elsewhere in the UI. But saying how many days it is a bit odd... People do know what date it is.

Seems a bit complicated to me to have another dialog. You could do something with an <input type="date"/>. I notice we have a lot of error messages which could just be avoided if we'd use that with automatic validation.

Adding a date input seems unnecessarily detailed. We don't want to bother people having to think about an exact date. It's the duration that we want.

I don't understand which automatic validation you're referring to.

If the user opens that dialog, we should suggest a reasonable default duration. Another two years from today seems like a reasonable number, given that we consider to use an initial default duration of 3 years (bug 1637179).

That means, most people don't have to change those values. They notice that they should extend, because their keys expires. They open the dialog. They see the suggested 2 years. They click OK. Done.

I don't understand your suggestion to avoid another dialog. That dialog can have some explanation, to remind what the consequences of an expiring key are.

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

Adding a date input seems unnecessarily detailed. We don't want to bother people having to think about an exact date. It's the duration that we want.

The though is, correctly, that the actual date is not important. It's just that the input widget provides for giving a vaoue and makes sure you don't enter dates in the past, too long in the future and whatnot.

The "value" of having just the widget is that you don't really need less controls - it's just an editable date.

<input type="date" value="2023-06-30" step="31" min="2020-07-30" max="2120-06-30"/>

I don't understand which automatic validation you're referring to.

E.g. we have validation that you can't have too short expiry or too long. The <input> will do that for you.

Thanks for your suggestions and explanations.

If you don't like the display of the remaining validity in days, I'll remove that.

Magnus, the potential for error messages is really small. The "too short" is just a technical test, if the user decides to enter zero or a negative number. I don't think many will attempt that. And the too bug is only triggered for a value more than 100 years. Also unlikely that someone will enter that.

I don't think these two scenarios justify the visual complexity of having a detailed calendar widget, and the brain work to decide about a special date. If you see a calendar widget, and want to go 5 years in the past, that's several clicks.

I would like to insist on opening a dialog to query the user what to do. It allows us to give background information to the user. And it ensures that the user doesn't click accidentally on a control and modifies the date, which wasn't really intended. And by having the button "Change Expiration Date" it makes this possibility discoverable - otherwise the user might not know yet this is possible.

Also, the dialog is useful when opening this element from within the account preferences, which also show that a key is expired, and offer to extend it.

I would like to confirm that all dates that you see in screenshots are formatted according to the user's locale configuration.

I have a different idea for simplifying this dialog.

I think it's unnecessary to offer the user full flexibility when extending the expiration.
It seems sufficient to restrict it to months granularity.
Also, it seems unnecessary to allow the user to shorten the validity.

This means, we could have a dropdown box that offers the numeric amount of months that we consider reasonable, and we already select a reasonable choice.

If the key has not yet expired, we can calculate the current remaining validity in months.
For example, if the key expires in 2 months and 14 days, we'd offer 4 months as the smallest available option. The dropdown would exclude values 1, 2, 3.

The maximum number offered value could be 10 years, 120 months.

By default, 24 months are selected (relative to "today").
If key is currently valid for more than 2 years, we'd add one more year to its validity by default.

If the key is already valid for 10 years or more, we'd not offer the ability to extend it further. Only offer the ability "does not expire".

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

I don't think these two scenarios justify the visual complexity of having a detailed calendar widget, and the brain work to decide about a special date. If you see a calendar widget, and want to go 5 years in the past, that's several clicks.

It's usually just 5 clicks away.
Anyway, not too keen on showing it in months only. People do think in years for the normal amounts of time the expiry should have.

I would like to insist on opening a dialog to query the user what to do. It allows us to give background information to the user.

I think we should aim to show as little as is needed. Advice on what to do after, should be shown after the action was really taken.
Instead of dialogs it would also be nicer to just have information show up inline.

Attached image extend-expiration-v2.png (obsolete) —

Do you like this one better?

Attachment #9160445 - Attachment is obsolete: true

Alessandro, I tried to add the blue highlighting bar, by copying code from e2e, but I'm not getting it.
I'll upload my latest patch.
Could you help me identify the necessary change, or maybe this could be done in a follow-up?

I've also simplified the text.

Assignee: nobody → kaie
Status: NEW → ASSIGNED
Flags: needinfo?(alessandro)
Flags: needinfo?(mkmelin+mozilla)

Could you help me identify the necessary change, or maybe this could be done in a follow-up?

We can do this in a follow up bug, also because the description XUL tag is currently busted and doesn't wrap text properly, fun!

I also think that showing the extension only in months it's a bit strange and we should keep the choice consistent with what we offer in the Key Wizard. (attachment coming).

Flags: needinfo?(alessandro)
Attached image Screenshot from 2020-07-01 13-08-29.png (obsolete) —

Also the order of choices should be respected.

  • Do not change
  • Key expires in...
  • Key doesn't expire

Thanks, will use that control and layout/order. I'd prefer to keep it at granularity months initially, to simplify my work, and have more time for other priority work. The complication is that the extending needs to calculate the minimum value we want to offer here, depending on granularity. We can make it more flexible later.

If I understood correctly, you're calculating the new expiration date from "today" (the day the user changes the date), and not the actual expiration date of the key, right?

For example, if the key expires in 2 months and 14 days, we'd offer 4 months as the smallest available option. The dropdown would exclude values 1, 2, 3.

Is this necessary?
If the key expires in 2 month, and the user selects 1 month, shouldn't the key expire in 3 months?

I think we should change the wording of the 2nd option.
Instead of Key expires in:, we should use Extend expiration date by:
In this way we don't need to worry about calculating the min limit for the user, and we can directly add the newly selected time to the current expiration date.

thanks, that's a good idea...

Just to summarize my suggestion one more time: The simplest way to show this is a checkbox (not radio choices) and date input

[ x ] Key expires [ 2020-09-20 ]

Could be readonly until a button is clicked.

Flags: needinfo?(mkmelin+mozilla)

(In reply to Magnus Melin [:mkmelin] from comment #24)

Just to summarize my suggestion one more time: The simplest way to show this is a checkbox (not radio choices) and date input

[ x ] Key expires [ 2020-09-20 ]

Could be readonly until a button is clicked.

But that's a different style than what Alessandro is using in the create key dialog.
You'd have to be consistent there, too.

I think brevity isn't a win here. I think "key does not expire" is easier to understand than "unchecked".

Before I touch this any more, I need a clear decision how to do it.

Given that we weren't able to agree on something more complex yet, here's the smallest possible UI that I can think of, which is also consistent with Alessandro's new key creation dialog, according to attachment 9160745 [details]

[a sentence that mentions the current expiration state, past or future, as suggested initially in the patch]

New expiration:
(*) Extend expiration date by: [2] ^ (days/months/years)
( ) Key does not expire

ok / cancel

(year selected by default)

I want to note the disadvantage of this minimal UI. People might open that dialog multiple times, and click OK each time, without really understanding what they are doing. Thereby they would create a key that has an expiration date very long in the future, something which they really shouldn't do.
You might think that the limitation to "months" is a bit weird, I'm not sure on that, but at least that dialog makes it clear what happens, gives reasonable explanation, and limits the amount of damage the user can do (at most ten years in the future)

Magnus, I was ready to be persuaded by you, and try an input of type=date". But it doesn't seem to work. I'm following references exactly, but all I see in the UI is a minimal sized input (one char width) without any possibility to change it.

Right now I don't want to spend time to analyze what's going wrong. We have higher priorities than making the way of entereing the validity perfect. Please let's use just any straightforward mechanism to enter the expiry date. This dialog isn't set in stone, we can always change it in another iteration.

<html:input type="date" id="new-expiry-date" value="2020-12-31" step="31" min="2020-07-01" max="2020-12-31" size="10"/>

There is another detail which I don't like about your suggestion to use "extend expiration by".

This wording is ambiguous. It is unclear what the base date the for "extend by" period is.

Is it based on the old expiration date?
Well, then an input like 3 months could still be in the past, if the key expired 4 months ago.
Or is it based on today?
Well, then an input like 3 months could actually shorten the expiration date, if the key will be valid for another 4 months.

In my opinion, the new expiration date must be given in "new validy period after today", that seems the most logical measurement to me.

But if we do that, then we must ensure to forbid any value that is shorter than the current expiration date (which e.g. might be 4 months in the future).

If you allow alternative input in days/months/years, then it is difficult to ensure that minimum limit. We'd have to dynamically calculate the new minimum value each time the user switches between the units, and if necessary, update the shown value.

The implementation I have suggested avoids that complexity.

Attached image expire-new.png —

Alessandro, based on the arguments given, would you accept this dialog for now?

If there are still concerns, I think we need to schedule a meeting.

Attachment #9160745 - Attachment is obsolete: true
Attachment #9160737 - Attachment is obsolete: true
Flags: needinfo?(alessandro)

Please remember that we are racing towards a deadline.

The deadline for starting localization for TB 78.2 is end of July.
And I must a complete a lot of additional functionality by that date, which also includes UI strings.

I think we should stick with this dialog and the radio selection option instead of the input date.

I see the benefit of a native input date for validation, but in this case it's not very intuitive and requires some further styling.
We can definitely try to implement it in the future but it should happen in a follow up bug taking care also of the Key Wizard to maintain consistency.

Instead of "Key expires in:", we should use "Extend expiration date by:"

Any reason why you didn't follow the suggestion from comment 22?

Flags: needinfo?(alessandro)

(In reply to Alessandro Castellani (:aleca) from comment #33)

Instead of "Key expires in:", we should use "Extend expiration date by:"

Any reason why you didn't follow the suggestion from comment 22?

Can you please read comment 30? It explains why I think this is ambiguous.

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/05aec7cef1fa
Support extending the lifetime of an OpenPGP key (change expiry). r=PatrickBrunschwig

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

Comment on attachment 9160740 [details]
Bug 1634561 - Support extending the lifetime of an OpenPGP key (change expiry). r=PatrickBrunschwig

important OpenPGP feature for 78.x

Attachment #9160740 - Flags: approval-comm-esr78?

Comment on attachment 9160740 [details]
Bug 1634561 - Support extending the lifetime of an OpenPGP key (change expiry). r=PatrickBrunschwig

OpenPGP - uplift request for consistency of comm-esr78, beta79 and c-c80

Attachment #9160740 - Flags: approval-comm-beta?
Target Milestone: --- → Thunderbird 80.0

Comment on attachment 9160740 [details]
Bug 1634561 - Support extending the lifetime of an OpenPGP key (change expiry). r=PatrickBrunschwig

Approved for beta
Approved for esr78

Attachment #9160740 - Flags: approval-comm-esr78?
Attachment #9160740 - Flags: approval-comm-esr78+
Attachment #9160740 - Flags: approval-comm-beta?
Attachment #9160740 - Flags: approval-comm-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: