1778867 - Discovered key cannot be imported due to "corruption or unknown attributes"

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, defect)

Description

[Arvidt]

Attachment: received mailing list mail

Steps to reproduce:

• Receive signed mail that does not contain signers public key (e.g. attachment, autocrypt header). In this case it's a official Debian Announcement mailing list mail.
• Click on the signature icon -> Discover (see screenshot)
• A windows pops up saying "The file contains one public key [...]" (BTW what "file" would that be? confusing)
• Click on Accepted->Import

Actual results:

• Message pops up "Import failed due to corrupt key or attribute problems"
• Click OK to attempt to import the parts of the key that are correct
• Warning pops up "No keys imported"

Expected results:

• Windows pops up saying "Found signers key from Web Key Directory"
• Key should be imported or it should be told exactly what is wrong with the key so the user can inform the sender to fix the key

I guess the signers (and senders) key is discovered via WKD.
One can check WKD with gpg --locate-keys --auto-key-locate clear,nodefault,wkd [e-mail]

Comment 1

[Arvidt]

Attachment: import

Comment 2

[Arvidt]

Attachment: problems with key

In the Linux console I can import the key with gpg 2.2.27 just fine:

$ gpg --locate-keys --auto-key-locate clear,nodefault,wkd [e-mail]
gpg: Oops: keyid_from_fingerprint: no pubkey
gpg: key 0xE5EC4AC9BD627B05: public key "Donald Norwood <[e-mail]>" imported
gpg: Total number processed: 1
gpg: imported: 1
gpg: public key of ultimately trusted key 0x0000000000000000 not found
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 17 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 17u
gpg: depth: 1 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 1f, 0u
gpg: next trustdb check due at 2023-03-30
pub rsa4096/0xE5EC4AC9BD627B05 2014-11-12 [SC] [expires: 2024-04-19]
B7A15F455B287F384174D5E9E5EC4AC9BD627B05
uid [ unknown] Donald Norwood <[e-mail]>
sub rsa4096/0x26D3DD16681E7552 2014-11-12 [E] [expires: 2024-04-24]

Comment 3

[Arvidt]

I exported the key that I imported with gpg (see comment 2) with gpa (GNU Privacy Assistant) from the gpg keyring to a file and that file (the key) could be imported successfully with the TB key manager then.
So if that works, TB should also be able to import the key itself right away.

Comment 4

[Arvidt]

After having imported the key via gpg to TB, the mail's signature is shown as valid in TB.

Comment 5

[Magnus Melin [:mkmelin]]

Please attach the list email to this bug as .eml

Comment 6

[Arvidt]

Attachment: list email

Comment 7

[Thomas D. (:thomas8)]

2022-07-11_1317_mass-mark-TB102found

Comment 8

[Kai Engert (:KaiE:)]

TB searches on the keyserver first. It find a key - but that key is incomplete, it doesn't have a user ID (as can be seen in the screenshot).

Thunderbird will not import new keys without a user ID - BTW that matches gnupg behavior.
(Such incomplete keys will be imported for KNOWN keys without asking for confirmation, to learn about new expiration or revocation.)

The bug is that we offer this key to the user for importing. If we cannot import it, we must not offer it.

With the key from the keyserver not working, we should then fall back to WKD. (We currently don't fall back to WKD because of this bug, because TB falsely assumes it found something useful already.)

Comment 9

[Kai Engert (:KaiE:)]

Actually, we currently don't attempt to use WKD in this scenario at all.

The signature contains a key ID. We can query a keyserver for a key by key ID.

We cannot query WKD by key ID, we can query WKD only using an email address.

We could be optimistic and attempt to search WKD using the email address that is seen in the email header. But that might not succeed. The data on WKD could refer to a new key, while the signature was created using an older (or simply different) key.

So with today's TB implementation, the minimal bugfix would be to say "we couldn't find a usable key", because the keyserver doesn't have it (lacking user ID).

The idea to try to lookup by WKD anyway would be an enhancement.

Comment 10

[Arvidt]

Would not it make sense to first query WKD, since that is authoritative from the domain owner?
And if the WKD key (from the sender's mail address from the mail's header) matches the signer key, all would be fine, no need to query any keyserver.
Only if there is no WKD answer or mismatch, keyserver could additionally be queried and if that key has no mail address user id, there would be message "No key found"?

Comment 11

[Kai Engert (:KaiE:)]

Attachment: Bug 1778867 - Don't offer importing a new key that lacks user ID. r=mkmelin

Comment 12

[Kai Engert (:KaiE:)]

As a first step, I've attached the minimal correctness fix, that avoids offering an incomplete key (no user id).

Comment 13

[Kai Engert (:KaiE:)]

(In reply to Arvidt from comment #10)

Would not it make sense to first query WKD, since that is authoritative from the domain owner?
And if the WKD key (from the sender's mail address from the mail's header) matches the signer key, all would be fine, no need to query any keyserver.
Only if there is no WKD answer or mismatch, keyserver could additionally be queried and if that key has no mail address user id, there would be message "No key found"?

Yes, agreed, that would be a useful enhancement.

Comment 14

[Kai Engert (:KaiE:)]

Attachment: 1778867-esr102.patch

Comment 15

[Kai Engert (:KaiE:)]

Comment on attachment 9285454 [details]
Bug 1778867 - Don't offer importing a new key that lacks user ID. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): -
User impact if declined: misleading interaction with the user
Testing completed (on c-c, etc.): manually
Risk to taking this patch (and alternatives if risky): low

Comment 16

[Kai Engert (:KaiE:)]

I've filed bug 1779836 to track the suggestion from comment 10.

Comment 17

[Kai Engert (:KaiE:)]

It isn't a perfect solution (and implementing but 1779836 would be useful), but as a workaround, when reading the email, you can already use mouse right click on the sender's email address, and click "discover openpgp key".

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/1aa03693518b
Don't offer importing a new key that lacks user ID. r=mkmelin

Comment 19

[Wayne Mery (:wsmwk)]

Comment on attachment 9285454 [details]
Bug 1778867 - Don't offer importing a new key that lacks user ID. r=mkmelin

[Triage Comment]
Approved for beta

Comment 20

[Rob Lemley [:rjl]]

Thunderbird 103.0b6:
https://hg.mozilla.org/releases/comm-beta/rev/d062885541d8

Comment 21

[Magnus Melin [:mkmelin]]

Uplift to 102?

Comment 22

[Kai Engert (:KaiE:)]

Comment on attachment 9285695 [details] [diff] [review]
1778867-esr102.patch

[Approval Request Comment]
see comment 15

Comment 23

[Wayne Mery (:wsmwk)]

Comment on attachment 9285695 [details] [diff] [review]
1778867-esr102.patch

[Triage Comment]
Approved for esr102

Comment 24

[Rob Lemley [:rjl]]

Thunderbird 102.2.0:
https://hg.mozilla.org/releases/comm-esr102/rev/78ae1713ad85

Comment 25

[Steven Michaud [:smichaud] (Retired)]

At bug 1786916 I've found a pretty clear-cut case of failing to import a PGP public key that does have a user id, triggered by this bug's patch.

Comment 26

[Steven Michaud [:smichaud] (Retired)]

From https://keys.openpgp.org/about/usage#gnupg-troubleshooting:

     While refreshing keys, you may see errors like the following:

        gpg: key A2604867523C7ED8: no user ID

    This is a known problem in GnuPG. We are working with the GnuPG team to resolve this issue.

Edit: Contrary to appearances, this may actually indicate a problem with the https://keys.openpgp.org site.