обмен ключами в организации

А большая организация? Если дюжина-другая человек, можно и ручками. Создайте себе корневой ключ подписания, разделите и заверяйте им все остальные. Подробнее — здесь.

встает вопрос: использовать для обмена ключами сервер ключей или пользоваться публичными? Какие риски при этом?

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

В общем, Вы не привели никаких подробностей ни об организации, ни о предполагаемой ключевой инфраструктуре. Так что и ответить точнее не могу.

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

Если сервер не поддерживает защищённые протоколы передачи данных (SSL, как в случае https://keyserver.pgp.com), а это подавляющее большинство общественных серверов, то противник, способный на активную атаку на канале связи, может любым образом модифицировать пакет передаваемого ключа.

Допустим, Вы, узнав о компрометации своего ключа, аннулировали его и отправляете на общественный сервер, дабы Ваши корреспонденты могли получить эту обновлённую копию и больше этот ключ не использовали. Поскольку оппонент имеет доступ к каналу связи (а канал открыт), он удаляет из пакета Вашего ключа субпакет KRC (сертификат аннулирования). Такое возможно, поскольку ключи OpenPGP имеют модульную структуру. В итоге депозитарий получает Ваш ключ так, как будто он не аннулирован; соответственно, таким его получат и Ваши корреспонденты и продолжат использовать скомпрометированный ключ.

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

дабы Ваши корреспонденты могли получить эту обновлённую копию и больше этот ключ не использовали. Поскольку оппонент имеет доступ к каналу связи (а канал открыт), он удаляет из пакета Вашего ключа субпакет KRC (сертификат аннулирования).

А разве ключ не подписывает контрольную сумму всех включённых в него владельцем полей? Разве при правильной реализации попытка удалить поля или изменить поля, которые имеет право менять только владелец не приведёт к тому, что ключ будет битым? По идее должно быть можно только не пускать новый ключ на сервер.

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

С позитивной стороны, это позволяет множеству копий ключа разной актуальности храниться в различных источниках: на серверах ключей, веб-сайтах, страницах книг. При этом все эти копии будут действительны (покуда не повреждена их криптографическая целостность). А в GnuPG вообще есть параметр --export-options export-minimal, позволяющий экспортировать наиболее компактный материал сертификата (только ID и одна автоподпись под каждым идентификатором).

Я имел ввиду

поля, которые имеет право менять только владелец

... к которым явно должно относиться и поле отзыва. А вот поля подписей должны идти отдельно, вне подписи владельца ключа, это уже они подписывают ключ, естественно подписывать должны все желающие. Хотя и эту возможность желательно бы иногда ограничить: например дать право подписи только по предварительному запросу, кто не получил некоторое секретное значение от автора, не может поставить подпись, пусть тем самым и заблокировав возможность создания сети доверия. А то это доверие получается чрезмерным. Например можно взять ключ известной личности, подписать его ключём, содержащим всякие приколы, неприличности, гадости, спам, превратить ключ в сборник анекдотов и выложить на общественный сервер. И этот флуд вообще никто удалить не сможет, поскольку ключ циркулирует в сети обмена между серверами. Также можно раздуть чей то ключ до неимоверных размеров, устроив "отказ в обслуживании".

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

поля, которые имеет право менять только владелец ... к которым явно должно относиться и поле отзыва. А вот поля подписей должны идти отдельно, вне подписи владельца ключа, ...

Предложение для формата v5? Учитывая, что RFC2440bis наконец официально принят, самое время начать обсуждать его недостатки. :-)

Да, сейчас раскритикуем в пух и прах, пусть обратно отзывают или срочно придумывают RFC9760 :-)

Скорее, начнём двигаться к новому формату ключей и стандарту.

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

С этим целиком согласен.