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

Профили сертификата и списка отмененных сертификатов

Введение в Х.509v3

Рассмотрим форматы сертификата Х.509 v3 и списка отмененных сертификатов (Certificate Revocation List – CRL) Х.509 v2. Рассмотрим стандартные расширения сертификата и CRL и определим расширения, специфичные для Internet. Рассмотрим алгоритм проверки действительности сертификационного пути.

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

Пользователь сертификата должен просмотреть политику сертификата, созданную СА, прежде чем использовать сертификат.

Сертификат Х.509 версии 3

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

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

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

Сертификационные пути и доверие

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

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

1. Регистрационный уполномоченный орган политики Internet (IPRA): данный уполномоченный орган, функционирующий под руководством Internet-сообщества, действует в качестве корневого органа в сертификационной иерархии. Он выпускает сертификаты только для уполномоченных органов следующего уровня, PCAs. Все сертификационные пути начинаются с IPRA.
2. Уполномоченные органы сертификатов политики (PCAs): PCAs являются вторым уровнем иерархии, каждый PCAs сертифицирован IPRA. РСА должны установить и опубликовать утверждение о своей политике в отношении сертифицируемых пользователей или подчиненных уполномоченных органов сертификации. Различные PCAs могут удовлетворять те или иные потребности пользователей. Например, один РСА может выпускать сертификаты для электронной почты, другой РСА может иметь политику, которая удовлетворяет более строгим законодательным требованиям в отношении цифровых подписей.
3. Уполномоченные органы сертификации (САs): САs являются третьим уровнем иерархии, но могут иметь и более низкий уровень. Те, что находятся на третьем уровне, сертифицируются PCAs. САs представляют, например, отдельные организации, отдельные единицы организации (департаменты, отделы, лаборатории) или отдельные географические единицы.

RFC 1422 определяет правило подчинения имен, которое требует, чтобы СА мог выпускать сертификаты только тем пользователям, чьи имена являются подчиненными (в дереве именования Х.500) по отношению к имени самого СА. Доверие, связанное с сертификационным путем, определяется именем РСА. Правило подчинения имен гарантирует, что САs, подчиняющиеся конкретному РСА, ограничены множеством участников, которых они могут сертифицировать (т.е. СА организации может сертифицировать только сотрудников данной организации). Системы сертификации пользователей должны иметь возможность автоматически проверять, выполняется ли правило подчинения имен.

RFC 1422 использует форматы сертификатов Х.509 v1. Ограничения Х.509 v1 требуют нескольких структурных ограничений на четкое связывание информации о политике или ограничения на использование сертификатов. Эти ограничения включают:

• Строгую иерархию сверху вниз, все сертификационные пути начинаются от IPRA.
• Правило подчинения имен ограничивает имена субъектов CAs.
• Использование понятия РСА, которое требует знания индивидуальных PCAs, что встроено в логику проверки цепочки сертификатов. Знание индивидуальных PCAs требуется при определении возможности принятия цепочки сертификатов.

В Х.509 v3 большинство ограничений, определенных в RFC 1422, может быть указано в расширениях сертификата без необходимости иметь строгую иерархическую структуру САs. В частности, расширения сертификата, касающиеся политик, устраняют необходимость применения правила подчинения имен. Как результат, третья версия может поддерживать более гибкую архитектуру:

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

Отмена сертификата

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

Х.509 определяет один метод отмены сертификата. Данный метод предполагает, что каждый СА периодически выпускает подписанную структуру данных, называемую списком отмененных сертификатом (CRL). CRL является помеченным временем списком, который подписан СА или специальным выпускающим CRL и в котором перечислены отмененные сертификаты. Данный список становится свободно доступен в открытом репозитории. Каждый отмененный сертификат идентифицируется в CRL своим серийным номером. Когда использующая сертификат система получает сертификат (например, для проверки цифровой подписи удаленного пользователя), эта система не только проверяет подпись сертификата и действительность, но также получает свежий CRL и проверяет, не находится ли в этом CRL серийный номер сертификата. Понятие "свежий" может зависеть от локальной политики, но обычно означает самый последний выпущенный CRL. Новый CRL выпускается регулярно (например, каждый час, день или неделю). При получении уведомления об отмене запись добавляется в CRL.

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

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

Как и формат сертификата Х.509 v3, для того, чтобы обеспечить интероперабельность реализаций различных производителей, необходимо иметь строгий формат Х.509 CRL v2. Существуют также специальные протоколы и соответствующие им форматы сообщений, поддерживающих on-line оповещения об отмене. On-line методы оповещения об отмене могут применяться в некоторых окружениях как альтернатива CRL. On-line проверка отмены может существенно уменьшить промежуток между отправкой сообщения об отмене и получением этой информации проверяющей стороной. После того как СА принимает и аутентифицирует сообщение от субъекта сертификата или от RA о необходимости отмены данного сертификата, любой запрос к on-line сервису будет корректно отображать действительность сертификата. Однако эти методы навязывают новые требования безопасности: проверяющая сторона должна доверять on-line сервису действительности, в то время как репозиторий не обязательно должен быть доверяемым.