Переменная состояния статуса сертификата принимает одно из трех значений: "аннулирован" (с указанием причины аннулирования ), "не аннулирован" и "статус сертификата не определен". Первоначально переменная состояния статуса сертификата имеет значение "не аннулирован", оно не меняется до тех пор, пока в ходе проверки не обнаруживаются доказательства аннулирования.
Обработка САС
Как только инициализация закончена, обрабатывается один или несколько списков САС. Обработка выполняется до тех пор, пока либо не выяснится, что сертификат аннулирован, либо не будут проверены все списки САС, указанные в дополнении проверяемого сертификата 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. Приложения не должны использовать сертификаты или содержащиеся в них открытые ключи без предварительного построения и валидации пути сертификации.
Выбор архитектуры PKI
Любой тип архитектуры PKI имеет свои слабые и сильные стороны. Не существует архитектуры, совершенной для всех сред. Выбор оптимальной архитектуры осуществляется с учетом специфики деятельности, потребностей и возможностей организации [70].
Одиночный УЦ - простое и рациональное решение для небольшого однородного сообщества. Когда сообщество может договориться с одиночным УЦ о выпуске всех своих сертификатов, исчезают проблемы, связанные с построением и валидацией пути сертификации. Компрометация одиночного УЦ, безусловно, является катастрофой и делает недействительными все выпущенные им сертификаты. В результате сообщество полностью теряет доступ к сервисам безопасности. С другой стороны, такое сплоченное сообщество способно эффективно распространить уведомление о компрометации и быстро восстановить PKI.