Фактом выпуска сертификата УЦ подтверждает пользователю сертификата (доверяющей стороне), что данный открытый ключ принадлежит данному лицу (субъекту сертификата). Степень доверия, с которой пользователю сертификата следует полагаться на его надежность, зависит от назначения сертификата, декларируемого политикой, и возможности его использования в конкретном приложении.
ППС не содержит подробного описания того, как реализуется политика безопасности. Например, ППС может содержать следующее положение: "Каждый подписчик должен лично пройти процедуру идентификации в РЦ, прежде чем для него будет выпущен сертификат", не конкретизируя процедуру регистрации. ППС является долговременным документом и не описывает операции детально, поэтому с течением времени они могут меняться, а политика по-прежнему останется актуальной (на протяжении десяти лет и более).
ППС может описывать операционную работу отдельного УЦ - это в основном касается центра, входящего в состав PKI одной организации или обслуживающего одно сообщество пользователей в рамках сетевой PKI. Часто подобные удостоверяющие центры придерживаются единственной политики. Кроме того, сферой применения ППС могут быть операции иерархической PKI. Если УЦ не является пунктом доверия в рассматриваемой иерархии, то недостаточно охарактеризовать политику только этого центра - ППС должна описывать операции головного УЦ и всех центров, которые выпускают сертификаты в соответствии с этой политикой. Нельзя исключать и вариант, когда разные иерархические PKI одной отрасли реализуют одну и ту же стандартную политику, разработанную одним УЦ.
Документ ППС адресован широкому кругу лиц. Прежде всего, им пользуются разработчики регламента УЦ, который функционирует в соответствии с данной политикой. Руководители других удостоверяющих центров изучают ППС данного УЦ, прежде чем принять решение о кросс-сертификации. Аудиторы и лица, принимающие решение об аккредитации данного УЦ, пользуются ППС для проверки операционной работы центра. Пользователи и доверяющие стороны обращаются к ППС, чтобы определить пригодность сертификатов УЦ для защиты их приложений.
Приведем примеры политик применения сертификатов. Пусть, например, авиакомпания IATA, сотрудничающая с другими авиакомпаниями-партнерами, желает выработать две политики применения сертификатов для PKI в авиационной индустрии: политику общего назначения и политику коммерческого назначения [152]. Политика общего назначения формируется для персонала компании IATA с целью защиты обычной информации (например, электронной почты) и аутентификации соединений web-браузеров с серверами для поиска информации общего характера. В этом случае сертификаты могут выпускаться автоматически для любого лица, указанного в списке корпоративного каталога авиакомпании IATA, или служащего авиакомпании-партнера, обратившегося к сетевому администратору своей организации с подписанным запросом на сертификат. Генерация, хранение и управление парами ключей могут осуществляться посредством браузеров.
Политика коммерческого назначения разрабатывается для защиты финансовых транзакций или коммуникаций с авиакомпаниями-партнерами и предусматривает использование аппаратных криптографических ключей. Сертификаты и аппаратные ключи выдаются только уполномоченным служащим авиакомпаний после прохождения ими проверки корпоративной службой безопасности и подписания обязательств защищенно хранить и правильно использовать аппаратные ключи.
Концепции политики применения сертификатов и регламента имеют разное происхождение и разрабатывались по разным причинам, но их связь чрезвычайно важна. Более детальное описание практической работы УЦ при выпуске и управлении сертификатами содержится в публикуемом им регламенте.
Регламент удостоверяющего центра
Термин регламент удостоверяющего центра (Certification Practice Statement - CPS) был введен в 1995 году в проекте директив Американской ассоциации юристов (American Bar Association) как "заявление о практике выпуска сертификатов удостоверяющим центром". Регламент подробно описывает систему и практику работы УЦ с сертификатами. В регламенте могут фиксироваться положения договора между УЦ и подписчиками. Регламент четко формулирует обязанности УЦ перед доверяющей стороной. Лицо, полагающееся на сертификат при проверке цифровой подписи, должно знать или получать информацию о содержании сертификата. Этим обусловлено требование включения в сертификат ссылки на регламент УЦ, выпустившего данный сертификат. Регламент должен отражать соответствие практики УЦ общепризнанным стандартам: только в этом случае может быть оценена пригодность и принципиальная совместимость сертификатов, выпущенных УЦ, с другими системами применения сертификатов.
Регламент - это очень подробный документ, детально описывающий, как УЦ реализует конкретную ППС, и все то, что потенциально необходимо для понимания и принятия во внимание подписчиками и пользователями сертификатов (доверяющими сторонами). Регламент идентифицирует ППС и задает механизмы (например, используемые программные и аппаратные средства PKI) и процедуры, обеспечивающие политику безопасности. Любой регламент, независимо от его уровня детализации, всегда более подробен, чем описание ППС, например, он может содержать следующее положение: "Пользователи получают свои сертификаты и смарт-карты в РЦ после личного предъявления документов, удостоверяющих личность, например, паспорта или водительских прав". Регламент достаточно подробно характеризует ППС, чтобы продемонстрировать, что безопасность полностью обеспечивается перечисленными механизмами и процедурами.
Регламент должен быть совершенно понятным, четким документом, описывающим сервисы УЦ и процедуры управления жизненным циклом сертификатов. Регламент необходим для адекватной оценки надежности УЦ, но он не создает основу совместимости удостоверяющих центров, управляемых разными организациями. Таким базисом служат политики применения сертификатов.
Каждый УЦ имеет свой регламент. В состав крупномасштабной PKI могут входить несколько удостоверяющих центров с одинаковыми функциями. В этом случае содержание регламентов может полностью совпадать, за исключением информации о местонахождении каждого УЦ и контактах с ним. Регламент можно рассматривать как руководство по операционной работе УЦ. Некоторые части регламента могут использоваться для написания руководств для регистрационных центров, пользователей и аудиторов PKI. Аудиторы и лица, принимающие решение об аккредитации данного УЦ, помимо ознакомления с ППС могут обращаться к регламенту для оценки операционной работы центра. Отметим, однако, что требование открыто публиковать регламент не является обязательным, для внешних сторон должно быть достаточно ППС и свидетельства об аккредитации УЦ.
УЦ на базе одного регламента может поддерживать несколько политик применения сертификатов, предназначенных для разных приложений или сообществ пользователей сертификатов. Многие удостоверяющие центры с разными регламентами могут поддерживать одну и ту же ППС. Например, если федеральное правительство определяет ППС для управления конфиденциальной информацией о кадрах, то описанием политики будет служить подробное изложение ее общих характеристик и перечисление типов приложений, для которых она пригодна. Разные департаменты или агентства, управляющие удостоверяющими центрами с разными регламентами, должны поддерживать политику федерального уровня, но могут поддерживать наряду с ней и другие политики применения сертификатов.
Любой УЦ, используя спецификатор политики, может включить в выпускаемый им сертификат ссылку на свой регламент. ППС должна описывать все области применения сертификатов данного УЦ, в то время как регламент УЦ может разрабатываться без учета назначения сертификатов. Таблица 13.1 позволяет сравнить формулировки политики применения сертификатов, регламента и организационных процедур, описывающие одно и то же положение политики PKI: защищенность аппаратных средств УЦ. Регламент и политика применения сертификатов содержат достаточно общую информацию и публикуются открыто, а организационные процедуры носят конфиденциальный характер и поэтому должны оставаться секретными. Обычно регламент и политика имеют одинаковый формат публикации, установленный стандартом RFC 2527 [76], и взаимно дополняют друг друга.
