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

В-третьих, для описания множества сертификатов на основании ограничений политик можно использовать дополнение 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

Задачей простой инфраструктуры открытых ключей 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.