Сертификационные пути и доверие
Пользователь сервиса безопасности является проверяющей стороной, которой требуется знание открытого ключа некоторого субъекта. В этом случае проверяющей стороне необходимо получить сертификат, содержащий требуемый открытый ключ и проверить его действительность. Если проверяющая сторона в настоящий момент не имеет заверенной копии открытого ключа СА, который подписал сертификат, не знает имени СА и, быть может, некоторой дополнительной информации, то ей требуется дополнительный сертификат для получения открытого ключа данного СА. В общем случае может потребоваться цепочка из нескольких сертификатов, содержащая сертификат открытого ключа конечного участника, подписанный одним СА, и ноль или более дополнительных сертификатов САs, подписанных другими САs. Такая цепочка, называемая сертификационным путем, необходима, потому что проверяющая сторона изначально обладает ограниченным количеством открытых ключей САs, полученных надежным способом.
Существуют различные способы, с помощью которых САs могут быть сконфигурированы для того, чтобы проверяющая сторона могла построить сертификационные пути. Первоначально планировалась жесткая иерархическая структура САs. При этом предполагалось существование трех типов уполномоченных органов сертификации:
- Регистрационный уполномоченный орган политики Internet (IPRA): данный уполномоченный орган, функционирующий под руководством Internet-сообщества, действует в качестве корневого органа в сертификационной иерархии. Он выпускает сертификаты только для уполномоченных органов следующего уровня, PCAs. Все сертификационные пути начинаются с IPRA.
- Уполномоченные органы сертификатов политики (PCAs): PCAs являются вторым уровнем иерархии, каждый PCAs сертифицирован IPRA. РСА должны установить и опубликовать утверждение о своей политике в отношении сертифицируемых пользователей или подчиненных уполномоченных органов сертификации. Различные PCAs могут удовлетворять те или иные потребности пользователей. Например, один РСА может выпускать сертификаты для электронной почты, другой РСА может иметь политику, которая удовлетворяет более строгим законодательным требованиям в отношении цифровых подписей.
- Уполномоченные органы сертификации (САs): САs являются третьим уровнем иерархии, но могут иметь и более низкий уровень.
Те, что находятся на третьем уровне, сертифицируются PCAs. САs представляют, например, отдельные организации, отдельные единицы организации (департаменты, отделы, лаборатории) или отдельные географические единицы.
RFC 1422 определяет правило подчинения имен, которое требует, чтобы СА мог выпускать сертификаты только тем пользователям, чьи имена являются подчиненными (в дереве именования Х.500) по отношению к имени самого СА. Доверие, связанное с сертификационным путем, определяется именем РСА. Правило подчинения имен гарантирует, что САs, подчиняющиеся конкретному РСА, ограничены множеством участников, которых они могут сертифицировать (т.е. СА организации может сертифицировать только сотрудников данной организации). Системы сертификации пользователей должны иметь возможность автоматически проверять, выполняется ли правило подчинения имен.
RFC 1422 использует форматы сертификатов Х.509 v1. Ограничения Х.509 v1 требуют нескольких структурных ограничений на четкое связывание информации о политике или ограничения на использование сертификатов. Эти ограничения включают:
- Строгую иерархию сверху вниз, все сертификационные пути начинаются от IPRA.
- Правило подчинения имен ограничивает имена субъектов CAs.
- Использование понятия РСА, которое требует знания индивидуальных PCAs, что встроено в логику проверки цепочки сертификатов. Знание индивидуальных PCAs требуется при определении возможности принятия цепочки сертификатов.
В Х.509 v3 большинство ограничений, определенных в RFC 1422, может быть указано в расширениях сертификата без необходимости иметь строгую иерархическую структуру САs. В частности, расширения сертификата, касающиеся политик, устраняют необходимость применения правила подчинения имен. Как результат, третья версия может поддерживать более гибкую архитектуру:
- сертификационные пути начинаются с открытого ключа СА в собственном домене пользователя или с открытого ключа верхнего уровня иерархии. Начало сертификационного пути с открытого ключа СА в собственном домене пользователя имеет определенные преимущества.В некоторых окружениях больше доверяет локальному домену.
- Ограничения имени могут определяться с помощью явного включения в сертификат расширения ограничения имени, но это не обязательно.
- Расширения политики и отображения политики заменяют понятие РСА, что допускает большую степень автоматизации. Приложение может определить, является ли сертификационный путь действительным, на основании содержимого сертификатов вместо априорного знания открытых ключей PCAs. Это позволяет лучше автоматизировать обработку сертификационного пути.
