1735033 - Key Discovery via button in Message Security window does not use WKD

Status: NEW

(MailNews Core :: Security: OpenPGP, enhancement, P2)

Description

[u617804]

Attachment: Import success when discovering via other than Message Security window

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

Steps to reproduce:

TB 91.2.0 (64-bit)

• Receive a signed email from a domain that supports WKD (in my case the sender is [e-mail]), but you do not have the signer's public key.
• In the email's Message Security window (see screenshot attachment 9245109 [details]) click on the "Discover" button

Actual results:

The signer's public cannot be imported (for details/screenshots see bug 1734994).

Expected results:

The signer's public should be imported via WKD, as it is the case when you right-click the email sender ([e-mail]) and select "Discover OpenPGP key" or go to Tools -> OpenPGP Manager -> Keyserver -> Discover Keys Online and enter the sender's email address (see attached screenshot of import success).

It looks like the Discovery functionality via the "Discover" button in the email's Message Security window only searches for the key ID on the keyserver.

I guess WKD is more trustworthy than any third party keyserver, so I would suggest:

• always try to fetch sender's key via WKD in the first place
• If key(s) could be fetched via WKD and (one of) the imported key ID matches the signer's key ID, all fine
• If key(s) could be fetched via WKD and no imported key ID matches the signer's key ID: Warning, security issue.
• Only if sender does not support WKD, try other possibilities like third party keyserver

Comment 1

[u617804]

I think my suggested last two points may not be correct, as you could have an old email for which a still valid key is present on a keyserver, but that key is not published via WKD (anymore).

So I guess my suggestion to fix this bug boils down to

• Always try to fetch sender's key via WKD in the first place

Comment 2

[Kai Engert [:KaiE:]]

IIUC you have a signed email, which doesn't include the public key, and you don't have the public key yet.

We are certain what the key ID of the signature key is, because it is contained in the signature. Searching on the keyserver by key ID will give us exactly one result, or not (if not found).

If all you have is a key ID, you cannot query WKD.

However, you are correct that we could still try to be smart and try to use WKD.

We would have to use the email address of the email sender to attempt to find the key.

If the key returned by WKD doesn't have the expected key ID, we could ignore that key. If the key ID matches, we can use it.

Comment 3

[u617804]

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

IIUC you have a signed email, which doesn't include the public key, and you don't have the public key yet.

Correct

Searching on the keyserver by key ID will give us exactly one result, or not (if not found).

It can give you exactly one result, which won't be imported if a) there is no User ID b) the User ID is not the sender's email address (not sure if b) really blocks the import currently)

If all you have is a key ID

As I understand the sender's email address is always evaluated on import (see b) above), no? If a key would be imported which User ID does not match the sender's email address, that key would lead to an invalid signature afterwards, as I understand, so that would not be helpful.

We would have to use the email address of the email sender to attempt to find the key.

Due to the cases mentioned above, I would suggest to try WKD at the first place, since I guess it is always more trustworthy than any third party keyserver. I guess it is also ok regarding privacy to query the sender's domain web server, since the email originates from that infrastructure anyway?

If the key returned by WKD doesn't have the expected key ID, we could ignore that key.
Not sure about this. Isn't WKD authoritative and the key should be imported in any case, because it definitely belongs to the email sender, and invalidating the signature from the other key would be correct then?