Preferred keyservers can be used in data signatures and user id signatures, and allow the signer to provide one (or more) URIs that supposedly can be used to lookup or refresh the public key of the signer (refreshing is important to check for revocations).
This is a severe misfeature, and NeoPG removes support for it, because of the following reasons:
Automatic use of the field can violate the privacy of the recipient.
It is disabled by default in GnuPG for this reason.
The preferred keyserver subpacket has not been widely adopted. Of 855 Debian maintainer keys, only 16 (1.9%) have such subpackets. I don't have any data on their use in signatures, but for GnuPG to retrieve the key automatically based on these subpackets, both auto-key-locate and honor-keyserver-url must be true.
The standard is unclear on the interpretation and semantic of this field. Of the 18 URIs among the Debian keys, one points to https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556, which is not a keyserver, but a lookup URL for this particular key on that keyserver. Another uses the URI scheme x-hkp, while the others use hkp, hkps or http. Those indicating http do not have the correct port (11371) for hkp access. And only 2 indicate secure access via TLS with hkps or https, while the others indicate unprotected access via hkp or http, irregardless of the current status of https/hkps support on the server.
Because these subpackets are attached to user id signatures, there can be several different on them, further complicating interpretation. In fact, of the 16 Debian keys two keys have signatures with two different keyserver urls:
Giovanni Mascellani:
spk:24:1:25:hkp%3A//keyserver.uz.sns.it (part of the SKS pool)
(6 times)
spk:24:1:24:hkp%3A//keyserver.linux.it (no DNS entry)
(4 times)
Raphaël Hertzog <raphael@ouaza.com>
spk:24:1:20:hkp%3A//keys.gnupg.net (alias for SKS pool)
(2 times)
spk:24:1:24:hkp%3A//keyring.debian.org
(1 time)
I have not checked the expiration and revocation status to see if those would help in this particular case. In general, it can be arbitrary complicated.
Of the 18 URIs among the Debian keys, we find (ignoring differences in scheme and so on) 11 different hostnames. Of these, 3 are not reachable at this time, 7 are reachable with hkp and hkps, and one is only reachable via hkp. All but 2 are part of the SKS pool.
The API of libneopg will provide low-level access to this information, if it exists, which might be sufficient for some users who want to experiment with them. In case it is desirable to do key lookup based on signatures containing keyserver information, it would be important to involve the user anyway, and not do it automatically behind the scenes.
Preferred keyservers can be used in data signatures and user id signatures, and allow the signer to provide one (or more) URIs that supposedly can be used to lookup or refresh the public key of the signer (refreshing is important to check for revocations).
This is a severe misfeature, and NeoPG removes support for it, because of the following reasons:
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556, which is not a keyserver, but a lookup URL for this particular key on that keyserver. Another uses the URI schemex-hkp, while the others usehkp,hkpsorhttp. Those indicatinghttpdo not have the correct port (11371) for hkp access. And only 2 indicate secure access via TLS with hkps or https, while the others indicate unprotected access via hkp or http, irregardless of the current status of https/hkps support on the server.I have not checked the expiration and revocation status to see if those would help in this particular case. In general, it can be arbitrary complicated.
The API of libneopg will provide low-level access to this information, if it exists, which might be sufficient for some users who want to experiment with them. In case it is desirable to do key lookup based on signatures containing keyserver information, it would be important to involve the user anyway, and not do it automatically behind the scenes.