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

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

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

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

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

Архитектура кросс-сертифицированных PKI - подходящее решение в том случае, когда отношения доверия устанавливаются между несколькими корпоративными PKI (их не должно быть много). Рис. 10.8показывает, что для установления отношений, описанных в примере, потребовались три одноранговые связи и шесть сертификатов удостоверяющих центров. С увеличением числа корпоративных PKI количество связей и сертификатов быстро растет. Кросс-сертификация n-корпоративных PKI требует (n 2- n)/2 - одноранговых связей и (n 2- n) - сертификатов [70].

Рис. 10.9. Восемь кросс-сертифицированных PKI

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

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

В отличие от сетевого центра, мостовой УЦ не выпускает сертификаты непосредственно для пользователей, а, в отличие от головного УЦ, в иерархии мостовой УЦ не является пунктом доверия . Все пользователи PKI рассматривают мостовой УЦ в качестве посредника. Мостовой УЦ устанавливает одноранговые отношения с разными корпоративными PKI. Эти отношения принимают вид моста доверия, который связывает пользователей разных PKI [10]. Если домен доверия реализован как иерархическая PKI, мостовой УЦ устанавливает связь с головным УЦ иерархии. Если домен реализован как сетевая PKI, мостовой УЦ устанавливает связь только с одним из удостоверяющих центров сети. Удостоверяющий центр, который вступает в отношения с мостовым УЦ , называется главным УЦ.

Пример 10.7. На рис. 10.10 мостовой УЦ связан с тремя корпоративными PKI. Первая PKI - это УЦ пользователей А и В , вторая - иерархическая PKI пользователя С , и третья - сетевая PKI пользователя D . Никто из пользователей не доверяет непосредственно мостовому УЦ . Пользователи А и В доверяют УЦ "Альфа" , который является издателем их сертификатов, они доверяют мостовому УЦ постольку, поскольку их собственный УЦ выпустил для него сертификат. Пункт доверия пользователя С - головной УЦ в его иерархии; пользователь С доверяет мостовому УЦ косвенно, потому что данный головной УЦ выпустил для того сертификат. Пользователь D доверяет издателю своего сертификата - УЦ 3 компании "Гамма" и косвенно доверяет мостовому УЦ , потому что существует правильный путь сертификации от УЦ 3 до мостового УЦ . Пользователи А и В могут использовать мост доверия для установления отношений с пользователями С и D .

Рис. 10.10. Связывание трех корпоративных PKI при помощи мостового УЦ и построение путей сертификации

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