Лекция 11. Валидация пути сертификации
Дается определение валидного пути сертификации, описывается процедура проверки валидности пути; рассматриваются входные параметры и переменные состояния, необходимые для валидации пути сертификации; объясняются принципы обработки каждого сертификата и механизм выявления в пути сертификации аннулированных сертификатов, обсуждаются подходы к выбору архитектуры PKI.
Процедура проверки валидности пути
После построения пути сертификации необходимо проверить его валидность. Проверка валидности пути заключается в верификации всех цифровых подписей на сертификатах, составляющих путь сертификации, определении периода действия каждого сертификата (чтобы гарантировать, что его срок действия не истек) и статуса каждого сертификата (чтобы гарантировать, что сертификат не был аннулирован), а также в отслеживании ограничений на политики применения сертификатов, на имена и т.д. Валидация пути обычно менее трудоемка, чем построение пути, но проверка всех ограничений может оказаться сложной, если путь сертификации достаточно длинный. В реализациях PKI используются различные алгоритмы валидации пути, некоторые из них объединяют построение и валидацию, но в большинстве алгоритмов эти операции реализованы как отдельные этапы. Рассмотрим, как проверяется валидность пути сертификации после того, как он построен.
Путь сертификации должен начинаться в пункте доверия того субъекта, который строил путь, в противном случае путь был построен неправильно. Входными данными для валидации пути сертификации являются открытый ключ пункта доверия, период действия этого открытого ключа, имя пункта доверия и любые ограничения, которые налагаются на пути сертификации, связанные с данным пунктом доверия. Во многих реализациях PKI эта информация содержится в самоподписанном или самоизданном сертификате УЦ, являющегося пунктом доверия.
Путь сертификации считается валидным, если образующая его последовательность сертификатов удовлетворяет следующим условиям [89].
* I. Первый сертификат издан пунктом доверия.
* II. Последний сертификат издан для данного конечного субъекта и содержит данный открытый ключ.
* III. Имена издателей и субъектов сертификатов образуют последовательность. Во всех сертификатах этой последовательности, за исключением первого и последнего, имя издателя текущего сертификата совпадает с именем субъекта предыдущего сертификата, а имя субъекта текущего сертификата совпадает с именем издателя следующего сертификата.
* IV. Период действия всех сертификатов не истек, то есть все сертификаты последовательности на момент валидации являются действующими.
Этот набор условий необходим, но не достаточен для того, чтобы путь сертификации был валидным. Помимо перечисленных условий, должны анализироваться и обрабатываться содержащиеся в сертификатах пути основные ограничения, а также ограничения на имена и политики [60]. Эта обработка выполняется за четыре основных шага:
1 Инициализация.
2 Базовая проверка сертификата.
3 Подготовка следующего сертификата в последовательности.
4 Завершение.
Шаги 1 и 4 выполняются однократно. Шаг 2 выполняется для каждого сертификата в последовательности, а шаг 3 - для всех сертификатов, за исключением последнего - сертификата конечного субъекта.
Валидация пути сертификации обычно выполняется для подтверждения валидности пути в текущий момент времени. В лекции рассматривается именно такая валидация, хотя тот же алгоритм может использоваться и для управления валидацией в моменты времени, предшествовавшие текущему моменту. Для валидации пути сертификации требуется несколько входных параметров, иногда их значения устанавливаются по умолчанию. Устанавливаемые по умолчанию значения подходят не для всех приложений.
Входными параметрами для валидации пути сертификации являются:
* предполагаемый путь сертификации;
* набор идентификаторов допустимых политик применения сертификатов ;
* информация о пункте доверия ;
* индикатор, показывающий, разрешено ли устанавливать соответствие политик применения сертификатов в пути сертификации ;
* индикатор, показывающий, требуются ли в сертификатах явные идентификаторы политики ;
* индикатор, показывающий, разрешено ли указывать в сертификатах специальный идентификатор "любая политика".
Инициализация
На этапе инициализации в зависимости от входных параметров устанавливаются переменные состояния, необходимые для валидации пути сертификации [70]. В переменных состояния сохраняются различные ограничения, учитываемые при валидации пути. Переменные состояния делятся на четыре группы.
Первая группа переменных состояния используется для сохранения информации, необходимой для верификации цифровых подписей: открытого ключа, связанных с ним параметров и названия алгоритма цифровой подписи.
Вторая группа переменных состояния предназначена для сохранения информации о цепочке имен и длине пути сертификации. Переменная состояния отличительного имени ожидаемого издателя используется для подтверждения корректной связи между отличительным именем издателя и отличительным именем субъекта в последовательности сертификатов. Переменная состояния длины пути отражает максимальное число сертификатов в последовательности. Значение этой переменной зависит от ограничения длины пути в дополнении сертификата Basic Constraints (основные ограничения).
Третья группа переменных состояния применяется для сохранения информации о политиках применения сертификатов, образующих путь сертификации. Эти переменные позволяют оценить, является ли критичным дополнение Certificate Policy ( политика применения сертификатов ), необходим ли явный идентификатор политики, разрешено ли отображать дополнительную политику и указывать в сертификатах идентификатор "любая политика".
Рис. 11.1. Пример проверки ограничений на имена
Четвертая группа переменных состояния отслеживает правильность именования. Для каждого типа имени должны анализироваться разрешенные и запрещенные поддеревья в иерархической структуре имен. Валидные имена должны содержаться в одном из разрешенных поддеревьев и не содержаться ни в одном из запрещенных поддеревьев.
На рис. 11.1 показан пример использования доменных имен Интернета [70]. Имя host.spyrus.com не является валидным, так как не принадлежит ни одному из разрешенных поддеревьев. Имена mail.department2.beta.com и file-server.department2.gamma.com не являются валидными, потому что принадлежат запрещенным поддеревьям.
Как только все переменные состояния инициализированы, осуществляется базовый контроль первого сертификата в последовательности.
Базовый контроль сертификата
Базовый контроль сертификата выполняется для всех сертификатов последовательности и состоит из ряда проверок [167]. Проверки, использующие каждую из четырех групп переменных состояния, выполняются, чтобы определить, не является ли сертификат просроченным или аннулированным, удовлетворяет ли сертификат ограничениям сертификатов последовательности, предшествующих ему или следующих за ним. Если любая из проверок дает отрицательный результат, то путь сертификации не считается валидным.
Проверка срока действия сертификата
Эта проверка завершается успешно, если текущие дата и время на момент валидации находятся в пределах срока действия сертификата.
Проверка статуса сертификата
Эта проверка завершается успешно, если издатель не аннулировал данный сертификат. Основным средством проверки статуса сертификата являются списки САС, но могут использоваться и другие альтернативные средства проверки.
Проверка подписи сертификата
Подпись сертификата может быть проверена на базе первой группы переменных состояния при помощи открытого ключа издателя сертификата, использования корректных параметров и алгоритма цифровой подписи.
