Инфраструктуры открытых ключей

После построения пути сертификации необходимо проверить его валидность. Проверка валидности пути заключается в верификации всех цифровых подписей на сертификатах, составляющих путь сертификации, определении периода действия каждого сертификата (чтобы гарантировать, что его срок действия не истек) и статуса каждого сертификата (чтобы гарантировать, что сертификат не был аннулирован), а также в отслеживании ограничений на политики применения сертификатов, на имена и т.д. Валидация пути обычно менее трудоемка, чем построение пути, но проверка всех ограничений может оказаться сложной, если путь сертификации достаточно длинный. В реализациях 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 не являются валидными, потому что принадлежат запрещенным поддеревьям.

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

Базовый контроль сертификата

Подготовка следующего сертификата

Сначала выполняется некоторая простая проверка сертификата УЦ. Затем обновляются переменные состояния, для того чтобы они могли отражать значения полей дополнений сертификата. Существует несколько дополнений, которые встречаются только в сертификатах УЦ; они используются для задания ограничений для подчиненных сертификатов. Обновление переменных состояния налагает ограничения на подчиненные сертификаты, когда выполняется последующая базовая проверка сертификатов.

Проверка того, что сертификат является сертификатом УЦ. Обычно эта информация указывается в дополнении Basic Constraints (основные ограничения). Сертификат должен содержать открытый ключ подписи. Проверяется, действительно ли это так и разрешает ли дополнение Key Usage (назначение ключа) применять ключ для подписания сертификатов.

Проверка длины пути сертификации. Проверяется, не была ли превышена максимальная длина пути сертификации.

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

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

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

Соответствие политик. В дополнение Policy Mapping (соответствие политик) не рекомендуется включать специальный идентификатор "любая политика". Если в поле этого дополнения появляется идентификатор "любая политика", то путь сертификации не признается валидным. Если в поле этого дополнения появляются идентификаторы других политик, то переменные состояния соответствия политик корректируются с учетом преобразования определенной политики домена издателя в определенную политику домена субъекта.

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

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

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

Завершение обработки сертификата

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

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

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

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

* политики применения сертификатов и любые связанные с политикой квалификаторы;

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

В процессе валидации пути сертификации проверяется, не был ли аннулирован издателем хотя бы один сертификат из цепочки сертификатов [167]. С этой целью часто используются списки аннулированных сертификатов (см. лекцию 8). Выявление аннулированных сертификатов состоит из трех последовательных шагов:

1 инициализации ;

2 обработки САС;

3 завершения.

Каждый шаг выполняется один раз. В случае необходимости на втором шаге могут быть проверены несколько списков САС. Иногда анализируют не все коды причины аннулирования, а ограничиваются, например, только компрометацией ключа УЦ. Процедура обработки аннулирования, описываемая в данном разделе, предполагает проверку всех кодов причины аннулирования и требует наличия двух входных элементов: сертификата и индикатора дельта-списка САС. Комбинация серийного номера сертификата и имени издателя позволяет установить, находится ли данный сертификат в настоящий момент в определенном САС. Дополнение сертификата Basic Constraints (основные ограничения) информирует о принадлежности сертификата конечному субъекту или УЦ. Информация о пункте распространения САС и последней версии САС позволяет определить, должен ли применяться САС для выяснения статуса сертификата. Индикатор дельта-списка САС (см. лекцию 9) показывает, должны ли использоваться дельта-списки САС. Во время инициализации на базе входных параметров устанавливаются значения переменных состояния.

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

Переменная состояния статуса сертификата принимает одно из трех значений: "аннулирован" (с указанием причины аннулирования ), "не аннулирован" и "статус сертификата не определен". Первоначально переменная состояния статуса сертификата имеет значение "не аннулирован", оно не меняется до тех пор, пока в ходе проверки не обнаруживаются доказательства аннулирования.

Обработка САС

Как только инициализация закончена, обрабатывается один или несколько списков САС. Обработка выполняется до тех пор, пока либо не выяснится, что сертификат аннулирован, либо не будут проверены все списки САС, указанные в дополнении проверяемого сертификата CRL Distribution Points (пункты распространения САС), а переменная состояния статуса сертификата сохранит значение "не аннулирован". Обработка каждого САС состоит из шести шагов [167].

* Шаг 1. САС считывается или помещается в локальную кэш-память компьютера для хранения. САС может охватывать коды причины аннулирования полностью или частично.

* Шаг 2. Проверяется издатель САС. Если в дополнении CRL Distribution Points данного сертификата последовательности указано имя издателя САС, то оно сравнивается с именем издателя обрабатываемого САС. Если эти имена различны, то проверяется, совпадает ли имя издателя обрабатываемого САС с именем издателя данного сертификата. Когда используются косвенные списки САС, то имя издателя САС, указанное в дополнении CRL Distribution Points сертификата, отличается от имени издателя этого сертификата.

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

* Шаг 4. Подтверждается, что САС является текущим. Если в поле CRL Next Update (следующее обновление САС) указано время, предшествующее текущему моменту, то необходимо либо получить соответствующий дельта-список для обновления САС, либо отбросить САС. Если начальное значение индикатора дельта-списка установлено и присутствует дополнение Freshest CRL (последняя версия САС), то получают дельта-список, соответствующий данному базовому САС. Для дельта-списка САС проверяется его соответствие тому же самому набору сертификатов и тому же самому набору кодов причин, которые содержит и базовый САС. Кроме того, проверяется, был ли он издан тем же самым УЦ и заверен тем же самым ключом, что и базовый САС. Если все эти проверки завершены успешно, то проверяется цифровая подпись дельта-списка САС. Если подпись верна, то объединяются базовый список и дельта-список САС.

* Шаг 5. Корректировка переменной состояния маски причины. Значение переменной состояния устанавливается как объединение текущего значения и списка кодов причины для САС, определенного ранее.

* Шаг 6. Поиск сертификата с заданным серийным номером в САС. Если в сертификате имеется дополнение Issuer CRL Entry (точка входа САС издателя), то значение этого дополнения должно совпадать с именем издателя сертификата. Если в сертификате отсутствует дополнение Issuer CRL Entry, то должны совпадать имена издателя сертификата и издателя САС. Если для сертификата с заданным серийным номером имена издателей совпадают, то сертификат аннулирован. В этом случае переменная состояния статуса сертификата принимает значение, соответствующее причине аннулирования.

Если переменная состояния маски причин не отражает того, что все причины аннулирования проверены, а переменная состояния статуса сертификата имеет значение "не аннулирован", то выполняется пошаговая обработка следующего САС, указанного в дополнении сертификата CRL Distribution Points. Если обработаны все списки САС из дополнения CRL Distribution Points, но не все причины аннулирования проверены, то должны быть получены и проанализированы дополнительные списки САС. Информация о них хранится в репозитории издателя данного сертификата. Пошаговая процедура обработки повторяется для каждого дополнительного САС, после этого выполняется процедура завершения.

Завершение

Если все списки САС проанализированы, а переменная состояния маски причины не показывает, что все причины аннулирования проверены, то переменная состояния статуса сертификата принимает значение "не определен". Большинство приложений будет реагировать на этот статус так же, как и на статус "аннулирован", остальные приложения уведомят пользователя о неопределенном статусе сертификата. После этого проверка сертификата на предмет аннулирования завершается, и выводится значение переменной состояния статуса сертификата.

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

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

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