обмен ключами в организации
Добрый день!
Поясните, пожалуйста, ситуацию:
Есть организация. Начальство решило использовать PGP внутри компании для кодирования почты.
встает вопрос: использовать для обмена ключами сервер ключей или пользоваться публичными? Какие риски при этом?
Или же в ручную пересылать ключи друг другу?
комментариев: 11558 документов: 1036 редакций: 4118
Публичные серверы изредка глохнут, может получиться отказ в обслуживании. Если интенсивность контактов с внешними участниками (клиентами, поставщиками) невелика, это не будет серьёзной проблемой. Если же предполагаете шифровать сообщения только внутри организации, то и использовать сервер большой потребности нет — все ключи могут храниться на связке каждого пользователя.
В общем, Вы не привели никаких подробностей ни об организации, ни о предполагаемой ключевой инфраструктуре. Так что и ответить точнее не могу.
по поводу отказа: их несколько и падение одного не смертельно.
комментариев: 11558 документов: 1036 редакций: 4118
Допустим, Вы, узнав о компрометации своего ключа, аннулировали его и отправляете на общественный сервер, дабы Ваши корреспонденты могли получить эту обновлённую копию и больше этот ключ не использовали. Поскольку оппонент имеет доступ к каналу связи (а канал открыт), он удаляет из пакета Вашего ключа субпакет KRC (сертификат аннулирования). Такое возможно, поскольку ключи OpenPGP имеют модульную структуру. В итоге депозитарий получает Ваш ключ так, как будто он не аннулирован; соответственно, таким его получат и Ваши корреспонденты и продолжат использовать скомпрометированный ключ.
Некоторые решения у проблемы есть, но не для всякого случая они подходят.
комментариев: 9796 документов: 488 редакций: 5664
А разве ключ не подписывает контрольную сумму всех включённых в него владельцем полей? Разве при правильной реализации попытка удалить поля или изменить поля, которые имеет право менять только владелец не приведёт к тому, что ключ будет битым? По идее должно быть можно только не пускать новый ключ на сервер.
комментариев: 11558 документов: 1036 редакций: 4118
С позитивной стороны, это позволяет множеству копий ключа разной актуальности храниться в различных источниках: на серверах ключей, веб-сайтах, страницах книг. При этом все эти копии будут действительны (покуда не повреждена их криптографическая целостность). А в GnuPG вообще есть параметр --export-options export-minimal, позволяющий экспортировать наиболее компактный материал сертификата (только ID и одна автоподпись под каждым идентификатором).
комментариев: 9796 документов: 488 редакций: 5664
... к которым явно должно относиться и поле отзыва. А вот поля подписей должны идти отдельно, вне подписи владельца ключа, это уже они подписывают ключ, естественно подписывать должны все желающие. Хотя и эту возможность желательно бы иногда ограничить: например дать право подписи только по предварительному запросу, кто не получил некоторое секретное значение от автора, не может поставить подпись, пусть тем самым и заблокировав возможность создания сети доверия. А то это доверие получается чрезмерным. Например можно взять ключ известной личности, подписать его ключём, содержащим всякие приколы, неприличности, гадости, спам, превратить ключ в сборник анекдотов и выложить на общественный сервер. И этот флуд вообще никто удалить не сможет, поскольку ключ циркулирует в сети обмена между серверами. Также можно раздуть чей то ключ до неимоверных размеров, устроив "отказ в обслуживании".
По моему, как раз для организации может быть имеет смысл содержать именно свой сервер ключей, с ограниченными сетями доверия.
комментариев: 11558 документов: 1036 редакций: 4118
Предложение для формата v5? Учитывая, что RFC2440bis наконец официально принят, самое время начать обсуждать его недостатки. :-)
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
С этим целиком согласен.