Ольга Полянская - Инфраструктуры открытых ключей

Если все списки САС проанализированы, а переменная состояния маски причины не показывает, что все причины аннулирования проверены, то переменная состояния статуса сертификата принимает значение "не определен". Большинство приложений будет реагировать на этот статус так же, как и на статус "аннулирован", остальные приложения уведомят пользователя о неопределенном статусе сертификата. После этого проверка сертификата на предмет аннулирования завершается, и выводится значение переменной состояния статуса сертификата.

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

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

Несмотря на сложность построения и валидации пути сертификации , эти операции являются жизненно важными для PKI. Приложения не должны использовать сертификаты или содержащиеся в них открытые ключи без предварительного построения и валидации пути сертификации .

Любой тип архитектуры PKI имеет свои слабые и сильные стороны. Не существует архитектуры, совершенной для всех сред. Выбор оптимальной архитектуры осуществляется с учетом специфики деятельности, потребностей и возможностей организации [70].

Одиночный УЦ- простое и рациональное решение для небольшого однородного сообщества. Когда сообщество может договориться с одиночным УЦ о выпуске всех своих сертификатов, исчезают проблемы, связанные с построением и валидацией пути сертификации . Компрометация одиночного УЦ, безусловно, является катастрофой и делает недействительными все выпущенные им сертификаты. В результате сообщество полностью теряет доступ к сервисам безопасности. С другой стороны, такое сплоченное сообщество способно эффективно распространить уведомление о компрометации и быстро восстановить PKI.

Иерархическая PKI- это оптимальное решение для организации со строгой иерархической структурой. Иерархическая PKI соответствует структуре организации, поэтому центр определяется естественным образом. Построение и валидация пути сертификации - просты. Однако могут возникнуть трудности при наложении этой структуры на совокупность независимых удостоверяющих центров. Создание иерархической PKI лучше начинать с организации головного УЦ. Подчиненные удостоверяющие центры могут быть объединены в иерархию уже при развертывании, немедленно, без сложных проблем перехода. Компрометация головного УЦ выводит из строя всю инфраструктуру, но восстановить работу PKI после компрометации любого другого УЦ достаточно просто. Правильно выбранные политика, регламент функционирования и средства физической защиты УЦ могут сделать его компрометацию маловероятной.

Сетевая PKI- это, скорее, вынужденное, нежели оптимальное решение для тех организаций, которые не имеют четкой иерархической структуры. В таких организациях проще развернуть сетевую PKI, поскольку взаимодействующие стороны предпочитают устанавливать равноправные, а не подчиненные отношения доверия. Проблемы подчиненности могут вызывать разногласия и должны всесторонне обсуждаться, как это происходит при развертывании иерархической инфраструктуры. Если удостоверяющие центры были основаны несколькими подразделениями организации ранее, то наиболее простым решением будет сетевая PKI. Кроме того, сетевая PKI - лучший вариант, если организация нуждается в инфраструктуре, способной легко преодолевать последствия компрометации любого УЦ. Компрометация одного УЦ будет катастрофой только для его пользователей, но серьезно не отразится на транзакциях между пользователями других удостоверяющих центров сетевой PKI. Главные недостатки сетевой архитектуры PKI - сложность построения и валидации пути сертификации .

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

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

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

Подробно рассматриваются механизмы распространения сертификатов и списков САС, обсуждается организация репозитория, дается характеристика каталога X.500, описывается упрощенный протокол доступа к каталогу LDAP, сопоставляются разные варианты развертывания репозитория, дается представление о способах распространения PKI-информации при помощи электронной почты, сетевых протоколов и системы доменных имен.