Архитектура расширенных списков доверия не избавляет пользователей от необходимости поддерживать актуальность своих списков доверия и не решает проблемы компрометации УЦ. Что касается структуры списка доверия, то пользователь А, выбирая свои пункты доверия, может руководствоваться выгодой или целесообразностью, а вовсе не безопасностью. Длинный список доверия существенно труднее поддерживать, кроме того, как и в случае с простым списком доверия, работая с расширенным списком, пользователь А может вовремя не получить уведомление о компрометации какого-либо УЦ.
Архитектура расширенного списка доверия требует решения новых проблем. Построение пути становится более сложным, поскольку пользователь А не всегда может определить, от какого из доверенных центров следует начинать построение пути сертификации. Пользователь А не имеет возможность строить путь, начиная от своего доверенного УЦ, как это позволяет делать сетевая PKI, - тогда бы ему пришлось формировать цепочку сертификатов для каждого пункта доверия из списка. Поэтому при построении пути пользователю А следует начинать движение от сертификата пользователя, с которым он желает связаться, в направлении одного из доверенных удостоверяющих центров из своего списка доверия.
Построение пути для расширенного списка доверия
Когда используются расширенные списки доверия, реализация должна учитывать как иерархические, так и сетевые PKI. В расширенном списке доверия могут присутствовать головные удостоверяющие центры иерархических PKI и удостоверяющие центры сетевых PKI. Для иерархии может применяться простой способ построения пути сертификации, а для сети - сложный способ. К сожалению, трудно определить, относится ли данный сертификат к иерархии или сети. Кроме того, хотя сертификат был выпущен одним из пунктов доверия, нелегко определить, от какого пункта доверия следует начинать путь сертификации.
Часто используется достаточно простой метод построения пути сертификации в иерархической PKI [84]. Если путь сертификации ведет к одному из доверенных пунктов, то считается, что построен валидный путь ; если нет, то проверяется, был ли выпущен верхний сертификат данного пути сертификации любым пунктом доверия. Если это так, то этот сертификат завершает путь ; если нет, то делается попытка построить путь от каждого пункта доверия к верхнему сертификату данного пути сертификации. Для повышения эффективности построения пути используется кэширование: в кэш-памяти компьютера сохраняются все возможные пути сертификации, каждый из которых помечается признаком качества. Простые иерархические пути считаются более качественными, чем сложные, в итоге выбираются пути с признаком более высокого качества, то есть наиболее короткие. Этот метод можно использовать и в сложных топологиях.
Кросс-сертифицированные корпоративные PKI
Если две организации или сообщества пользователей постоянно взаимодействуют друг с другом и нуждаются в защищенных коммуникациях, то между их инфраструктурами открытых ключей могут быть установлены одноранговые связи.
Рис. 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 имеется не один путь. Каждый путь является валидным, но одни пути длиннее других. Как и в сетевой архитектуре, поиск кратчайшего пути значительно усложняет процесс построения пути.
Архитектура кросс-сертифицированных PKI - подходящее решение в том случае, когда отношения доверия устанавливаются между несколькими корпоративными PKI (их не должно быть много). Рис. 10.8 показывает, что для установления отношений, описанных в примере, потребовались три одноранговые связи и шесть сертификатов удостоверяющих центров. С увеличением числа корпоративных PKI количество связей и сертификатов быстро растет. Кросс-сертификация n-корпоративных PKI требует (n2 - n)/2 - одноранговых связей и (n2 - n) - сертификатов [70].
