Инфраструктуры открытых ключей

В сетевой архитектуре сертификаты конечных субъектов выпускаются непосредственно их пунктами доверия. Субъект, строящий путь, доверяет своему УЦ, который может не совпадать с пунктом доверия того конечного субъекта, к которому строится путь. Более того, для этого УЦ могут быть выпущены сертификаты другими удостоверяющими центрами из разных сегментов сети. По этой причине построение пути начинается в пункте доверия и продолжается в направлении издателя сертификата конечного субъекта. Идентификатор ключа УЦ в сертификате сравнивается с идентификатором ключа субъекта сертификатов удостоверяющих центров, включая сертификат искомого УЦ. Так как дополнения Authority Key Identifier (идентификатор ключа УЦ) недостаточно для построения пути, следует использовать другие атрибуты как эвристические. Это могут быть имена или любые другие атрибуты, помогающие выбрать, с какого из возможных сертификатов начинать построение пути. Если выбранный сертификат не ведет к завершенному пути сертификации, то просто пробуют следующий за ним сертификат и т.д. [84].

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

На рис.10.6 показаны пути сертификации, которые можно построить от пользователя А к пользователям B, C и D. Для пользователей C и D показан не один путь. Каждый путь является валидным, но некоторые пути длиннее других. Нахождение наиболее короткого пути не требуется, решение этой задачи значительно усложняет процесс. Обычно используется первый найденный валидный путь. С иллюстративной целью третий путь сертификации для пользователя D имеет петлю.

Гибридная архитектура PKI

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

Пример 10.4. Рассмотрим сценарий, проиллюстрированный рис. 10.7 [70]. Три компании сотрудничают друг с другом, но используют корпоративные PKI разных типов. Пользователи А и В получили свои сертификаты от головного УЦ компании "Альфа". Пользователь С получил свой сертификат от УЦ подразделения 1 в иерархической PKI компании "Бета". Пользователь D получил сертификат от УЦ подразделения 3 в сетевой PKI компании "Гамма". Пользователь А может использовать один из трех вариантов гибридной архитектуры PKI для установления защищенных коммуникаций с пользователями C и D.

Рис. 10.7.  Три корпоративные PKI

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

Архитектура расширенного списка доверия

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