User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Using Thunderbird Daily 94.0a1 (2021-09-15) (64-bit) on Windows 10 Education version 21H1 (19043.1165)

1. Go to Tools > OpenPGP Key Manager
2. Go File > Import Public Key(s) From File
3. Select the provided armored key file "E1F34FEAC85D9788C67555F1348F028C7FCB2899.asc"
4. Click "Open"
5. Mark the key as "Accepted (unverified)" and click "OK"
6. Click "View Details and manage key acceptance" link within dialog
7. Click on the "Structure" tab within the "Key Properties" dialog

Actual results:

Observe that the key is listed as having expired on 2/25/2021

Observe that the key has three sub-keys each with an expiry of 2/24/2024 and a creation date of 2/24/2021

Observe that the key has three additional sub-keys each with an expiry of 2/25/2021 and a creation date of 2/26/2018

Expected results:

The key should have been determined to be valid and not determined to be expired.

For example, when GPG 2.2.29 is presented with this key, it determines that the key is valid and unexpired, listing an expiry date of 2024-02-25 for the overall key:

$ gpg --list-key E1F34FEAC85D9788C67555F1348F028C7FCB2899

pub rsa4096/0x348F028C7FCB2899 2018-02-26 [SC] [expires: 2024-02-25]
Key fingerprint = E1F3 4FEA C85D 9788 C675 55F1 348F 028C 7FCB 2899
uid [ unknown] Erik Moeller <erik@freedom.press>
uid [ unknown] Erik Moeller <eloquence@gmail.com>
sub rsa4096/0x63630D6D583EC177 2021-02-25 [E] [expires: 2024-02-25]
sub rsa4096/0x566B4DE9A79F9C09 2021-02-25 [A] [expires: 2024-02-25]
sub rsa4096/0xE0C90B9872E16D73 2021-02-25 [S] [expires: 2024-02-25]
sub rsa4096/0xEF07C18956EA2394 2018-02-26 [E] [expired: 2021-02-25]
sub rsa4096/0x9D1AB0D26E5326A8 2018-02-26 [A] [expired: 2021-02-25]
sub rsa4096/0xB42DA2F34A721EAD 2018-02-26 [S] [expired: 2021-02-25]

Additionally, it seems that this GPG command and Thunderbird disagree on the creation date of some of the sub-keys, as while Thunderbird says, for example, that sub-key 0x63630D6D583EC177 was created on 2-24-2021, GPG indicates that it was created a day later on 2-25-2021.

Screenshot showing Thunderbird key structure alongside differing key details produced for the same key by GPG 2.2.29

The rnpkeys utiliy says:

pub 4096/RSA (Encrypt or Sign) 348f028c7fcb2899 2018-02-26 [SC] [EXPIRED 2021-02-25]
e1f34feac85d9788c67555f1348f028c7fcb2899
uid Erik Moeller <eloquence@gmail.com>
uid Erik Moeller <erik@freedom.press>
sub 4096/RSA (Encrypt or Sign) 63630d6d583ec177 2021-02-25 [E] [EXPIRES 2024-02-25]
f7dae94bf77dd0a6518d6d9b63630d6d583ec177
sub 4096/RSA (Encrypt or Sign) 566b4de9a79f9c09 2021-02-25 [A] [EXPIRES 2024-02-25]
05e8163687b7f1623692f078566b4de9a79f9c09
sub 4096/RSA (Encrypt or Sign) e0c90b9872e16d73 2021-02-25 [S] [EXPIRES 2024-02-25]
83d0c74a6f5ff711d479540fe0c90b9872e16d73
sub 4096/RSA (Encrypt or Sign) ef07c18956ea2394 2018-02-26 [E] [EXPIRED 2021-02-25]
016198fea32ddba2f2798f95ef07c18956ea2394
sub 4096/RSA (Encrypt or Sign) 9d1ab0d26e5326a8 2018-02-26 [A] [EXPIRED 2021-02-25]
75b686d58aa39269a78eae619d1ab0d26e5326a8
sub 4096/RSA (Encrypt or Sign) b42da2f34a721ead 2018-02-26 [S] [EXPIRED 2021-02-25]
b46ebf095f6dc5a051986cc5b42da2f34a721ead

Looking at the packet dump, I see a signature packet to change the expiration date of the freedom.press user ID. But apparently there is no such packet for the gmail identity.

Maybe that's the reason for RNP's decision?

We recently had a similar issue in bug 1673993.

Nickolay, should RNP treat this key as "not expired"?

I just remembered bug 1704182 (which isn't fixed on 78.x apparently).

Did Erik use Thunderbird to extend the expiration of the key?
If yes, he should try extending the expiration again, using stable Thunderbird 91.x

I do not know how he extended the key. I will link them to this bug report and try to find out.

Thanks for reporting. The explanation here is as following:

Userid at freedom.press has two certifications:

• one made in 2018, with ~3 year validity,
• second made in 2021, with ~6 year validity (calculated from key creation date, i.e. 2018).

However, first one marks userid as primary, and the second one doesn't mark it as primary.
RNP chokes on this, since it first looks for certification, which marks some uid as primary, and doesn't look ahead for newer certifications for the same uid.
We'll update RNP to behave correctly in this scenario.

Thanks for the analysis.

I'm very surprised that GnuPG allows to use the key with the expired user ID. Does GnuPG ignore individual expiration of user IDs, and will allow all user IDs, if at least one user ID is not yet expired?

Do you think it would be a good idea to discuss this with the GnuPG team, or even on the openpgp ietf list, and agree on common behavior?

(In reply to Emily Mabrey from comment #0)

Additionally, it seems that this GPG command and Thunderbird disagree on the creation date of some of the sub-keys, as while Thunderbird says, for example, that sub-key 0x63630D6D583EC177 was created on 2-24-2021, GPG indicates that it was created a day later on 2-25-2021.

Forgot to reply on this - most likely it's because of time zone shifts. Internally in PGP packets time is stored in UTC, and RNP functions return it in UTC as well.

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

I'm very surprised that GnuPG allows to use the key with the expired user ID. Does GnuPG ignore individual expiration of user IDs, and will allow all user IDs, if at least one user ID is not yet expired?

Do you think it would be a good idea to discuss this with the GnuPG team, or even on the openpgp ietf list, and agree on common behavior?

We had the discussion on this topic here: https://github.com/rnpgp/rnp/issues/1510
Technically, gmail.com userid is valid as it has one valid certification. However, that certification has key expiration time in the past, but that's about the key itself not userid.

Ok. Nickolay, can you please explain what new behavior you plan to implement?

After the fix, which user IDs will you treat as valid?
Only the freedom.press, or both user IDs?

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

Ok. Nickolay, can you please explain what new behavior you plan to implement?

After the fix, which user IDs will you treat as valid?
Only the freedom.press, or both user IDs?

Both userids would be reported as valid.
Currently (since RNP v0.15.2) both should be reported as invalid since key is mistakenly considered to be expired.

(In reply to Nickolay Olshevsky from comment #9)

(In reply to Emily Mabrey from comment #0)

Additionally, it seems that this GPG command and Thunderbird disagree on the creation date of some of the sub-keys, as while Thunderbird says, for example, that sub-key 0x63630D6D583EC177 was created on 2-24-2021, GPG indicates that it was created a day later on 2-25-2021.

Forgot to reply on this - most likely it's because of time zone shifts. Internally in PGP packets time is stored in UTC, and RNP functions return it in UTC as well.

I'm on UTC−04:00 currently (EDT).

(In reply to Emily Mabrey from comment #13)

I'm on UTC−04:00 currently (EDT).

Okay, that should be an explanation - mentioned subkey was created at timestamp 1614216541, which is GMT: Thursday, 25 February 2021 01:29:01
In UTC-04:00 it would be 24 February. It looks like GnuPG didn't pick time zone correctly.

(In reply to Nickolay Olshevsky from comment #12)

Both userids would be reported as valid.

Thanks for clarifying

Hi folks - thanks for troubleshooting this. I did not use Thunderbird to modify the key. It's a split master / subkey setup involving a GPG key smartcard; I rotated the subkeys instead of expiring them. This is the first time I've encountered this bug with a recipient. Please do let me know if there are any changes I should make to my keyring to preserve compatibility.

Thanks for writing back.
Issue is tracked on RNP side via https://github.com/rnpgp/rnp/issues/1632 , and fix will be included into RNP v0.16.0

JFYI: RNP v0.16.0 is out, including fix for this issue.

Marking as fixed, because Thunderbird 102 and later already ship RNP v0.16.0