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

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

Пример 10.5. Чтобы защищенно связываться с пользователями B , C и D , пользователь А должен включить в свой расширенный список доверия три удостоверяющих центра: по одному УЦ от каждой доверенной PKI ( см. рис. 10.7). Пользователь А доверяет своему собственному УЦ "Альфа" , головному УЦ иерархической PKI компании "Бета" и одному УЦ в сетевой PKI компании "Гамма" . Внутри каждой корпоративной PKI удостоверяющие центры могут быть связаны одноранговыми или иерархическими связями. Пользователь А может легко добавить новый УЦ или целую корпоративную PKI в свой список доверия . Сложность сертификатов зависит от связей в каждой корпоративной PKI.

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

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

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

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

Часто используется достаточно простой метод построения пути сертификации в иерархической PKI [84]. Если путь сертификации ведет к одному из доверенных пунктов , то считается, что построен валидный путь ; если нет, то проверяется, был ли выпущен верхний сертификат данного пути сертификации любым пунктом доверия . Если это так, то этот сертификат завершает путь ; если нет, то делается попытка построить путь от каждого пункта доверия к верхнему сертификату данного пути сертификации . Для повышения эффективности построения пути используется кэширование: в кэш-памяти компьютера сохраняются все возможные пути сертификации , каждый из которых помечается признаком качества. Простые иерархические пути считаются более качественными, чем сложные, в итоге выбираются пути с признаком более высокого качества, то есть наиболее короткие. Этот метод можно использовать и в сложных топологиях.

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

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

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