Построение пути в сетевой PKI
В сетевой архитектуре разные пользователи строят разные пути сертификации. Повторимся, что пользователи обычно считают пунктом доверия тот УЦ, который выпустил их сертификаты. Следовательно, когда пользователь А строит путь сертификации до пользователя В, то путь начинается в УЦ, который выпустил сертификат для А, и заканчивается сертификатом пользователя В. Соответственно, когда пользователь С строит путь сертификации до пользователя В, то путь начинается в УЦ, который выпустил сертификат для С, и заканчивается сертификатом пользователя В. Эти пути сертификации различны, несмотря на то, что пользователи А и С получили свои сертификаты от одного и того же УЦ.
В сетевой архитектуре сертификаты конечных субъектов выпускаются непосредственно их пунктами доверия. Субъект, строящий путь, доверяет своему УЦ, который может не совпадать с пунктом доверия того конечного субъекта, к которому строится путь. Более того, для этого УЦ могут быть выпущены сертификаты другими удостоверяющими центрами из разных сегментов сети. По этой причине построение пути начинается в пункте доверия и продолжается в направлении издателя сертификата конечного субъекта. Идентификатор ключа УЦ в сертификате сравнивается с идентификатором ключа субъекта сертификатов удостоверяющих центров, включая сертификат искомого УЦ. Так как дополнения 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, которой доверяет данный пользователь. Эта инфраструктура может быть одиночным УЦ, иерархией или сетью. Пользователь доверяет путям сертификации, которые начинаются с сертификата, выданного любым УЦ из списка доверия.
Пример 10.5. Чтобы защищенно связываться с пользователями B, C и D, пользователь А должен включить в свой расширенный список доверия три удостоверяющих центра: по одному УЦ от каждой доверенной PKI (см. рис. 10.7). Пользователь А доверяет своему собственному УЦ "Альфа", головному УЦ иерархической PKI компании "Бета" и одному УЦ в сетевой PKI компании "Гамма". Внутри каждой корпоративной PKI удостоверяющие центры могут быть связаны одноранговыми или иерархическими связями. Пользователь А может легко добавить новый УЦ или целую корпоративную PKI в свой список доверия. Сложность сертификатов зависит от связей в каждой корпоративной PKI.
Эта архитектура сохраняет основное преимущество простого списка доверия. Если пользователю А в целях бизнеса необходимо доверять пользователям другой PKI, которая не имеет отношений доверия с УЦ пользователя А, список доверия позволяет быстро и просто решить эту проблему, а также использовать преимущества иерархической и сетевой инфраструктур. Чтобы обеспечить безопасность коммуникаций с другими сообществами пользователей, пользователь А может полагаться на надежность отношений доверия, установленных теми удостоверяющими центрами, которым он доверяет. Это позволяет уменьшить количество пунктов доверия, информацию о которых должен обновлять пользователь А.