Ольга Полянская - Инфраструктуры открытых ключей

Дополнение Policy Mappings (соответствие политик) используется, если субъектом сертификата является УЦ. С помощью этого дополнения можно устанавливать соответствие между политиками применения сертификатов разных удостоверяющих центров.

Пример 6.1. Пусть корпорация ACE заключает соглашение с корпорацией ABC о кросс-сертификации с целью защиты электронного обмена данными [167]. Каждая компания имеет свою политику безопасности финансовых транзакций. Очевидно, что просто генерация кросс-сертификатов не обеспечит необходимой функциональной совместимости, так как в каждой компании конфигурирование финансовых приложений и выпуск сертификатов для служащих осуществляются согласно собственной политике. Одно из возможных решений - переконфигурирование всех финансовых приложений и повторный выпуск всех сертификатов в соответствии с требованиями обеих политик. Другим, более простым решением может быть использование дополнения Policy Mappings . Если поле этого дополнения включает кросс-сертификат, выпущенный УЦ компании ACE для УЦ компании ABC, то политика безопасности финансовых транзакций компании ABC считается эквивалентной одноименной политике компании ACE.

Выпуск сертификата одним УЦ для другого является подтверждением надежности сертификатов последнего. Существует три основных способа подтвердить надежность некоторого множества сертификатов. Во-первых, это можно сделать при помощи дополнения Basic Constraints (описанного выше). Второй способ состоит в описании множества сертификатов на основании имен, указанных в поле имени субъекта или альтернативного имени субъекта, в дополнении Name Constraints (ограничения на имена). Это дополнение может использоваться для задания множества допустимых имен или множества неразрешенных имен.

В-третьих, для описания множества сертификатов на основании ограничений политик можно использовать дополнение Policy Constraints (ограничения политик). Это дополнение используется только в сертификатах УЦ и задает проверку пути к политике, запрашивая идентификаторы политик и (или) запрещая задание соответствия политик [2]. Если УЦ выдает универсально надежные сертификаты, то нет необходимости явно указывать в них политики применения сертификатов. Если же сертификаты УЦ, признанного надежным в определенном домене, используются вне этого домена, то требуется явное указание политики применения во всех сертификатах пути сертификации. При помощи дополнения Policy Constraints можно объявить неправомерным дополнение Policy Mappings в том случае, когда сертификация выходит за пределы определенного домена. Это актуально для контроля рисков, возникающих из-за "транзитивного" доверия, когда домен A доверяет домену В , домен В доверяет домену С , но домен A не желает доверять домену С . Если ограничения политики применения сертификатов установлены, то пользователи не станут иметь дело с сертификатами, в которых не указаны определенные политики или дополнение Policy Constraints вообще отсутствует.

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

Стандартно используются следующие спецификаторы политики:

*а) CPS содержит ссылку в виде уникального идентификатора ресурса на опубликованный регламент УЦ (Certification Practice Statement - CPS), в соответствии с которым выпускался данный сертификат;

*б) User Notice содержит указатель на уведомление и/или текст уведомления, которое должно появляться на экране дисплея пользователя сертификата (включая подписчиков и доверяющие стороны) до использования сертификата и информировать о политике применения данного сертификата.

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

Помимо сертификатов открытых ключей формата X.509 v3 существуют сертификаты и других форматов. Остановимся на сертификатах SPKI , PGP , SET и атрибутных сертификатах .

Задачей простой инфраструктуры открытых ключей SPKI(Simple Public Key Infrastructure) является распространение сертификатов для авторизации , а не для аутентификации владельцев открытых ключей. Теоретические основы и требования к SPKI разработаны рабочей группой организации IETF. Базой для SPKI стали основные идеи простой распределенной структуры безопасности - Simple Distributed Security Infrastructure (SDSI), поэтому можно говорить о единой концепции, кратко обозначаемой SPKI/SDSI. Центральными объектами SDSI являются сами ключи, а не имена. Именно ключи могут идентифицировать объекты. Сертификаты SDSI имеют удобную для восприятия форму, как правило, содержат некоторый текст свободного формата, фотографию или другую информацию.

Рабочая группа IETF SPKI разработала ряд технических и информационных документов, в том числе:

*формат сертификата;

*теорию сертификатов;

*требования;

*примеры.

Основная цель сертификата SPKI - это авторизация некоторых действий, выдача разрешений, предоставление возможностей и т.п. владельцу ключа [175]. Сертификаты SPKI часто называют сертификатами авторизации. Сертификаты авторизации , по замыслу авторов идеи SPKI , должны генерироваться любым владельцем ключа, которому разрешено предоставлять или делегировать полномочия. Владелец ключа непосредственно идентифицируется своим открытым ключом, хотя для ряда целей допускается применение некоторых других идентификаторов. Это может быть значение хэш-кода открытого ключа или некоторое имя, которое тем не менее всегда связано с ключом. В связи с тем, что сертификаты SPKI могут содержать информацию, которую владелец ключа не желает публиковать, допускается распространение сертификатов самим владельцем. Владелец ключа может использовать глобальное хранилище, например LDAP, сервер ключей PGP или систему доменных имен DNS.

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