Мы знаем email адрес человека и хотим с ним безопасно связаться. Как узнать его
публичный OpenPGP ключ?

Заранее обменяться ключами

   gpg --import MYKEYID.asc

Самый простой, самый надёжный вариант. Но не всегда практичный и удобный, так
как физическая встреча людей далеко не всегда возможна. Узнать или получить можно
не весь ключ (он относительно больших размеров), но хотя бы
отпечаток ключа, чтобы его можно было аутентифицировать, получив из сторонних источников.

Экспорт ключа для записи его на бумагу, флешку, любой носитель:

   gpg --armor --output MYKEYID.asc --export MYKEYID

Получить ключ через один из множества ключевых серверов (keyserver)

   gpg --keyserver KEYSERVER --recv-keys SOME@BODY.COM

Технически, сервер ключей представляет собой что-то вроде публичного
FTP-сервера, который умеет импортировать/обрабатывать OpenPGP записи и
производить по ним поиск, работает по OpenPGP HTTP Keyserver Protocol (HKP)
протоколу. Многие из них синхронизируются между собой автоматически и, загрузив
ключ на один из них, можно ожидать его появление на других серверах, но это
происходит далеко не всегда.

Проблема заключается в том, что никто не обязывает загружать свои ключи на сервера:
многие просто не хотят "светить" своей приватной информацией (email адрес, имя
связанное с ним). Плюс заранее неизвестно, какой ключевой сервер надо использовать.

Ключевые сервера только импортируют информацию, добавляют, но никогда не
удаляют. С одной стороны, это хорошо, с другой, становится невозможно удалить
ключ или часть его информации (UID-ы, подключи).

Поддержка ключевых серверов имеется во множестве OpenPGP клиентов. Отправить
ключ на сервер можно так:

   gpg --keyserver KEYSERVER_URL --send-keys MYKEYID

Получить ключ через DNS-based Authentication of Named Entities (DANE)

   gpg --auto-key-locate dane --locate-key SOME@BODY.COM

В этом варианте OpenPGP ключ полностью размещается внутри одной DNS записи
hash(SOME)._openpgpkey.body.com. Из-за хэширования не утекает настоящее имя "SOME".

DANE требует возможность управления DNS записями и накладывает ограничения на
сервер (TCP и EDNS расширения обязательны почти наверняка). Многие пользователи
приобретают собственные домены, хотя DNS, почтовые и Web-сервера располагаются
у сторонних лиц. Например, можно использовать собственное доменное имя, но
почтовые сервера Google, при этом пользуясь DANE без сторонних ключевых
серверов и потерь приватности.

DANE поддерживается клиентами не так широко, но его записи можно получить
самостоятельно drill/dig запросами и импортировать результат в OpenPGP программу.

Генерирование DANE CERT записи, которую можно вставить в зону DNS, делается просто:

   gpg --export --export-options export-dane MYKEYID

Получить ключ через Web Key Discovery (WKD)

   gpg --auto-key-locate wkd --locate-key SOME@BODY.COM

WKD протокол пока ещё на стадии утверждения и что-то может поменяться, но его
реализация уже имеется в последних версиях GnuPG. Для получения ключа он
использует HTTPS инфраструктуру. В данном примере команда приведёт к простому
скачиванию бинарного (не Base64) ключа https://body.com/.well-known/openpgp/hu/hash(SOME).

WKD использует HTTPS и может быть более удобен для использования и публикации
ключей по сравнению с DNS. В нём нет задержек от кэша DNS, статические файлы
проще обновлять чем DNS записи, особенно если это хочется сделать как-то
автоматизировано на всём домене для множества пользователей. Однако, это ещё
одна инфраструктура (кроме DNS), и обязательно работающая по TLS. Получение TLS
сертификатов может являться проблемой.

WKD поддерживается пока реже, чем DANE, но получить ключ с HTTPS
сервера можно любым HTTP клиентом и сразу же импортировать в OpenPGP программу.

Узнать хэш-часть до доменного имени, под которой необходимо загрузить ключ на
HTTPS сервер, можно так:

   gpg --list-keys --with-wkd-hash MYKEYID

Получить ключ через LDAP

   gpg --auto-key-locate ldap --locate-key SOME@BODY.COM

В этом варианте будет обращение к LDAP серверу ldap://keys.body.com/ и поиск
OpenPGP ключа на нём для заданного пользователя. Скорее всего, это имеет смысл
для корпоративных решений, где LDAP применяется чаще, чем в масштабах Интернета.

Но у нас пока нет доверия к полученным по HKP (ключевой сервер)/DANE/WKD
ключам. Злоумышленник может иметь контроль над ними, может сделать MitM
(дословно, "человек посредине")
атаку. Как проверить целостность и аутентичность полученного ключа?

Сравнить отпечаток с тем, что вы получили напрямую от человека

Разместить отпечаток на визитке -- плёвое дело. Самый надёжный и простой
вариант, но опять же, не всегда возможен физический контакт людей.

Узнать отпечаток импортированного ключа можно так:

   gpg --list-keys --with-fingerprint MYKEYID

Узнать отпечаток у владельца по сторонним каналам связи

Использовать голосовую и/или видео связь, разные средства коммуникации (IRC,
XMPP, PSYC, итд), телефонную связь, обычную почту с принимающей стороной.
Компрометация всего и сразу маловероятна, но часто бывает, что ничего кроме
собственно самой почты вы не знаете и не имеете никакой информации для аутентификации.

Сравнить отпечаток с полученным по PKA

   gpg --auto-key-locate pka --locate-key SOME@BODY.COM

PKA это DNS запись, но в отличиие от DANE, там размещён только отпечаток ключа,
поэтому её можно переслать UDP пакетами, не предъявляя особых требований к DNS серверу.

Генерирование PKA записи, которую можно вставить в зону DNS, делается просто:

   gpg --export --export-options export-pka MYKEYID

Желательно использовать DNSSEC и TLS

Записи DANE и PKA желательно аутентифицировать через DNSSEC. Это не даёт
гарантий, что MitM-атака невозможна, но усложняет её. К примеру, WKD работает
только поверх TLS.

Использовать HKP, PKA, DANE, WKD по разным каналам связи

Используйте разные DNS сервера, разные прокси, разные сети. Компрометация
множества сетей и серверов - более сложная задача для злоумышленника.

Если мы не получали отпечаток ключа, или сам ключ напрямую от его владельца, то
полного доверия к полученному через все эти WKD, DANE и прочих, у
нас нет. Например, ключевой сервер это одна точка отказа. DANE и TLS используют
PKI, который может быть скомпрометирован на государственном уровне.

Для того чтобы иметь хоть какое-то доверие, в OpenPGP используется:

Сеть доверия: Web-of-Trust (WoT)

Пользователи могут подписывать публичные ключи друг друга, тем самым заверяя,
что аутентифицировали ту или иную информацию в ключе (например, видели паспорт
с прописанным в нём именем, смогли отправить/получить электронную почту по
указанным в ключе адресам, итд). WoT представляет собой граф таких связей, основанных на
подписях людей.

В теории, если у вас есть доверенные публичные ключи ваших знакомых, а у
недоверенного ключа есть их подписи, то скорее всего, ему можно доверять в
большей степени.

Чем больше подписей он имеет, тем выше вероятность, что среди них есть подписи
удостоверяемых вами ключей. Для расширения WoT многие часто проводят, так называемые,
Key Signing Party.

Это не даёт полной гарантии доверия: например, у вас есть известный и доверяемый
ключ системного администратора вашей компании, и он захочет устроить MitM атаку
-- если у полученного ранее неизвестного вам ключа будет стоять только его
подпись, то он успешно её проведёт. GnuPG в WoT находит кратчайший путь доверия
-- это даёт потенциально множество точек отказа (MitM). Но в теории, ничто не
мешает аутентифицировать WoT полностью.

Кроме того, через WoT утекает информация о ваших связях, с кем вы так или иначе
контактировали, виделись, вообще имели хоть какое-то дело. Это приватная
информация, но из-за WoT она публично доступна. Ценность подобной
метаинформации может быть огромна.

Модель Trust On First Use (TOFU)

В этой модели все факты успешного использования ключей сохраняются в локальной
базе данных. При первом использовании ключа он просто запоминается. Далее,
каждый факт успешной проверки новой подписи с заданного email адреса
сохраняется в БД. Если для известного email адреса будет замечено использование
другого ключа, то это повод для предупреждения о возможной MitM атаке.

Чем больше будет успехов использования ключа на заданных адресах, тем выше к
нему доверие. Если мы регулярно и долго общаемся с человеком и продолжаем
использовать один и тот же ключ, то выше вероятность доверия к нему.

TOFU предоставляет меньшие гарантий доверия, чем WoT, но его гораздо проще
использовать, он требует меньше действий от пользователя, так как
фактически просто собирает статистику. WoT требует аккуратного управления доверием к
каждому UID-у ключей, созданием подписей и их обменом.

Но TOFU можно использовать и совместно c WoT, как минимум, для обнаружения
неконсистентной связи используемых ключей и соответствующих email адресов.

Включить режим WoT и TOFU можно опцией: trust-model tofu+pgp.

Полностью ручное управление доверием

В этом случае, вы не полагаетесь ни на статистику (TOFU), ни на WoT, и подписи
других людей (их можно вообще вырезать из импортируемых ключей для экономии
места на жёстком диске), а просто самостоятельно в вашей локальной ключнице
проставляете степень доверия UID-ам ключей. Для большей безопасности вы можете
подписывать доверяемые UID-ы чужих ключей, но делая локальную подпись, которая
не попадаёт в экспорт.

Рекомендовать что-то одно конкретное вряд ли можно: везде свои плюсы и минусы,
где-то удобнее одно, где-то другое, в зависимости от потребностей и возможностей.