Very soon we must decide what properties we should use for new OpenPGP keys by default:

• expire or not expire? If expire, how long is default validity?

• RSA or ECC? If RSA, 3072 or 4096?

There are good arguments for all choices, so it isn't easy to make that decision.

I'd prefer an expiration, but suggest to use a longer expiration, for example 3 years.
We could use an RSA 3072 key for wider compatibility.

It's not clear to me there is true value in expiry, except for if the encryption used in the future gets broken .
Assuming you still have the key once it's about to expire it should be possible to update the key as needed in the future.

What would be a concern for normal users that would cause them to want to have an expiring key?

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

It's not clear to me there is true value in expiry, except for if the encryption used in the future gets broken .
Assuming you still have the key once it's about to expire it should be possible to update the key as needed in the future.

What would be a concern for normal users that would cause them to want to have an expiring key?

An expiring OpenPGP key saves yourself from trouble and weak security
in the future.

A majority of people will probably NOT take much care with their key,
don't have a backup, and will lose the secret key eventually.

Even if you lose your secret key, other people can still use your public
key to send you encrypted email. And they will!

Last year an insurance company sent important documents to me by email.
As a complete surprise, they encrypted the email with OpenPGP!
I had never told them to use encrypted email!

They probably had discovered my personal key on a keyserver.
(And if you have a non-expiring key, chances are that your key will
be listed somewhere on the web, in a directory, or saved in someone's
keyring, even many years later.)

Given this was a big insurance company, how do you resolve that
situation? The agent probably didn't control encryption, likely it
was an automated system.

Even if there is a chance to convince other people to change their
encryption setup, it's a hassle. They might have trouble identifying
your old key and have difficult to delete it. And unless their software
has a built in mechanism to blacklist a key, they could simply import
the key again on the next occassion, when searching for your key.

I still had a copy of my own secret key, but it was an old key that I
haven't used in a long time. I no longer remembered the passphrase for
that old key!

Having an expiration on a key is an insurance that eventually, this
key will stop causing you trouble in the future, if you mess up and
haven't kept a usable copy of your secret key.

Another good reason is the security level of the key material in a key,
or the availability of software that can work with the key algorithm
that was used for the key.

My old key was from 2003, it used a pair of DSA 1024 and ElGamal 2048.
That's probably no longer a good choice today, so it makes sense to stop
using it eventually.

An expiring key can be considered a hassle. If you don't extend it ahead
of time, and if you don't distribute it to your correspondents ahead of
time, then your correspondents will no longer be able to use it after
expiry.

I think that Thunderbird should implement the following assistance to
avoid that issue:

• remind users to extend their own key well ahead of time, e.g. 3 months in advance

• we can autmoatically include the updated key in openpgp email we sent

• when receiving email that contains an openpgp key, we should have some smart automatica beahvior to refresh the incoming key. While usually, we shouldn't import a new key without the user's feedback, it seems fine to automatically refresh keys that the user already has. In other words, on receiving an email with a key, we should scan the key. If the key is already present (same key material), but the key contains a refreshed expiry date (this is transported as an additional signed attribute that can be verified to be legitimately done by the key owner), then we can autmatically update the stored key to include the new expiration date.

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

There are good arguments for all choices, so it isn't easy to make that decision.

So true. It can make one crazy.

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

I'd prefer an expiration, but suggest to use a longer expiration, for example 3 years.

I can honestly say that I shrugged here. 3 years is really not long for me. More a good moderate time.
Long for me is 20 years. 10 years is at least not short for me, a reasonable time.
Short for me is 1 year. 3 years is at least not long for me.
I would suggest, in any case a key should expire in 10 years and it's expiry date should not be extendable over that time.
Because: Who can really trust such an old key? In fact, not even the owner himself, I think. Who can trust that the secret key was never stolen or otherways compromised. Who knows if the owner has still access to the private key on the other side.

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

A majority of people will probably NOT take much care with their key,
don't have a backup, and will lose the secret key eventually.

+++ Yes, and therefore, they will also create regularly new keys. And after years, You could have dozens of keys of a user, all without expiry time. Or the user changed his email address and generates new keys for the new mail address and will never the old address (or lost the DNS domain and therefore the corresponding mail addresses). So, at least after 10 years a key should expire, I think.
I think, an argument for a short expiry like 1 or 2 years (or I could live also with 3 years) time would be the key trust again. I think the whole complex mechanism of key verification vitally needs a revocation mechanism, without that, the original trust could transfer in an attack vector if the key was stolen within some years and could be misused to fake authenticity then, and the receiver really thinks: "Well, that must be true, I verified this key!". Better would be if the key already would expire every 3 years and a new key must be _re_verified, or taken as untrusted, which is untrusted like clear text mail, but better, because at least it is encrypted.
But this revocation mechanism is so complicated and boring.
I can give real honest user feedback for the revocation mechanism: Couple of weeks ago I created a new mail address (I regulary create mail addresses which are communication partner specific, so I have not to care about possible spam or stolen mail addresses, I could delete the mail alias again and even inform the partner, that his customer database well could be stolen). Since the partner (german data privacy agency) also can use OpenPGP(Applause!) I also wanted to use that, so I created a new key with TB68+Enigmail. Key generation was fast, that was nice. Then, there came a big warning: "You are urged to create revocation certificate, make a backup, protect it with a password, store it safe" and so on, I thought "blah blah", really not, and clicked it away. I really found this so boring and complicated, just for a theoretically possible case, and my communication partner would rarely ever get knowledge of this revocation certificate. Maybe I will only communicate with them only in maybe 8 years again? Will I have my trusted computer then still? Who knows?
And, I guess am pretty security aware and have some good knowledge of e2eee (and over 15 years IT admin). But what about a rather normal user who really does not understand this revocation thing at all and normally doesn't care to send unencrypted because he has nothing to hide? I guess this revocation thing is really not usable, at least without a central server where You can upload them and clients regulary lookup the keys. Then You have privacy issue again etc. etc.
Drawback of an expiry date of course is that like your insurance company do not find a valid key, they might send just unencrypted.
I could image expiry time of 3 years, with automatically generation of a new replacement key in the background without user interaction 6 months before expiry and automatically switching to attach the new key at outgoing mails (propagation), maybe even signed with the old key.

I agree we need to have a revocation story.
On key generation, we'll save revocation certificates automatically in the Thunderbird profile directory. So you can go back to your profile directory, and retrieve it, even if you have a master password set and have forgotten it.
If the user was careful, revokes a key, the user probably still has the revoked key in the TB keyring.
If yes, and the user configures a new key for the same email address, and when sending out the new public key by email, then I'd like to bundle the old revocation statement. And it would be nice to have Thunderbird automatically process an attached revocation statement.
But that's something for a separate bug.
General discussion is probably best to happen here:
https://thunderbird.topicbox.com/groups/e2ee

I created a Topic Topicbox for general discussion on this:
https://thunderbird.topicbox.com/groups/e2ee/T018b43a2f63e8884/decide-about-defaults-for-new-openpgp-keys-in-tb-78-expiration-key-type-and-size

Alessandro, FYI.

Attached patch also fixes bug 1637412.

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/47aefd784341
Change OpenPGP key generation default to 3 years, type RSA, 3072 bits. r=PatrickBrunschwig

Comment on attachment 9161563 [details]
Bug 1637179 - Change OpenPGP key generation default to 3 years, type RSA, 3072 bits. r=PatrickBrunschwig

Change an OpenPGP key attribute default, which was useful while testing, to the recommended default for users of production Thunderbird 78

Comment on attachment 9161563 [details]
Bug 1637179 - Change OpenPGP key generation default to 3 years, type RSA, 3072 bits. r=PatrickBrunschwig

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

Comment on attachment 9161563 [details]
Bug 1637179 - Change OpenPGP key generation default to 3 years, type RSA, 3072 bits. r=PatrickBrunschwig

Approved for beta
Approved for esr78

https://hg.mozilla.org/releases/comm-esr78/rev/62d8e2ccbd75343a22f55f7f4a8c6f2f7a982887
https://hg.mozilla.org/releases/comm-beta/rev/b298c582e59e5607d115cbd0df44397327e30a5e