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

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

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

Завершение

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

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

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

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

Выбор архитектуры PKI

Любой тип архитектуры PKI имеет свои слабые и сильные стороны. Не существует архитектуры, совершенной для всех сред. Выбор оптимальной архитектуры осуществляется с учетом специфики деятельности, потребностей и возможностей организации [70].

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