1640511 - Optionally support hkp keyservers that return a single result (such as keys.mailvelope.com)

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[Kai Engert [:KaiE:]]

I learned that keys.mailvelope.com is a verifying keyserver.

It seems like we could add it to our default list of keyservers?

Comment 1

[Patrick Brunschwig]

Be careful, it's a different implementation with a different REST API than keys.openpgp.org.

You'll have to use the HKPS protocol to access it, or implement their own REST API.

Comment 2

[Patrick Brunschwig]

Apart from this, you can safely add it, but I would not make it the default. The server is written in node.js, and we don't expect that it can handle a huge load :-)

Comment 3

[Kai Engert [:KaiE:]]

Thanks Patrick for the explanations. Let's be careful then. Sounds like we shouldn't add it to the default search when the user attempts to discover a key. We'll have to figure out how to allow optional searching, which would greatly reduce the load we might cause on that server.

Comment 4

[f.fainelli]

Can we consider letting users configure their own keyserver, even a non verifying one? There are lots of corporations that deploy their own key server using Symantec's Encryption Verified Directory. Being able to automatically fetch keys from such key servers would be a huge time saver.

Comment 5

[Kai Engert [:KaiE:]]

(In reply to f.fainelli from comment #4)

Can we consider letting users configure their own keyserver, even a non verifying one? There are lots of corporations that deploy their own key server using Symantec's Encryption Verified Directory. Being able to automatically fetch keys from such key servers would be a huge time saver.

Non-verifying keyservers might return more than one result for a queried email address. It's difficult for the user to decide which one to import. And currently no UI has been implemented in Thunderbird to offer such a selection.

Comment 6

[Kai Engert [:KaiE:]]

I wonder if we sould allow the hkp protocol for downloading, but only if the lookup by email address returns exactly one match.

Comment 7

[Kai Engert [:KaiE:]]

Attachment: hkp-single.patch

This is a quick experiment to search a hkp server. This patch applies on top of the comm-esr102 branch.
In order to use it, change the (unofficial) preference temp.openpgp.keyserver to:
hkp://keys.mailvelope.com

(Currently only a single key server is searched.)

Comment 8

[Kai Engert [:KaiE:]]

Attachment: Bug 1640511 - Support hkp keyservers that return a single result. Define an official keyserver pref. r=PatrickBrunschwig

Comment 9

[Kai Engert [:KaiE:]]

Attachment: Bug 1640511 - Cleanup: remove obsolete keyserver code. r=PatrickBrunschwig

Depends on D163135

Comment 10

[Kai Engert [:KaiE:]]

I cleaned up the patch, and changed it to be on top of comm-central.

I've renamed the old temporary pref to a new official pref name.

The pref now supports multiple keyservers. Both hkp and vks are supported. If keyservers of other types are in the list, they are ignored.

If more than one keyserver is given, they will be searched in the given order. Searching will stop as soon as a keyserver returned a key.

When querying hkp, and more than one result is returned, the results from that keyserver are ignored (treated as "nothing found").
This allows the use of keyservers which offer the hkp protocol for downloading, and which enforce a single key per email address.
(If a non-enforcing key also has just one key for an email address, we'll accept that result, too.)

Comment 11

[Kai Engert [:KaiE:]]

In the patch I've also added the keyservers keys.mailvelope.com and keyserver.ubuntu.com as secondary keyservers.
I think it would be useful to test with this setting.
The amount of users on TB daily and beta builds isn't that big.
If that turns out to be a problem for anyone, we can change that back later on.

Comment 12

[Kai Engert [:KaiE:]]

On second thought, I don't want to have lookups for k.u.c by default on daily/beta builds.

I think it's confusing that we lookup keys, but then ignore results if there are multiple.
If anyone really wants to have k.u.c as an additional place for downloading, they can add it on their own to the pref.

Comment 13

[Kai Engert [:KaiE:]]

Attachment: Experimental backport to esr102 (does NOT change the pref)

Comment 14

[Kai Engert [:KaiE:]]

https://hg.mozilla.org/comm-central/rev/649b1635ff6d49b37a6669f2412bf0f07ef1be84
https://hg.mozilla.org/comm-central/rev/dbb3e5f18f40d828f5d7b5e4fca62164f3af3587

Comment 15

[Kai Engert [:KaiE:]]

(In reply to f.fainelli from comment #4)

Can we consider letting users configure their own keyserver, even a non verifying one? There are lots of corporations that deploy their own key server using Symantec's Encryption Verified Directory. Being able to automatically fetch keys from such key servers would be a huge time saver.

Can you please test and confirm the new functionality resolves your request?
See also:
https://thunderbird.topicbox.com/groups/e2ee/T801ebc471b308144/improved-keyserver-support

Comment 16

[Magnus Melin [:mkmelin]]

Does the single-key restriction consider revoked keys? Or is that not relevant here? I mean the case where you'd find one revokted and one new key.

Comment 17

[Kai Engert [:KaiE:]]

Not yet, good point. Ideally we'd import all revoked keys. I realize that we should probably also implement another change: For keys downloaded from a HKP server, we might want to strip all third party signatures, prior to importing, such servers might not have a protection against signature spam.

Comment 18

[Kai Engert [:KaiE:]]

Actually, it should work differently. Revocations should be obtained by lookup to known key IDs/fingerprints. Ideally, when searching for a new key by email address, a smart keyserver should provide a non-revoked non-expired public key, only.
We still need to implement "automatic revocation checking from keyservers" (refreshing keys). Currently, this happens only when the user asks to discover keys online.