Во-первых, обратите внимание, что вы можете полностью пропустить весь процесс, поскольку сертификат CA пула SKS связан с последними дистрибутивами GnuPG, обычно расположенными по адресу /usr/share/gnupg/sks-keyservers.netCA.pem,
Во-вторых, обратите внимание, что использование HKPS не аутентифицирует данные Ручной у бассейна. это только мера конфиденциальности (чтобы предотвратить раскрытие всей вашей цепочки ключей с помощью --refresh-keys). Но фактические блоки ключей PGP, полученные с серверов ключей, все еще должны проверяться так же, как вы всегда это делали. Это ты все еще должен проверьте отпечаток каждого импортированного ключа или воспользуйтесь Web-of-Trust или Gofu.db от GnuPG.
Так что когда дело доходит до:
Как мне выяснить, чей открытый ключ я должен загрузить с сервера ключей отдельно (чтобы я не доверял их веб-сайту в одиночку)?
Если бы кто-то мог скомпрометировать сайт, чтобы загрузить поддельный CA.pem, он мог бы также загрузить поддельную подпись CA.pem.asc вместе с ним. И если бы кто-то мог вставить поддельный открытый ключ на веб-сайт, он мог бы загрузить этот же ключ на сервер ключей.
Другими словами, загрузка чьего-либо ключа отдельно от сервера ключей не обеспечивает никакой дополнительной безопасности. Сервер ключей никому не мешает загружать поддельные ключи под тем же именем & amp; Эл. адрес. Все по-прежнему сводится к проверке отпечатка пальца ключа или веб-доверия. Если у вас нет отпечатка пальца для проверки, вы можете получить его, обратившись к владельцу.
(Знать что человек управляет пулом SKS, я бы сказал, технических средств недостаточно. Мой подход заключается в сборе информации из разных источников, таких как опрос других людей или проверка web.archive.org или запрос на канале IRC GnuPG (если вы доверяете случайным пользователям IRC). Если вы продолжаете видеть одного и того же человека "Кристиан Фискерстранд" повсюду, это, вероятно, правильный вариант.)
Если у вас нет любой форма существующего контакта с владельцем веб-сайта, ваш единственный вариант заключается в доверии, что веб-сайт предоставляет вам достоверную информацию. (К счастью, ваше подключение к нему проходит проверку подлинности по протоколам HTTPS и WebPKI, поэтому вы можете исключить большинство атак MITM, оставляя только серверный компромисс.)
Возможно, вы можете проверить различные моментальные снимки веб-сайта по адресу web.archive.org (чтобы увидеть, был ли тот же ключ на месте в течение последних нескольких месяцев или лет).
Как предполагается использовать каждый фрагмент информации?
Отпечаток сертификата и / или хэш SPKI служат практически для тех же целей, что и веб-сайты, которые предлагают простые хеш-коды SHA1 наряду с загрузками. (Действительно, отпечаток пальца - это просто хэш сертификата SHA1 без его кодировки Base64.) Вы можете использовать их если Вы доверяете веб-сайту ... но тогда он в основном избыточен, потому что вы получили сертификат CA с того же веб-сайта. Это может предотвратить некоторые случайные ошибки, хотя.
Чтобы просмотреть отпечаток сертификата (SHA1):
openssl x509 -in $file -noout -fingerprint -sha1
certtool --fingerprint < $file
cat $file | sed "/^-/d" | base64 -d | sha1sum
Просмотр идентификатора ключа субъекта X.509v3 требует внимания к разнице между расчета SPKI хэширует сам себя (как показано в разделе «Другая информация»), а не просто смотрит на тот, который встроен в расширения X.509 (как видно в разделе «Расширения»):
certtool -i < $file | grep -C3 "Public Key ID"
CRL (список отзыва сертификатов) используется Dirmngr GnuPG, чтобы гарантировать, что скомпрометированные сертификаты сервера ключей не могут быть повторно использованы до истечения срока их действия. CRL подписан CA, и я думаю, что dirmngr автоматически загружает и обновляет его, так что вам не нужно это делать.
Подпись сделана владельцем веб-сайта и может быть использована для проверки файла CA.pem, если у вас уже есть другие средства проверки для ключа PGP владельца. Просто загрузка его с того же сайта не добавляет много.
Чтобы проверить подпись:
gpg --verify sks-keyservers.netCA.pem.asc