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

В связанные мостом инфраструктуры легко добавляются новые удостоверяющие центры или даже целые корпоративные PKI [100]. Изменения остаются прозрачными для пользователей, пока они не касаются пунктов доверия . По мере роста PKI число отношений доверия, которые должны быть установлены, начинает превышать разумное и поддающееся управлению. На рис. 10.10для трех корпоративных PKI были установлены три отношения доверия, как и в примере кросс-сертификации ( рис. 10.8). Рис. 10.11иллюстрирует связывание восьми корпоративных PKI при помощи мостового УЦ . Это требует установления восьми отношений доверия, а не двадцати восьми, как требовалось в варианте кросс-сертификации ( рис. 10.8).

Рис. 10.11. Связывание восьми корпоративных PKI при помощи мостового УЦ

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

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

Мостовой УЦ имеет ряд преимуществ по сравнению с кросс-сертифицированными PKI. Разные пользователи по-прежнему строят разные пути сертификации для одного и того же сертификата конечного субъекта, и путь сертификации начинается с пункта доверия пользователя, который желает построить путь до данного сертификата . Однако существует только один кросс-сертификат, связывающий данную PKI со всеми сторонними PKI. Это существенно упрощает построение пути сертификации . На рис. 10.10показаны пути сертификации , которые связывают пользователя А и пользователей B , C и D . Пользователь D может построить не один путь , так как является участником сетевой PKI.

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

Дается определение валидного пути сертификации, описывается процедура проверки валидности пути; рассматриваются входные параметры и переменные состояния, необходимые для валидации пути сертификации; объясняются принципы обработки каждого сертификата и механизм выявления в пути сертификации аннулированных сертификатов, обсуждаются подходы к выбору архитектуры PKI.

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

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

Путь сертификации считается валидным, если образующая его последовательность сертификатов удовлетворяет следующим условиям [89].

*I. Первый сертификат издан пунктом доверия .

*II. Последний сертификат издан для данного конечного субъекта и содержит данный открытый ключ.

*III. Имена издателей и субъектов сертификатов образуют последовательность. Во всех сертификатах этой последовательности, за исключением первого и последнего, имя издателя текущего сертификата совпадает с именем субъекта предыдущего сертификата, а имя субъекта текущего сертификата совпадает с именем издателя следующего сертификата.