1929026 - Unable to send signed email after expired OpenPGP key has been refreshed (from keyserver) with new expiration date

Status: NEW

(MailNews Core :: Security: OpenPGP, defect)

Description

[raffi.enficiaud]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:132.0) Gecko/20100101 Firefox/132.0

Steps to reproduce:

I had a GPG key/identity with several subkeys, and I imported in Thunderbird a modified version where only one of the signing and encrypting subkeys have their secret key. This worked perfectly fine, see eg. https://bugzilla.mozilla.org/show_bug.cgi?id=1753214#c30 for the detail of the GPG identity .

• In Thunderbird, I was notified that the key I am using for signing has expired (on the 01.11.24)
• I opened GPG Keychain on macOS and extended the validity date of the expired subkey, I then pushed the update to the keyserver
• back to Thunderbird, I opened the GPG key manager and clicked "refresh the key online"

Actual results:

• the key has been successfully updated and shows the new expiry date 29.05.2026 of the signing subkey
• as before, it shows an exclamation mark next to the "primary key" and the non relevant subkeys, and no exclamation mark on the encryption and signing subkeys I use
• when I try to send a message, I have an error "Sending of the message failed."

Note that sending encrypted emails without signing works (as well as just sending emails without any GPG signing/encryption).

Expected results:

I should be able to send the messages with the new, refreshed signing key.

Comment 1

[raffi.enficiaud]

Note: 130.0b3 is also affected by this problem.

Comment 2

[Magnus Melin [:mkmelin]]

Just to be clear, did you restart Thunderbird after refreshing?

Comment 3

[raffi.enficiaud]

Just to be clear, did you restart Thunderbird after refreshing?
yes

Comment 4

[Kai Engert [:KaiE:]]

Thunderbird stores and uses secret and public keys separately.

If you import an updated public key, your secret key will still contain the old expiration information, and the engine will refuse to use it for signing.

You need to re-import your updated secret key.
Can you please confirm that fixes it?

Comment 5

[raffi.enficiaud]

Thank you Kai for your explanations and for taking the time to answer.

Thunderbird stores and uses secret and public keys separately.
If you import an updated public key, your secret key will still contain the old expiration information, and the engine will refuse to use it for signing.

I have to say I don't know exactly how it works. My superficial understanding is that refreshing the key from the server will add some new certification to all the subkeys (and possibly add more subkeys) and this certification will have a new date. Certification for a subkey means that the primary identity, that I trust (tab "your acceptance") has granted trust to that subkey, which should then be trusted. However the content of the subkey itself (public key and private key) has not changed (otherwise the subkeyid may have changed maybe).

This allows me for instance to have 2 computers:

• on 1 and 2: I have a copy of my GPG key, possibly with different master passwords etc
• on 1, I update a key, for instance I am extending a key or subkey. I then "push" to a key server
• on 2, I refresh from the key server: I can use the key exactly as if I have done the operations on computer 2 as I did on computer 1

This use case works perfectly fine with gpg tools, even if computer 2 has just a subset of the private subkeys.

Also, I do not know if the expiration information is attached to the key or to the certification.

You need to re-import your updated secret key.

This is the part I do not understand. The key structure, certifications etc in Thunderbird are exactly how they should be (I will attach the screenshots):

• if I had to re-import the secrets, then the key handling of Thunderbird is not working as gpg does
• if I were to extend the key expiration date directly in Thunderbird and push to the keyserver, would have it worked? if so, then the behaviour of Thunderbird is not symmetric wrt. key update from keyservers.

Does this make sense?

Comment 6

[raffi.enficiaud]

Attachment: key-trust.png

Comment 7

[raffi.enficiaud]

Attachment: key-certifications.png

Comment 8

[raffi.enficiaud]

Attachment: key-structure.png

Comment 9

[Kai Engert [:KaiE:]]

Did you previously import your secret key into Thunderbird?

Did you use GnuPG to extend the validity of your key?

If the answer is yes to both. then you need to go back to the computer where you used GnuPG to extend the validity, export the secret key to a file, protect it with a password, take that file to the computer that has Thunderbird, go to OpenPGP key manager, use menu file, import secret key from file, and select that file.

Comment 10

[Kai Engert [:KaiE:]]

Nickolay, do you think Thunderbird could automatically update the validty of a secret key, that is stored separately in Thunderbird's keyring for secret keys, by using an downloaded public key that has newer validity information?

If not, I assume the steps from comment 9 are necessary.
But it seems that GnuPG doesn't need those steps, and can update itself completely with a newer public key?

Comment 11

[raffi.enficiaud]

Did you previously import your secret key into Thunderbird?

I stripped out the secrets of all keys/subkeys, except 2 (one signing and one encryption), and then imported that to Thunderbird. The key structure reflects that.

Did you use GnuPG to extend the validity of your key?

Yes

If the answer is yes to both. then you need to go back to the computer where you used GnuPG to extend the validity, export the secret key to a file, protect it with a password, take that file to the computer that has Thunderbird, go to OpenPGP key manager, use menu file, import secret key from file, and select that file.

I understand what you said in your first comment and the previous one, and I know the steps, but this is where I do not understand why it should be the case. See my Comment 5: as far as I understand the subkey has not changed, a new certificate has been added extending the validity of the key. The validity of the subkey is governed by the certificate, not the key itself.

Comment 12

[Kai Engert [:KaiE:]]

When we import a public key, it's stored in TB's keyring for public keys.

When we import a secret key, it's stored in TB's keyring for secret keys.

When we want to sign, we're using the key from the keyring for secret keys.

If the key in the keyring for secret keys hasn't been updated, it still contains the old validity, and our OpenPGP backend (RNP) will refuse to use that expired key.

Comment 13

[Kai Engert [:KaiE:]]

I wonder if the following would work:
For each secret key that Thunderbird manages, take the correpsonding public key. Strip that public key from all third party signatures. Then import that into the secret keyring.
Repeat whenever a new public key is imported.

This isn't currently implemented.
When I worked on the original design for TB's OpenPGP key storage, I thought it's a good idea to keep the keyrings separate.

Comment 14

[raffi.enficiaud]

When we import a public key, it's stored in TB's keyring for public keys.

When we import a secret key, it's stored in TB's keyring for secret keys.

Having a public and a secret store is I believe fine, although IMO this is an overkill: private keys are already protected with a passphrase and can be rekeyed by TB on import (so that their passphrase is derived from the master password for instance).
Using 2 different stores means that they need to be in sync because both store should have the same public information. While importing a private key, IMO we should be storing its public part in the public store. The same happens for refresh: the refresh needs to impact the public information on both stores, so that the public part is be the same on both stores.

Storing just a public part into another store, stripping parts of keys, etc is making the risk of leaking info: this is where I believe that it is a better design to have a unique store and rely on GPG mechanisms to handle the secrets in a secure way.

When we want to sign, we're using the key from the keyring for secret keys.

That key is attached a certificate that is public. Even if currently you store an expiration date inside the private store, the expiration (and certificate) is public information. Same goes for revocation.
Either the public part of the key is refreshed or, if your implementation permits it, the private store retrieves information from the public store for eg. fetching certificates and checking the validity of the key (in that case, we care only about properly refreshing the public store).

For each secret key that Thunderbird manages, take the correpsonding public key. Strip that public key from all third party signatures. Then import that into the secret keyring.

The stripping part is, I believe, not necessary: you will remove public information, and may risk to mistakenly remove relevant information from the key. When the user refreshes the keys, TB can for instance check if the keys being refreshed exists on the private store as well, and update the store.

When I worked on the original design for TB's OpenPGP key storage, I thought it's a good idea to keep the keyrings separate.

As I said, I don't think using two stores is adding much, but I also believe refreshing the two stores is something that can be done (although there might be some weird edge cases: what happens if you start TB without entering the master password and you refresh, what is shown to the user in that case, etc).