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

Отображение политики в сертификатах

Отображение политики в сертификатах

Конечно, большинство пользователей не изучают непосредственно ППС и регламент, а получают информацию о политиках PKI косвенно, из таких дополнений сертификатов, как Certificate Policies, Policy Mappings и Policy Constraints, характеризующих соответственно политики применения сертификатов, соответствие политик разных доменов PKI и ограничения на политики. Каждый идентификатор объекта (в данном случае в качестве объекта выступает политика), указанный в дополнении сертификата, соответствует одной ППС. При разработке ППС ей присваивается уникальный идентификатор объекта. В рамках присвоенного идентификатора допускается лишь незначительное изменение политики. Процедура изменения и способ получения последней информации о ППС содержится в самой политике. Регламенты привязываются к идентификаторам политики через ППС, которую они реализуют. ППС может быть реализована в нескольких регламентах, а один регламент может удовлетворять требованиям нескольких политик.

Рис. 13.1.  Реализация одной политики тремя центрами

Пример 13.2. Рассмотрим связи между ППС и регламентами трех разных удостоверяющих центров одной корпоративной PKI, которые выпускают сертификаты в соответствии с одной политикой (рис. 13.1). Каждый УЦ выпускает свои сертификаты согласно политике компании "Альфа" (P_Альфа). Все эти сертификаты содержат один и тот же идентификатор политики в дополнении Certificate Policies. Но каждый УЦ имеет свой собственный регламент, который описывает механизмы и процедуры безопасности, характерные именно для этого центра.

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

Рис. 13.2.  Реализация двух политик тремя центрами

Пример 13.3. Для поддержки широкого круга приложений корпоративная PKI может выпускать сертификаты в соответствии с несколькими политиками. Рассмотрим ситуацию, когда компания "Альфа" использует две политики >[70]. УЦ подразделения 1 выпускает сертификаты согласно политике P₁, УЦ подразделения 2 - согласно политике P₂, а УЦ подразделения 3 - в соответствии с одной из политик ( P₁ или P₂ ) или согласно обеим политикам P₁ и P₂ (рис. 13.2). Выпуск сертификата для каждой из двух политик целесообразен в том случае, когда каждая политика соответствует приложению определенного типа (например, защищенная электронная почта или подписание электронных договоров). Кроме того, политики могут быть ориентированы на разный уровень гарантий, то есть политика P₁ может иметь низкий уровень гарантий, а политика P₂ - высокий. В этом случае сертификат пользователя должен содержать идентификатор либо политики P₁, либо P₂, но не обеих политик. Приложения для сферы с низкими рисками могут принимать сертификаты, выпущенные в соответствии с политикой P₁ или P₂, а приложения для сферы с высокими рисками могут требовать сертификаты, изданные согласно политике P₂.

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

Пример 13.4. Для пользователей А и B компании "Альфа" их домен политик образуют политики P₁ и P₂. Другие корпоративные PKI могут придерживаться политик, которые эквивалентны политикам домена политик пользователейА и B. Допустим, компания "Бета" имеет один УЦ, который выпускает сертификаты в соответствии с тремя политиками P_выс, P_ср и P_низ, соответствующими разным уровням безопасности (высокому, среднему и низкому). Если пользователи А и B при работе сталкиваются с сертификатами стороннего УЦ, то не способны интерпретировать соответствующие идентификаторы политик и, следовательно, определить, какие сертификаты применимы к их приложениям >[70].

Рис. 13.3.  Соответствие политик двух компаний

УЦ "Альфа" может перевести информацию о политиках других доменов в информацию, понятную своим пользователям, при помощи дополнения Policy Mappings (соответствие политик) в своем сертификате. Компания "Альфа" может установить следующее соответствие политик: политика P_выс ( "Бета" ) эквивалентна политике P₂ ( "Альфа" ), а политики P_ср и P_низ ( "Бета" ) эквивалентны политике P₁ ( "Альфа" ). Компания "Бета", в свою очередь, может признать политику P₁ ( "Альфа" ) соответствующей политике P_низ ( "Бета" ), политику P₂ ( "Альфа" ) соответствующей политике P_ср ( "Бета" ), но считать, что ни одна из политик компании "Альфа" не соответствует требованиям политики P_выс ( "Бета" ). В результате приложения, для которых подходят сертификаты компании "Бета" с указанием политики P_выс, не смогут работать с сертификатами компании "Альфа".

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

Оглавление книги