Построение пути в мостовой PKI
Мостовой УЦ имеет ряд преимуществ по сравнению с кросс-сертифицированными PKI. Разные пользователи по-прежнему строят разные пути сертификации для одного и того же сертификата конечного субъекта, и путь сертификации начинается с пункта доверия пользователя, который желает построить путь до данного сертификата. Однако существует только один кросс-сертификат, связывающий данную PKI со всеми сторонними PKI. Это существенно упрощает построение пути сертификации. На рис. 10.10 показаны пути сертификации, которые связывают пользователя А и пользователей B, C и D. Пользователь D может построить не один путь, так как является участником сетевой PKI.
Когда простые и иерархические PKI связаны мостом доверия, построение пути сертификации лишь немного сложнее, чем в обычной иерархической PKI [101]. Внутри иерархии может быть использован простой способ построения пути, но когда он перестает работать, выбирается только один кросс-сертификат, который издан мостовым УЦ. Среди многих кросс-сертификатов, выпущенных для мостового УЦ, только один сертификат будет издан одиночным УЦ простой PKI или головным УЦ иерархической PKI. Нахождение пункта доверия на основе кросс-сертификатов, выпущенных для мостового УЦ, - достаточно простая задача. Когда мостом доверия связаны сетевые PKI, построение пути сертификации внутри сети остается сложным. Однако если каждая из сторонних PKI управляет отдельным пространством имен, предположения о том, какой сертификат является наиболее подходящим, обычно бывают правильными. Кроме того, введение мостового УЦ не приводит к образованию дополнительных петель, петли могут появляться только внутри сетевой PKI.
Лекция 11. Валидация пути сертификации
Дается определение валидного пути сертификации, описывается процедура проверки валидности пути; рассматриваются входные параметры и переменные состояния, необходимые для валидации пути сертификации; объясняются принципы обработки каждого сертификата и механизм выявления в пути сертификации аннулированных сертификатов, обсуждаются подходы к выбору архитектуры PKI.
Процедура проверки валидности пути
После построения пути сертификации необходимо проверить его валидность. Проверка валидности пути заключается в верификации всех цифровых подписей на сертификатах, составляющих путь сертификации, определении периода действия каждого сертификата (чтобы гарантировать, что его срок действия не истек) и статуса каждого сертификата (чтобы гарантировать, что сертификат не был аннулирован), а также в отслеживании ограничений на политики применения сертификатов, на имена и т.д. Валидация пути обычно менее трудоемка, чем построение пути, но проверка всех ограничений может оказаться сложной, если путь сертификации достаточно длинный. В реализациях PKI используются различные алгоритмы валидации пути, некоторые из них объединяют построение и валидацию, но в большинстве алгоритмов эти операции реализованы как отдельные этапы. Рассмотрим, как проверяется валидность пути сертификации после того, как он построен.
Путь сертификации должен начинаться в пункте доверия того субъекта, который строил путь, в противном случае путь был построен неправильно. Входными данными для валидации пути сертификации являются открытый ключ пункта доверия, период действия этого открытого ключа, имя пункта доверия и любые ограничения, которые налагаются на пути сертификации, связанные с данным пунктом доверия. Во многих реализациях PKI эта информация содержится в самоподписанном или самоизданном сертификате УЦ, являющегося пунктом доверия.
Путь сертификации считается валидным, если образующая его последовательность сертификатов удовлетворяет следующим условиям [89].
* I. Первый сертификат издан пунктом доверия.
* II. Последний сертификат издан для данного конечного субъекта и содержит данный открытый ключ.
* III. Имена издателей и субъектов сертификатов образуют последовательность. Во всех сертификатах этой последовательности, за исключением первого и последнего, имя издателя текущего сертификата совпадает с именем субъекта предыдущего сертификата, а имя субъекта текущего сертификата совпадает с именем издателя следующего сертификата.
* IV. Период действия всех сертификатов не истек, то есть все сертификаты последовательности на момент валидации являются действующими.
Этот набор условий необходим, но не достаточен для того, чтобы путь сертификации был валидным. Помимо перечисленных условий, должны анализироваться и обрабатываться содержащиеся в сертификатах пути основные ограничения, а также ограничения на имена и политики [60]. Эта обработка выполняется за четыре основных шага:
1 Инициализация.
2 Базовая проверка сертификата.
3 Подготовка следующего сертификата в последовательности.
4 Завершение.
Шаги 1 и 4 выполняются однократно. Шаг 2 выполняется для каждого сертификата в последовательности, а шаг 3 - для всех сертификатов, за исключением последнего - сертификата конечного субъекта.
Валидация пути сертификации обычно выполняется для подтверждения валидности пути в текущий момент времени. В лекции рассматривается именно такая валидация, хотя тот же алгоритм может использоваться и для управления валидацией в моменты времени, предшествовавшие текущему моменту. Для валидации пути сертификации требуется несколько входных параметров, иногда их значения устанавливаются по умолчанию. Устанавливаемые по умолчанию значения подходят не для всех приложений.
Входными параметрами для валидации пути сертификации являются:
* предполагаемый путь сертификации;
* набор идентификаторов допустимых политик применения сертификатов ;
* информация о пункте доверия ;
* индикатор, показывающий, разрешено ли устанавливать соответствие политик применения сертификатов в пути сертификации ;