1704182 - openpgp: extending expiration date doesn't extend expiration of the first user id

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, defect)

Description

[Ralf Jung]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

I just updated to Thunderbird 78.9.1. Ever since the update (I am not sure what exactly the previous version was, but it was 78.something), I cannot send encrypted messages to one of my contacts any more. (Other contacts seem to work fine.) The same contact and key worked fine earlier this week. Looking at the "OpenPGP Key Manager", it only lists the 'main' address of the key, but not the other addresses. When I import the same key into regular GPG, both addresses show up. For other contacts, some of them have multiple addresses and that does show up in Thunderbird.

Somehow, it looks like Thunderbird "forgot" the other address of this key, and even deleting and re-importing it will not fix that. Sadly this means I cannot communicate encrypted with my contact (they barely use their other address), so this is quite problematic from a security perspective.

Is there any way to convince Thunderbird of the existence of both of the email addresses for this key?

Comment 1

[Ralf Jung]

Turns out my contact has the same problem "in reverse": when they send an encrypted email to me from the affected address, that works, but when they look at that email, Thunderbird says that the signature is invalid because the "message was sent from an address not matching the public key of the signature" (paraphrasing here, the message is shown in German). So, just like on my system, it looks like Thunderbird fails to realize that this key is valid for the given address.

Comment 2

[Ralf Jung]

Any chance of someone looking into this? Even after the update to 78.10.0, I am still unable to communicate encrypted with this contact.

Comment 3

[neal]

78.9.1 did indeed introduce new code that would influence this behavior, e.g., in this commit from March 17th.

It would be good if you could attach a certificate that demonstrates the problem so that we can reproduce the issue.

Comment 4

[Ralf Jung]

Thanks for coming back to me! I'm happy to email the affected public key to you (or another developer) privately -- but it's not my public key so I wouldn't want to just upload it here. Would that work?

Comment 5

[Kai Engert (:KaiE:)]

Ralf, thanks for sending us the example key.

For each user ID included with an OpenPGP key, there is an associated signature, which was made at the time the user ID was added.

In your scenario, for the user ID that is missing with newer Thunderbird, the signature contains an expiration date, and it has already expired in January 2021.

I think that our RNP engine correctly decides that user ID is no longer valid.

Comment 6

[Ralf Jung]

Thanks for taking a look! So you are saying, the two addresses have different expiration dates in this key?

The odd thing is, I am pretty sure I used the key with the now-missing address after the prior expiration date in January, but before the Thunderbird update mentioned above. But maybe the old Thunderbird ignored the mismatching dates, and used the same for both addresses?

The other odd thing is that my contact is using Thunderbird to manage this key, so if the expiration date is different for the two addresses, it looks like when my contact asked Thunderbird to extend the validity of the key, Thunderbird did that only for one of the two addresses of that key... I haven't done this myself yet so I don't know if there is the possibility of a user error here (selecting the wrong thing in the UI).

Comment 7

[Kai Engert (:KaiE:)]

(In reply to Ralf Jung from comment #6)

Thanks for taking a look! So you are saying, the two addresses have different expiration dates in this key?

Yes. You could have a look yourself, for example using a tool like pgpdump.

The odd thing is, I am pretty sure I used the key with the now-missing address after the prior expiration date in January, but before the Thunderbird update mentioned above. But maybe the old Thunderbird ignored the mismatching dates, and used the same for both addresses?

Thunderbird 78.x versions earlier than 78.9.1 didn't check the user ID signature dates.

The other odd thing is that my contact is using Thunderbird to manage this key,

The key you have sent is in your name.
If you're talking about a different key in a different name, then I haven't looked at that other key yet.

Is there another key that has problems? Do you want to send it to me, too?

so if the expiration date is different for the two addresses, it looks like when my contact asked Thunderbird to extend the validity of the key, Thunderbird did that only for one of the two addresses of that key...

Can you please clarify the expiration of which key was extended using Thunderbird 78?
Your key (in the name of Ralf), or a different key? If a different key, can you please send it to me?

The key management functions of Thunderbird 78 are currently limited.
It currently doesn't support changing the expiration date of user IDs, only of the keys.

In other words, if you have used other software to create a key with expiring user IDs, then you cannot use Thunderbird to extend the lifetime of the user IDs. You must use other software to extend it, and then import the key into Thunderbird again.

The keys Thunderbird itself creates may have an expiration date for the key itself, but Thunderbird doesn't set an expiration date for the user ID.

Comment 8

[Kai Engert (:KaiE:)]

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

The keys Thunderbird itself creates may have an expiration date for the key itself, but Thunderbird doesn't set an expiration date for the user ID.

I need to double check that.

Comment 9

[Kai Engert (:KaiE:)]

I was wrong.

Thunderbird 78 creates keys that have an expiration date set for both the user ID and the encryption subkey.

When extending a key that was created using Thunderbird, it updates the expiration date for both the user ID and the subkey.

I need to test what happens if we extend the expiration of a key that has multiple user IDs.

Comment 10

[Ralf Jung]

They key I sent you is not in my name... I am confused about that part of your statement.^^ The last name is the same since it's my father's key. ;) We're also using the same email domain (which has my name in it). But the first name in the key is not "Ralf".

The key was created with Enigmail a few years ago, and auto-imported by Thunderbird when Enigmail support was dropped. So, using the "other software" for this is no longer possible, due to Thunderbird not supporting Enigmail any more. This is on a Windows machine, so I wouldn't know how to directly use the GPG CLI, nor was there ever any other GPG UI installed on that system. I was assuming that migration would take care of doing whatever needs doing so that keys previously created with Enigmail continue to work?

Thunderbird 78.x versions earlier than 78.9.1 didn't check the user ID signature dates.

Okay, so we have explained the chain of events then, that's great.

What is left, as far as I am concerned, is figuring out how this key ended up in this weird state, and if Thunderbird might be (partially) responsible for this situation. I'd also be interested in ways to fix this key so that Thunderbird can properly extend its expiration in the future (but I guess we can generate a new key if needed...).

Comment 11

[Ralf Jung]

I've since had the chance of looking at this on my Dad's computer. When opening the details for this private key, the affected email address does not even show up! Only the other one does. So no wonder that asking Thunderbird to extend the validity period of this key will not do anything for an email address that Thunderbird does not even seem to realize has anything to do with this key at all.

This key is almost 10 years old, and validity has been extended several times in the past without this issue (using Enigmail -- so I can't try if this would still work now on the latest "strange" version of this key). To me this looks like a bug in the "extend validity" feature of Thunderbird's PGP implementation. It might also be noteworthy that when this key was originally created, only the main (still-working) email address existed -- the new (no-longer-working) email address was added later (again using the Enigmail UI).

We've now created a new key, but of course that is not a satisfying solution. The old key was fine until January this year, when Thunderbird was used to extend its validity which somehow moved it to a bad state.

Comment 12

[Kai Engert (:KaiE:)]

Ralf, thanks for the additional details you have provided. Regarding the key not being in your name, I had not looked closely, and probably noticed the common last name.

I am able to reproduce the bug.

I used the following steps:

• set system date to january 2020
• used gpg to create a key, expiring in one year, used id aaaaa
• set system date to march 2020
• used gpg to edit the key and added a second user id bbbbb
• back to regular system date, the key is already expired
• import the secret key into thunderbird
• use thunderbird to change the expiration of the key
• notice that thunderbird no longer shows user id aaaaa

Nickolay:

TB calls rnp_key_set_expiration twice - one for every subkey.

RNP sets a new expiration for the second user id (bbbbb), and sets a new expiration for the subkey, but it doesn't modify the expiration of the primary user id.

Is this a bug in RNP ?

Comment 13

[Kai Engert (:KaiE:)]

Attachment: 2.asc

This is an example secret key, after step 2 - after having edited the key using gpg to add a second user ID.

Comment 14

[Kai Engert (:KaiE:)]

Attachment: 3.asc

This is the result of imorting 2.asc into Thunderbird, performing the described steps, then exporting the secret key to a file.

Password for secret keys is: x

Comment 15

[Ralf Jung]

I used the following steps:

Yes, that sounds great!
I think back when the key was created, the second email address did not even exist yet. So indeed what probably happened is that we added the second email address using Enigmail (and thus, under the hood, gpg) somewhere in the middle of a validity period, and that way, the two signatures could end up with different validity periods.

Comment 16

[Nickolay Olshevsky]

Thanks for digging into this issue, somehow missed the thread. Confirmed, issue is on RNP's side - we update expiration only for the latest self-signature, while we should update latest self-signature for all uids (and direct-key sigs as well).
Filed an issue at https://github.com/rnpgp/rnp/issues/1497

Comment 17

[Nickolay Olshevsky]

Fixed in RNP and included into the v0.15.1 release.

Comment 18

[Kai Engert (:KaiE:)]

This works for me, using the updated RNP. After using TB to change the expiration again, the other user ID reappears.

Marking fixed in tb 91.

It might be a few weeks until the releases becomes available in stable 78.x.

Comment 19

[Magnus Melin [:mkmelin]]

Marking fixed 78 to get it of the list. Will be fixed in 78 once bug 1713664 is uplifted.