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

Понятие политики сертификата и регламента сертификационной практики

Введение

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

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

Сертификат Х.509 v3 может содержать поля, декларирующие, что для данного сертификата применялись одна или более политик сертификата. Соответственно, политика сертификата есть "поименованное множество правил, которые определяют применимость сертификата для конкретного сообщества и/или класса приложений с общими требованиями безопасности". Политика сертификата может применяться пользователем сертификата при решении вопроса о том, может ли доверять сертификату и содержащейся в нем информации для конкретного приложения.

Детальное описание регламента, которому следует СА при выпуске и управлении сертификатами, содержится в регламенте сертификационной практики ( Certification Practice Statement - CPS ), публикуемом СА.

Рассмотрим взаимосвязь между политиками сертификата и CPS.

Определим элементы, которые могут потребоваться при создании политики сертификата или CPS.

Мы ограничимся обсуждением понятий политики сертификата (как определено в Х.509) и CPS. В частности, опишем типы информации, которые могут быть включены в определение политики сертификата или CPSs. Хотя предполагается использование формата сертификата Х.509 версии 3, не обязательно ограничиваться применением только данного формата сертификата. Более того, считается, что данная основа может быть адаптирована для других форматов сертификата.

Основные понятия

Политика сертификата

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

Стандарт Х.509 определяет политику сертификата как "именованное множество правил, которые определяют применимость сертификата для конкретного сообщества и/или класса приложений с общими требованиями безопасности". Сертификат Х.509 v3 может содержать индикацию политики сертификата, которая может применяться пользователем сертификата при принятии решения о том, можно ли задействовать сертификат для той или иной цели.

Политика сертификата, которую должны распознавать как выпускающий, так и пользователь сертификата, представлена в сертификате уникальным зарегистрированным Object Identifier. Процесс регистрации должен следовать стандартам ISO/IEC и ITU. Участник, который регистрирует Object Identifier, также публикует текстовую спецификацию политики сертификата. В сертификате обычно декларируется единственная политика сертификата или, возможно, небольшое число различных политик.

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

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

В качестве примера предположим, что некая организация определила две политики сертификата - одну для использования в общих целях ( General-Purpose ), другую для проведения финансовых транзакций ( Commercial-Grade ).

Будем считать, что политика General-Purpose предназначена для защиты передаваемой информации (например, e-mail) или для аутентифицированных соединений от браузеров к серверам. Пара ключей может создаваться, храниться и управляться с использованием дешевых, основанных на ПО систем. При такой политике сертификат может автоматически выпускаться для любого сотрудника, который перешлет подписанный запрос сертификата системному администратору организации.

Политика Commercial-Grade используется для защиты финансовых транзакций. Для такой политики требуется, чтобы пара сертифицированных ключей создавалась и хранилась в соответствующих криптографических аппаратных токенах. Сертификаты и токены предоставляются сотрудникам. Требуется, чтобы эти авторизованные лица сами приходили в офис безопасности, выполняли некоторые формальные процедуры идентификации, подписывали обязательство по защите токена и т.п.

Поля сертификата Х.509

Следующие поля расширения в сертификате Х.509 используются для поддержки политик сертификата:

• Расширение CertificatePolicies ,
• Расширение PolicyMappings ,
• Расширение PolicyConstraints .

Расширение CertificatePolicies

Расширение CertificatePolicies имеет два варианта - один с полем, помеченным как некритичное, другой с полем, помеченным как критичное. Назначение поля в этих двух случаях различается.

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

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

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

Расширение PolicyMappings

Расширение PolicyMapping может использоваться только в сертификатах СА. Данное поле позволяет СА указать, что некоторые политики в его собственном домене могут считаться эквивалентными некоторым другим политикам в домене субъекта СА.

Например, предположим, что между корпорациями существует соглашение на кросс-сертификацию открытых ключей. Далее предположим, что обе корпорации имеют ранее определенные политики безопасности для защиты финансовых транзакций, которые называются по-разному. Можно видеть, что простое создание кросс-сертификатов не обеспечивает необходимой интероперабельности, так как приложения компаний сконфигурированы таким образом, чтобы принимать свои собственные политики безопасности. Одно из возможных решений состоит в том, чтобы переконфигурировать все финансовые приложения на нужную политику и заново выпустить все сертификаты с другой политикой. Другое решение состоит в использовании поля PolicyMapping. Тогда данное поле должно быть включено в кросс-сертификат.

Расширение PolicyConstraints

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

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