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

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

Рис. 10.8.  Кросс-сертифицированные корпоративные PKI и пути сертификации пользователя А

Пример 10.6. На рис. 10.8 УЦ пользователя А кросс-сертифицирован с головным УЦ иерархической PKI компании "Бета" и УЦ подразделения 2 в сетевой PKI компании "Гамма". Кроме того, удостоверяющие центры компаний "Бета" и "Гамма" кросс-сертифицированы друг с другом. Каждый пользователь поддерживает один пункт доверия. Пользователи A, B и D доверяют удостоверяющим центрам, которые выпустили их сертификаты, а пользователь С доверяет своему головному УЦ. Межкорпоративные отношения являются одноранговыми, а внутри корпоративных инфраструктур установлены или одноранговые, или иерархические связи. Имея свой список доверия, пользователь А не может добавлять в него новый УЦ внешней PKI по своему усмотрению, а должен полагаться на действия администратора своего пункта доверия. А дминистраторы УЦ обычно имеют более высокую квалификацию, чем пользователи, и способны определить надежность УЦ или PKI. Прежде чем устанавливать отношения кросс-сертификации, администраторы УЦ анализируют политику и практику применения сертификатов другого УЦ. После кросс-сертификации удостоверяющих центров пользователь В получает возможность проверять валидность сертификатов пользователей С и D из других PKI. В соответствии с принципами архитектуры расширенного списка доверия пользователям необходимо обновлять свои собственные списки доверия.

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

Построение пути для кросс-сертифицированных PKI

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

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

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