Читать онлайн «Инфраструктуры открытых ключей». Страница 57

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

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

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

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

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

Реальной альтернативой объемным документам, подробно описывающим политику PKI, может стать краткая характеристика политики - документ PDS (PKI Disclosure Statement) [10]. Документ PDS возник как проект группы инженерной поддержки Интернета IETF, затем Американская ассоциация юристов (American Bar Association - ABA) воплотила его идею в соответствующее приложение к своему руководству по оценке инфраструктур открытых ключей - PKI Evaluation Guidelines. Аналогичный документ был разработан также техническим комитетом по безопасности Европейского института стандартов связи (European Telecommunications Standards Institute - ETSI).

Документ, кратко раскрывающий политику PKI, должен занимать не более 2 страниц, в отличие от ППС и регламента, которые обычно излагаются на 8-10 и 40-80 страницах соответственно. PDS описывает самые существенные аспекты деятельности PKI: гарантии, ограничения и юридическую ответственность сторон, он может служить контрольным списком для проверки соответствия практик безопасности двух удостоверяющих центров до вступления их в доверительные отношения. В целом документ PDS больше похож на соглашение с конечным пользователем или владельцем пластиковой карты, чем на обычный документ о политике. Действительно, пользователя среднего уровня подготовки обычно интересует его ответственность в различных ситуациях, а отнюдь не используемые криптографические методы или специфические меры безопасности PKI. Например, тот факт, что для хранения секретного ключа УЦ используется аппаратный ключ (токен), скорее всего, привлечет внимание лишь ограниченного круга лиц, а вот положение об ответственности доверяющей стороны за проверку валидности используемых сертификатов до проведения транзакции заинтересует всех субъектов PKI.

PDS позволяет ограничивать ответственность УЦ, если сертификат использовался не по назначению. Например, издатель сертификатов может опубликовать документ PDS, ограничивающий использование сертификатов только целями бизнеса. Если в дальнейшем клиент компании пожелает использовать свой сертификат для покупки DVD-диска в Интернет-магазине, то не сможет в этом случае рассчитывать на гарантии УЦ. Конкретизируя ответственность сторон, PDS не только обеспечивает защиту издателя сертификатов, но и определяет отношения между всеми субъектами PKI.

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

Как и все другие документы, описывающие политику PKI, PDS не является универсальным. В работе [49] предлагается дополнить список этих документов стандартным шаблоном (XML-таблицей) характеристик политики PKI, что дает возможность свести разработку политики к выбору тех параграфов, которые необходимы конкретной компании, развертывающей PKI, и проставлению в пустых графах соответствующих денежных сумм, временных ограничений и т.п. Этот способ не только дает выигрыш во времени, но и позволяет сравнивать политики разных инфраструктур открытых ключей при кросс-сертификации. Подключение таблицы стиля политики PKI к поисковому механизму дает возможность автоматически анализировать ее структуру. В результате поиска и сравнительного анализа стандартных таблиц, характеризующих политику каждой зарегистрированной PKI, легко установить соответствие политик разных инфраструктур и принять решение о безопасности кросс-сертификации. Этот способ гораздо проще распространенного сегодня бюрократического и трудоемкого метода синхронизации политик PKI.

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

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

Стандарт RFC 2527 Certificate Policy and Certification Practices Framework [152] не обязывает разработчиков политики или регламента называть разделы определенным образом и не устанавливает никаких правил раскрытия положений политики или регламента. Поэтому перечень разделов можно рассматривать как рекомендательный список, позволяющий эффективно сравнивать различные политики применения сертификатов и регламенты при принятии решений о формировании политики. В наборе положений требуется прямо или косвенно (по ссылке) задавать типы спецификаторов политики и их значения, используемые по умолчанию.

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