Security of verifying gpg keys from internet key servers

[Ben McGinnes]

On Mon, Aug 13, 2018 at 09:54:54PM +0100, David Woodfall wrote:
> On Monday 13 August 2018 20:22,
> Matthias Apitz <guru at unixarea.de> put forth the proposition:
>> On Monday, 13 August 2018 18:59:38 CEST, David Woodfall <dave at dawoodfall.net
>>>>
>>>> Dave, do you verify gnuPG keys/signs on the fly? Is this secure?
>>>> Thx
>>>
>>> Mutt does it automatically. I don't know why it wouldn't be secure.
>>>
>>
>> Well, verifying the identity of an unknown person with some server
>> over the Inrernet is not very reliable, isn't it?
> 
> In what way? I think gnupg.net is a pretty secure source to look up
> keys. There's no other way unless someone attaches/sends you there
> key to import that I know about.

It shouldn't matter which server an OpenPGP key was obtained from, the
security and/or validity of the key is maintained by the protocol's
implementation.  Verifying that a key belongs to a particular person
always requires some form of out-of-band checking; hence in person
meetups to do so.

The entire web of trust concept was developed specifically to federate
trust; that is, to move the control of trust from any server to each
user.  While the cryptographic strength of the protocol and any
implementation of it, ensures that each user's control of their key is
absolute (with the usual caveats regarding five dollar wrenches and/or
an abundance of rubber hoses).

Anyway, keys.gnupg.net is sychronised with the SKS keyserver pool,
though it also has some extra features, including the new Web Key
Directory service.  WKD support can be compiled in with current
versions of GPG using the "--enable-wks-tools" flag with configure
step.  Then gpg will be able to use the "--locate-keys" flag in place
of the "--search-keys" flag; then it will check the local key store,
follwed by the WKD protocol, followed by the SKS keyservers.

WKD is still considered a little experimental, but it's ultimately
intended to help move key distribution back out to domains without
requiring running a full keyserver in the process.  It's also intended
to provide more tuned control over user data stored on keys and what
people can search for (e.g. serving different user IDs from different
domains, yet still maintaining the one key).


Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-users/attachments/20181028/0f7fdddd/attachment.asc>