1711443 - OpenPGP key with extended expiration and different expiration on subkeys handled incorrectly

Status: RESOLVED INVALID

(MailNews Core :: Security: OpenPGP, defect)

Description

[Kai Engert (:KaiE:)]

See the problem report in bug 1666507 comment 3 until comment 11.

Comment 1

[Kai Engert (:KaiE:)]

I'm summarizing, estolle claims:

• key with two user IDs, primary and alias
• key created 2016-11-01, expiration 2021-11-01
• on 2021-02-03, expiration changed to never

After investigation, Nickolay reported:

• yes, for primary and user IDs, expiration was changed to nver
• no, for subkey, expiration wasn't changed, the subkey will expire

However, in bug 1666507 comment 10 estolle disagrees with Nickolay's statement; estolle claims that Kleopatra does not show expiration for the subkey.

I think it will be helpful if you provide a human readable listing of the key from gpg, using
gpg --list-keys --with-subkey-fingerprints your-key-id

estolle reports that Thunderbird displays the primary key with no expiry (as expected), but the subkey is shown with the original expiration (will expire in 2021-11-01).

It seems Thunderbird displays the information that Nickolay expected, based on the packet dump.

In bug 1666507 comment 11 asks me, what is the expected display in Thunderbird's openpgp key manager, details, structure.
It is expected that for each subkey a row is shown, and that each row should show the expiration date of that primary key or subkey.
That works for me with another complex key I've looked at.

I think to move forward with this bug, we should be given the public key, so we can look at it more easily. If you don't want to publicly attached your public key here, could you please send it to me by email? [e-mail]

I need this to get clarity on the reported issue and to confirm if there is a bug or not.

Comment 2

[Kai Engert (:KaiE:)]

estolle has sent me their public key.

When listing the key with gpg, I get:

pub   rsa4096 2016-11-01 [SCA]
      primary-fingerprint
uid           [ unknown] name1
uid           [ unknown] name2
sub   rsa4096 2016-11-01 [E] [expires: 2021-10-31]
      sub-fingerprint

Thunderbird lists expiration dates in the same way,

With today's date, I'm able to use gpg to encrypt a message using that key.

As a test I changed the system date to 2021-11-02.
Now gpg refuses to use the key:

gpg: [stdin]: encryption failed: Unusable public key

I conclude Thunderbird behaves correctly. The effective expiration date is the date when the key can no longer be fully used for OpenPGP purposes, and if the encryption subkey expires, it can no longer be used for encryption.

In my opinion the display by Kleopatra is imprecise.

I don't see a bug in Thunderbird here, so resolving as invalid.

If you disagree, please explain why.

Comment 3

[makechanges]

I don't really understand what is going on, but the problem that I am having seems to be related to this issue.

Using gpg, I can verify that my public key is not expired - but for some reason Thunderbird shows that it is expired. I am also unable to use the "Change Expiration Date" option in the Key Properties dialogue box that I can get to through the OpenPGP Key Manager, because I get hung up on the "This is a key with a complex structure, changing its expiry date isn’t supported." message.

This did not seem to be a problem until I updated Thunderbird to 91.8.1 this morning. My key doesn't expire for another year, and was renewed about a year ago. I was able to send encrypted emails up until I updated Thunderbird this morning, but now Thunderbird says that the key expired in 2019.

Comment 4

[makechanges]

This also appears to be happening for a colleague, who also uses Thunderbird, and up until today my key worked fine for them.

Comment 5

[Nickolay Olshevsky]

Could you please check whether your key uses SHA1 hash in signatures? This can be done via gpg --list-packets keyfile.asc, and looking for digest algo 2.

Comment 6

[estolle]

(In reply to Nickolay Olshevsky from comment #5)

Could you please check whether your key uses SHA1 hash in signatures? This can be done via gpg --list-packets keyfile.asc, and looking for digest algo 2.

I can only find digest algo 8 in my output.

Comment 7

[estolle]

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

In my opinion the display by Kleopatra is imprecise.
I don't see a bug in Thunderbird here, so resolving as invalid.
If you disagree, please explain why.

Long time no see! Well, I disagree because it this is not about a display issue. A key either has expired or not. So either Kleopatra has a bug in its extension routine for expiry dates that Thunderbird isn't lured into or Thunderbird has a bug. I personally would put my odds on Thunderbird because such a bug in Kleopatra would have been known for a very long time as this is about a standard operation, isn't it?

Comment 8

[estolle]

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

Using Kleopatra, just now I encrypted a file trying all of my keys with extended expiry date. It worked. If the keys had expired earlier, I shouldn't be able to do so, right? If so, I believe Thunderbird has a problem.

Comment 9

[makechanges]

(In reply to Nickolay Olshevsky from comment #5)

Could you please check whether your key uses SHA1 hash in signatures? This can be done via gpg --list-packets keyfile.asc, and looking for digest algo 2.

Can you tell me what I should look for when I search for "digest algo 2"? There are entries for "digest algo 2", but nothing that states "SHA1"....

Comment 10

[Nickolay Olshevsky]

(In reply to makechanges from comment #9)

Can you tell me what I should look for when I search for "digest algo 2"? There are entries for "digest algo 2", but nothing that states "SHA1"....

2 is a number of SHA-1 algorithm in the OpenPGP packets. You may see more details on this issue here: https://bugzilla.mozilla.org/show_bug.cgi?id=1763641 as it seems problem is not related to this ticket but related to the SHA-1 deprecation.

Comment 11

[makechanges]

Using Thunderbird for encrypted email has all of a sudden become non-functional for me. More comments at https://bugzilla.mozilla.org/show_bug.cgi?id=1763641