Инфраструктура Открытого Ключа (часть 5)

Проверка действительности сертификационного пути

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

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

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

Выбор доверенного корневого органа является вопросом политики: это может быть самый верхний СА в иерархии, либо CA, который выпустил свой(и) сертификат(ы) для проверки, или какой-то другой СА. Процедура проверки действительности пути является той же самой, независимо от выбора корневого органа.

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

Проверка действительности базового пути

При проверке действительности сертификационного пути следует использовать процедуру обработки пути Х.509, которая функционально эквивалентна внешнему поведению данного алгоритма. Однако поддержка некоторых расширений сертификата, обрабатываемых данным алгоритмом, не всегда обязательна. Клиенты, которые не поддерживают эти расширения, могут пропустить соответствующие шаги в алгоритме проверки действительности пути.

Например, некоторым клиентам не требуется поддержка расширения отображения политики безопасности. Клиенты, которые не поддерживают данное расширение, могут пропустить шаги проверки действительности пути, где обрабатываются отображения политики. Заметим, что клиенты должны отвергать сертификат, если он содержит неподдерживаемое критичное расширение.

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

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

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

Для достижения данной цели процесс проверки действительности пути проверяет, помимо прочего, чтобы ожидаемые сертификационные пути (последовательность из n сертификатов) удовлетворяли следующим условиям:

1. Для всех х в {1, ..., n-1} субъект сертификата х является выпускающим сертификата х+1.
2. Сертификат 1 выпущен доверенным начальным сертификатом.
3. Сертификат n является действительным сертификатом.
4. Для всех х в {1, ..., n-1} сертификат был действительным в момент запроса.

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

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

Сертификат является самовыпущенным, если DNs, которые появляются в полях субъекта и выпускающего, одинаковы и не пусты. В общем случае выпускающие и субъекты сертификатов, которые формируют путь, для каждого сертификата различны. Однако СА может выпустить сертификат для себя для поддержки обновления своего сертификата или изменений в сертификационных политиках. Эти самовыпущенные сертификаты при подсчете длины пути или ограничений имени не учитываются.

Данный раздел описывает алгоритм, состоящий из четырех основных шагов:

1. Инициализация.
2. Базовая обработка сертификата.
3. Подготовка для обработки следующего сертификата.
4. Завершение (wrap-up).

Шаги (1) и (4) выполняются только один раз. Шаг (2) выполняется для всех сертификатов в пути. Шаг (3) выполняется для всех сертификатов в пути, за исключением последнего. На рис.17.1 представлена высокоуровневая диаграмма потока для данного алгоритма.