Механизм кросс-сертификации может быть использован для расширения доверия между сообществами разных доверяющих сторон. В частности, кросс-сертификация между двумя удостоверяющими центрами - один из старых способов определения данным УЦ прав другого УЦ издавать сертификаты в некотором пространстве имен. Это фундаментальный механизм расширения доверия в модели распределенного доверия, но он равно применим и к web-модели, а также к модели доверия, сконцентрированного вокруг пользователя (где каждый пользователь действует как свой собственный УЦ).
Рис. 5.5. Кросс-сертификация между УЦ1 и УЦ2
Пример 5.4. Предположим, что пользователь А был сертифицирован УЦ1 и владеет доверенной копией открытого ключа УЦ1, а пользователь В был сертифицирован УЦ2 и владеет доверенной копией открытого ключа УЦ2. Изначально пользователь А может доверять только тем субъектам, сертификаты которых были заверены УЦ1, потому что пользователь А способен верифицировать только эти сертификаты. Пользователь А не может верифицировать сертификат пользователя В, так как не владеет доверенной копией открытого ключа УЦ2 ; аналогично - пользователь В не имеет возможности верифицировать сертификат пользователя А. Однако после кросс-сертификации удостоверяющих центров УЦ1 и УЦ2 доверие пользователя А может быть распространено на сообщество субъектов УЦ2, включая пользователя В. Теперь пользователь А может верифицировать сертификат УЦ2, используя свою доверенную копию открытого ключа УЦ1, а затем проверить сертификат пользователя В при помощи своей копии открытого ключа УЦ2.
Кросс-сертификация вносит в концепцию расширения доверия особое преимущество - возможность контроля на базе стандартных дополнений, определенных для кросс-сертификатов: ограничений на имена, политику и длину пути. УЦ1 может кросс-сертифицировать УЦ2, но ограничить некоторым образом сообщество домена УЦ2 (субъекта), которому будет доверять сообщество домена УЦ1 (доверяющей стороны). В определенных целях доверие внутри домена УЦ1 может быть расширено на отдельных индивидуумов или на определенные группы субъектов домена УЦ2. Такое расширение доверия под управлением администратора УЦ1 практически невозможно реализовать в web-модели или модели доверия, сконцентрированного вокруг пользователя.
В частности, используя дополнение сертификата "ограничения на имена", УЦ1 может задать условие принятия сообществом домена УЦ1 в качестве валидных только тех сертификатов, которые выпущены УЦ2 для субъектов определенного сегмента пространства имен. Этот сегмент пространства имен может быть ограничен отдельным пользователем, группой, отделом, целой организацией и т.п. Например, одна компания может использовать этот механизм, чтобы гарантировать принятие в качестве валидных только сертификатов сотрудников отдела закупок другой компании. Дополнение сертификата Policy Constraints (ограничения политики) позволяет управлять назначением сертификатов, например, запрещать их использование для верификации подписи на юридическом контракте.
Ограничения на длину пути в дополнении сертификата Basic Constraints (базовые ограничения) могут использоваться для регулирования количества кросс-сертификатов в валидном пути сертификации. Например, УЦ1 может разрешить принятие сертификатов конечных субъектов, изданных УЦ2, но запретить использование сертификатов, изданных любым другим УЦ, который кросс-сертифицирован с УЦ2.
Итак, кросс-сертификация обеспечивает функциональную совместимость доменов PKI, которые невозможно связать другим образом. В качестве нежелательной альтернативы может выступать обмен ключами между головными удостоверяющими центрами и хранение каждым пользователем открытого ключа головного УЦ внешнего домена.
Лекция 6. Сертификаты открытых ключей
Описывается формат сертификата открытого ключа, дается краткая характеристика обязательных и опциональных полей сертификата, подробно рассматриваются ограничивающие и информационные дополнения сертификата, обсуждаются альтернативные форматы сертификатов, объясняются принципы функционирования простой инфраструктуры открытых ключей, систем PGP и SET, дается представление об атрибутных сертификатах.
Формат сертификатов открытых ключей X.509
Формат сертификата открытого ключа определен в рекомендациях Международного Союза по телекоммуникациям ITU (X.509) [78] и документе RFC 3280 Certificate & CRL Profile [167] организации инженерной поддержки Интернета Internet Engineering Task Force (IETF). IETF является открытым интернациональным сообществом исследователей, разработчиков сетевых протоколов, операторов и производителей, занимающихся проблемами развития сетей Интернет и обеспечением непрерывного функционирования существующей инфраструктуры. В настоящее время основным принятым форматом является формат версии 3, позволяющий задавать дополнения, с помощью которых реализуется определенная политика безопасности в системе. Несмотря на то, что документ RFC 3820 адресован Интернет-сообществу, формат сертификата открытого ключа предоставляет гибкий механизм передачи разнообразной информации и применяется в корпоративных PKI.
Сертификат открытого ключа подписи или шифрования представляет собой структурированную двоичную запись в формате абстрактной синтаксической нотации ASN.1. Сертификат содержит элементы данных, сопровождаемые цифровой подписью издателя сертификата (см. рис. 6.1 и табл. 6.1). В сертификате имеется десять основных полей: шесть обязательных и четыре опциональных. Большая часть информации, указываемой в сертификате, не является обязательной, а содержание обязательных полей сертификата может варьироваться. К обязательным полям относятся:
* серийный номер сертификата Certificate Serial Number ;
* идентификатор алгоритма подписи Signature Algorithm Identifier ;
* имя издателя Issuer Name ;
* период действия Validity (Not Before/After) ;
* открытый ключ субъекта Subject Public Key Information ;
* имя субъекта сертификата Subject Name.
Под субъектом сертификата понимается сторона, которая контролирует секретный ключ, соответствующий данному открытому ключу. Наличие необязательных полей характерно для сертификатов версий 2 и 3, к необязательным полям сертификата относятся номер версии, два уникальных идентификатора и дополнения. Структура сертификата представлена на рис. 6.1.
Поле Version (см. табл. 6.1) задает синтаксис сертификата, по умолчанию предполагается первая версия сертификата. Если в поле версии указывается 2, то сертификат содержит только уникальные идентификаторы, а если 3, то в сертификат включаются и уникальные идентификаторы, и дополнения, что характерно для всех современных сертификатов. Сертификаты первой версии не содержат уникальные идентификаторы или дополнения.
Рис. 6.1. Структура сертификата
Издатель сертификатов присваивает каждому выпускаемому сертификату серийный номер Certificate Serial Number, который должен быть уникален. Комбинация имени издателя и серийного номера однозначно идентифицирует каждый сертификат.
В поле Signature Аlgorithm Identifier указывается идентификатор алгоритма ЭЦП, который использовался издателем сертификата для подписи сертификата, например ГОСТ Р 34.10-94 (см. рис. 6.2).
Рис. 6.2. Пример сертификата формата X.509
Поле Issuer Name содержит отличительное имя (формата X.500) третьей доверенной стороны, то есть издателя, который выпустил этот сертификат. В поле Validity (Not Before/After) указываются даты начала и окончания периода действия сертификата.
Поле Subject Name содержит отличительное имя субъекта, то есть владельца секретного ключа, соответствующего открытому ключу данного сертификата. Субъектом сертификата может выступать УЦ, РЦ или конечный субъект.
