Формат сертификатов открытых ключей X.509
Формат сертификата открытого ключа определен в рекомендациях Международного Союза по телекоммуникациям ITU (X.509) и документе RFC 3280 Certificate & CRL Profile организации инженерной поддержки Интернета Internet Engineering Task Force (IETF). IETF является открытым интернациональным сообществом исследователей, разработчиков сетевых протоколов, операторов и производителей, занимающихся проблемами развития сетей Интернет и обеспечением непрерывного функционирования существующей инфраструктуры. В настоящее время основным принятым форматом является формат версии 3, позволяющий задавать дополнения, с помощью которых реализуется определенная политика безопасности в системе. Несмотря на то, что документ RFC 3820 адресован Интернет-сообществу, формат сертификата открытого ключа предоставляет гибкий механизм передачи разнообразной информации и применяется в корпоративных PKI.
Сертификат открытого ключа подписи или шифрования представляет собой структурированную двоичную запись в формате абстрактной синтаксической нотации ASN.1. Сертификат содержит элементы данных, сопровождаемые цифровой подписью издателя сертификата (см. и ). В сертификате имеется десять основных полей: шесть обязательных и четыре опциональных. Большая часть информации, указываемой в сертификате, не является обязательной, а содержание обязательных полей сертификата может варьироваться. К обязательным полям относятся:
* серийный номер сертификата Certificate Serial Number ;
* идентификатор алгоритма подписи Signature Algorithm Identifier ;
* имя издателя Issuer Name ;
* период действия Validity (Not Before/After) ;
* открытый ключ субъекта Subject Public Key Information ;
* имя субъекта сертификата Subject Name.
Под субъектом сертификата понимается сторона, которая контролирует секретный ключ, соответствующий данному открытому ключу. Наличие необязательных полей характерно для сертификатов версий 2 и 3, к необязательным полям сертификата относятся номер версии, два уникальных идентификатора и дополнения. Структура сертификата представлена на .
Поле Version () задает синтаксис сертификата, по умолчанию предполагается первая версия сертификата. Если в поле версии указывается 2, то сертификат содержит только уникальные идентификаторы, а если 3, то в сертификат включаются и уникальные идентификаторы, и дополнения, что характерно для всех современных сертификатов. Сертификаты первой версии не содержат уникальные идентификаторы или дополнения.
Рис. 6.1. Структура сертификата
Издатель сертификатов присваивает каждому выпускаемому сертификату серийный номер Certificate Serial Number, который должен быть уникален. Комбинация имени издателя и серийного номера однозначно идентифицирует каждый сертификат.
В поле Signature Аlgorithm Identifier указывается идентификатор алгоритма ЭЦП, который использовался издателем сертификата для подписи сертификата, например ГОСТ Р 34.10-94 ().
Рис. 6.2. Пример сертификата формата X.509
Поле Issuer Name содержит отличительное имя (формата X.500) третьей доверенной стороны, то есть издателя, который выпустил этот сертификат. В поле Validity (Not Before/After) указываются даты начала и окончания периода действия сертификата.
Поле Subject Name содержит отличительное имя субъекта, то есть владельца секретного ключа, соответствующего открытому ключу данного сертификата. Субъектом сертификата может выступать УЦ, РЦ или конечный субъект.
|Версия v1 | Элемент | Название | Описание |
|version | Версия | Версия (0 означает v1, 2 означает v3) |
|serialNumber | Серийный номер сертификата | Серийный номер сертификата |
|signature.algorithm
Identifier
algorithm
parameters
| Идентификатор алгоритма подписи | Тип алгоритма подписи
.
Алгоритм
Параметры
|
|issuer | Издатель | Уникальное название УЦ, выпустившего сертификат |
|Validity
NotBefore
notAfter
| Период действия | Период действия
Дата и время начала действия
Дата и время окончания действия
|
|subject | Субъект | Уникальное имя субъекта |
|SubjectPublicKeyInfo
Algorithm
subjectPublicKey
| Информация об открытом ключе субъекта | Информация об открытом ключе субъекта
Криптографический алгоритм
Ключ (строка битов)
|
|Версия v2 | issuerUniqueID | Уникальный идентификатор издателя | Уникальный идентификатор УЦ, выпустившего сертификат |
|subjectUniqueID | Уникальный идентификатор субъекта | Уникальный идентификатор субъекта сертификата |
|AuthorityKeyIdentifier
keyIdentifier
authorityCertIssuer
authorityCertSerialNumber
| Идентификатор ключа УЦ | Идентификатор ключа УЦ
Идентификатор ключа
Общее название УЦ
Серийный номер сертификата УЦ
|
|subjectKeyIdentifier | Идентификатор ключа субъекта | Идентификатор, используемый тогда, когда субъект имеет более одного ключа (например, во время возобновления сертификата) |
|Версия v3 | keyUsage
digitalSignature
.
nonRepudiation
keyEncipherment
dataEncipherment
.
.
.
keyAgreement
.
.
KeyCertSign
.
.
CRLSign
| Назначение ключа | Назначение ключа (строки битов)
1. Формирование и проверка
цифровой подписи
2. Неотказуемость
3. Шифрование других ключей
4. Шифрование и расшифрова-
ние данных и контроль цело-
стности с использованием
имитозащиты
5. Формирование других ключей
(например, по алгоритму
Диффи-Хелмана)
6. Формирование ЭЦП серти-
фикатов. Может использо-
ваться УЦ
7. Формирование ЭЦП САС.
Может использоваться УЦ
|
|keyUsage
EncipherOnly
DecipherOnly
| Назначение ключа | Назначение ключа (строки битов)
8. Только для шифрования
9. Только для расшифрования
|
|extendedKeyUsage | Расширенное назначение ключа | Задает одно или несколько назначений ключа помимо или вместо дополнения keyUsage |
|cRLDistributionPoint | Пункт распространения списков аннулированных сертификатов | Задает унифицированный идентификатор ресурса (URL) для указания местонахождения списков САС |
|privateKeyUsagePeriod | Период действия секретного ключа | Период действия секретного ключа, соответствующего открытому ключу в данном сертификате. При отсутствии этого дополнения периоды действия секретного и открытого ключей совпадают |
|certificatePolicies | Политики применения сертификат | Содержит уникальный идентификатор объекта OID, характеризующий политику применения сертификата и назначение сертификата |
|PolicyMappings
IssuerDomainPolicy
SubjectDomainPolicy
| Соответствие политик | Используется только в сертификатах УЦ. Задает один или несколько идентификаторов объекта в составе домена УЦ издателя, которые должны совпадать с политикой в составе домена УЦ субъекта |
|BasicConstraints | Основные ограничения | Указывает, действует ли субъект как УЦ, задает длину пути сертификации |
|PolicyConstraints | Ограничение политик | Используется только в сертификатах УЦ, задает проверку пути к политике, запрашивая идентификаторы политик и (или) запрещая задание соответствий политик |
|NameConstraints | Ограничения на имена | Используется только в сертификатах УЦ, задает пространство имен, которому должны принадлежать имена субъектов любого следующего сертификата в пути сертификации |
|SubjectAltName
.
OtherName
rfc822Name
dNSName
x400Address
directoryName
ediPartyName
uniformResource-
Identifier
iPAddress
registeredID
| Альтернативное имя субъекта | Альтернативное имя субъекта.
Свободный выбор имени.
Произвольное имя
Адрес электронной почты
Имя домена
Адрес отправителя/получателя
Имя каталога
EDI-имя
Унифицированный указатель
ресурсов WWW URL
IP-адрес
Зарегистрированный ID объекта
|
|issuerAltName | Альтернативное имя издателя | Альтернативное имя издателя |
|SubjectDirectory Attributes | Атрибуты каталога субъекта | Необязательные атрибуты субъекта, например, почтовый адрес, номер телефона и т.п. |
Таблица 6.1.Формат сертификата X.509
Поле Subject Public Key Information содержит информацию об открытом ключе субъекта: сам открытый ключ, необязательные параметры и идентификатор алгоритма генерации ключа. Это поле всегда должно содержать значение. Открытый ключ и необязательные параметры алгоритма используются для верификации цифровой подписи (если субъектом сертификата является УЦ) или управления ключами.
Необязательные поля Issuer Unique Identifier и Subject Unique Identifier информируют об уникальных идентификаторах субъекта и издателя сертификата и предназначены для управления многократным использованием имен субъектов и издателей. Вследствие неэффективности подобного механизма управления Интернет-стандарты профилей сертификата и списка аннулированных сертификатов не рекомендуют использовать в сертификатах эти поля.
Дополнения сертификата
Важная информация находится также в дополнениях сертификата. Они позволяют включать в сертификат информацию, которая отсутствует в основном содержании, определять валидность сертификата и наличие у владельца сертификата прав доступа к той или иной системе. Кроме того, в дополнениях содержится технологическая информация, позволяющая легко проверить подлинность сертификата. Каждая организация может использовать свои частные дополнения, удовлетворяющие конкретным требованиям ведения бизнеса. Однако большинство требований включено в стандартные дополнения, поддержку которых обеспечивают коммерческие программные продукты.
Опциональное поле Extensions (дополнения) появляется в сертификатах третьей версии. Каждое дополнение состоит из идентификатора типа дополнения Extension identifier, признака критичности Criticality flag и собственно значения дополнения Extension value. Идентификатор типа дополнения задает формат и семантику значения дополнения. Признак критичности сообщает приложению, использующему данный сертификат, существенна ли информация о назначении сертификата и может ли приложение игнорировать данный тип дополнения. Если дополнение задано как критичное, а приложение не распознает данный тип дополнения, то сертификат не должен использоваться приложением. Приложение может игнорировать нераспознанное некритичное дополнение и использовать сертификат.
Дополнения сертификатов X.509 определены рекомендациями Х.509 версии 3 Международного Союза по телекоммуникациям и документом RFC 3280 . Все эти дополнения можно разделить на две категории: ограничивающие и информационные . Первые ограничивают область применения ключа, определенного сертификатом, или самого сертификата. Вторые содержат дополнительную информацию, которая может быть использована в прикладном программном обеспечении пользователем сертификата. К ограничивающим дополнениям относятся:
* основные ограничения ( Basic Constraints );
* назначение ключа ( Key Usage );
* расширенное назначение ключа ( Extended Key Usage );
* политики применения сертификата ( Certificates Policies, Policy Mappings, Policy Constraints );
* ограничения на имена ( Name Constraints ).
К информационным дополнениям относятся:
* идентификаторы ключей ( Subject Key Identifier, Authority Key Identifier );
* альтернативные имена ( Subject Alternative Name, Issuer Alternative Name );
* пункт распространения списка аннулированных сертификатов ( CRL Distribution Point, Issuing Distribution Point );
* способ доступа к информации УЦ ( Authority Access Info ).
Документ RFC 3280 Certificate & CRL Profile пока не рекомендует использовать дополнение Subject Directory Attributes, которое предназначено для доставки любых значений атрибутов каталога X.500, характеризующих субъект данного сертификата. Вместе с этим стандарт X.509 позволяет вводить любые другие дополнения, необходимость которых определяется их использованием в конкретной системе (например, в системе SET ).
Субъектом сертификата может быть конечный пользователь, система или УЦ. Основные поля сертификата одинаковы для всех субъектов. Различать субъекты сертификатов и оценивать возможность построения пути сертификации позволяет дополнение Basic Constraints (основные ограничения), используемое только для удостоверяющих центров.
Дополнение Key Usage (назначение ключа) отражает области применения секретного ключа, соответствующего указанному в сертификате открытому ключу. В одноименной графе () перечислены возможные области применения ключа.
Дополнение Subject Alternative Name (альтернативное имя субъекта) позволяет расширить границы идентификации владельца сертификата при помощи альтернативных имен, таких как DNS-имена, IP-адреса, URI-адреса или адреса электронной почты Интернета. Альтернативное имя должно проверяться в соответствии с регламентом УЦ. Помимо зарегистрированных типов имен УЦ может использовать свои собственные имена, задавая их в поле Other Name. Аналогичная информация содержится и в дополнении Issuer Alternative Name, характеризующем издателя сертификата. Удостоверяющие центры могут иметь много пар ключей, и дополнение Authority Key Identifier (идентификатор ключа УЦ) помогает пользователям выбрать правильный ключ для верификации подписи на сертификате.
Пользователи также могут владеть несколькими парами ключей или несколькими сертификатами для одного и того же ключа. Дополнение Subject Key Identifier (идентификатор ключа субъекта) используется для того, чтобы различать ключи подписи в сертификатах одного и того же владельца.
Дополнение CRL Distribution Point (пункт распространения САС) задает унифицированный идентификатор ресурса (Uniform Resource Identifier - URI) для указания местонахождения списка аннулированных сертификатов, то есть определяет пункт распространения САС.
Организации могут поддерживать широкий круг приложений, использующих PKI. Некоторые сертификаты бывают надежнее других в зависимости от процедур их выпуска или типов криптографических модулей пользователей. Различные организации (компании или правительственные агентства) используют разные политики применения сертификатов, пользователи при этом не всегда способны их различить, но при принятии решения могут ориентироваться на дополнение Certificate Policies (политики применения сертификата). Это дополнение содержит абсолютно уникальный идентификатор объекта (Object Identifier - OID), характеризующий политику применения сертификатов, в соответствии с которой был выпущен данный сертификат, и назначение сертификата. Признак критичности в поле Certificate Policies ограничивает использование сертификата одной из идентифицируемых политик - тем самым УЦ декларирует, что выпущенный им сертификат должен применяться в соответствии с положениями одной из указанных в списке политик. Это может защитить УЦ от материальных претензий доверяющей стороны, которая использовала сертификат не по тому назначению или не тем способом, которые установлены политикой применения сертификатов, указанной в сертификате.
Пусть, например, служба департамента налогов и сборов должна выпустить сертификаты для налогоплательщиков с целью защиты информации о налоговых отчислениях. Очевидно, что эта служба осознает и стремится минимизировать риск случайного выпуска сертификата для плохо аутентифицированного лица, так как в случае ошибки при выпуске сертификата и использования его злоумышленником может быть причинен значительный материальный ущерб. Считается, что пометка дополнения Certificate Policies признаком критичности позволяет издателю сертификата уменьшить риск при таких обстоятельствах и защитить себя от претензий по возмещению ущерба. Кроме того, в поле дополнения Certificate Policies можно указывать значения спецификаторов каждой идентифицируемой политики применения сертификатов.
Дополнение Policy Mappings (соответствие политик) используется, если субъектом сертификата является УЦ. С помощью этого дополнения можно устанавливать соответствие между политиками применения сертификатов разных удостоверяющих центров.
Пример 6.1. Пусть корпорация ACE заключает соглашение с корпорацией ABC о кросс-сертификации с целью защиты электронного обмена данными . Каждая компания имеет свою политику безопасности финансовых транзакций. Очевидно, что просто генерация кросс-сертификатов не обеспечит необходимой функциональной совместимости, так как в каждой компании конфигурирование финансовых приложений и выпуск сертификатов для служащих осуществляются согласно собственной политике. Одно из возможных решений - переконфигурирование всех финансовых приложений и повторный выпуск всех сертификатов в соответствии с требованиями обеих политик. Другим, более простым решением может быть использование дополнения Policy Mappings. Если поле этого дополнения включает кросс-сертификат, выпущенный УЦ компании ACE для УЦ компании ABC, то политика безопасности финансовых транзакций компании ABC считается эквивалентной одноименной политике компании ACE.
Выпуск сертификата одним УЦ для другого является подтверждением надежности сертификатов последнего. Существует три основных способа подтвердить надежность некоторого множества сертификатов. Во-первых, это можно сделать при помощи дополнения Basic Constraints (описанного выше). Второй способ состоит в описании множества сертификатов на основании имен, указанных в поле имени субъекта или альтернативного имени субъекта, в дополнении Name Constraints (ограничения на имена). Это дополнение может использоваться для задания множества допустимых имен или множества неразрешенных имен.
В-третьих, для описания множества сертификатов на основании ограничений политик можно использовать дополнение Policy Constraints (ограничения политик). Это дополнение используется только в сертификатах УЦ и задает проверку пути к политике, запрашивая идентификаторы политик и (или) запрещая задание соответствия политик . Если УЦ выдает универсально надежные сертификаты, то нет необходимости явно указывать в них политики применения сертификатов. Если же сертификаты УЦ, признанного надежным в определенном домене, используются вне этого домена, то требуется явное указание политики применения во всех сертификатах пути сертификации. При помощи дополнения 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 - это авторизация некоторых действий, выдача разрешений, предоставление возможностей и т.п. владельцу ключа . Сертификаты SPKI часто называют сертификатами авторизации. Сертификаты авторизации, по замыслу авторов идеи SPKI, должны генерироваться любым владельцем ключа, которому разрешено предоставлять или делегировать полномочия. Владелец ключа непосредственно идентифицируется своим открытым ключом, хотя для ряда целей допускается применение некоторых других идентификаторов. Это может быть значение хэш-кода открытого ключа или некоторое имя, которое тем не менее всегда связано с ключом. В связи с тем, что сертификаты SPKI могут содержать информацию, которую владелец ключа не желает публиковать, допускается распространение сертификатов самим владельцем. Владелец ключа может использовать глобальное хранилище, например LDAP, сервер ключей PGP или систему доменных имен DNS.
Поскольку сертификаты SPKI содержат информацию, ознакомление с которой может представлять угрозу безопасности и приватности, объем информации, подтверждающей полномочия владельца, должен быть сведен к необходимому минимуму в зависимости от назначения сертификата. В тех случаях, когда требуется анонимность некоторых сертификатов (например, в секретном голосовании и аналогичных приложениях), сертификаты SPKI должны уметь присваивать атрибут ключу обезличенной подписи. Одним из атрибутов владельца ключа является его имя. У одного владельца ключа может быть несколько имен: те, которыми владелец предпочитает называться, и те, под которыми он известен другим владельцам ключей. Сертификат SPKI должен обеспечивать связывание ключей с такими именами.
Сертификат SPKI, как и всякий другой, имеет период действия.Проверка валидности сертификатов в простой инфраструктуре открытых ключей осуществляется при помощи списка аннулированных сертификатов (САС). Минимальный САС содержит перечень уникально идентифицированных аннулированных сертификатов, номер данного списка в последовательности публикуемых САС и подпись. Так как в SPKI явным образом не задается способ передачи САС, основным требованием является точное указание в сертификате открытого ключа информации о местонахождении САС. SPKI должна поддерживать проверку валидности сертификатов в онлайновом режиме.
Хотя SPKI-сертификаты имеют много общего с сертификатами открытых ключей X.509 (например, поля Issuer и Validity ), синтаксис и семантика этих полей неодинаковы. Кроме того, количество полей в сертификатах этих двух типов не позволяет их эквивалентно отображать друг на друга, а соглашения об именах отличаются полностью.
Работа группы IETF SPKI над документами простой инфраструктуры открытых ключей завершена, однако на практике эта работа в полном объеме не реализована. В настоящее время спрос на SPKI-сертификаты очень невелик, поэтому поставщики программных продуктов для УЦ и PKI не спешат реализовывать совершенно другой синтаксис сертификата в дополнение к сертификатам открытых ключей X.509 v3.
Сертификаты PGP
Система PGP (Pretty Good Privacy) разработана американским программистом Филиппом Циммерманном для защиты секретности файлов и сообщений электронной почты в глобальных вычислительных и коммуникационных средах. Ф. Циммерманн предложил первую версию PGP в начале 1990-х годов . Версия 2.x PGP была опубликована несколькими годами позже в спецификации набора стандартов IETF, названной PGP Message Exchange Formats . Последняя версия PGP, получившая название Open PGP, была издана в спецификации набора стандартов IETF - Open PGP Message Format . Документ, относящийся к Интернет-стандартам, объединяет PGP и MIME и называется PGP MIME Security with Pretty Good Privacy .
PGP представляет собой гибридную систему, комплексно использующую преимущества асимметричных и симметричных криптографических алгоритмов. С точки зрения пользователя, PGP ведет себя как система с открытым ключом. Она обеспечивает безопасный обмен сообщениями и файлами по каналам открытой связи без наличия защищенного канала для обмена ключами . PGP позволяет шифровать, заверять электронной цифровой подписью, расшифровывать и проверять сообщения во время отправки и чтения электронной почты. В PGP применяются стойкие криптографические алгоритмы CAST, тройной DES и IDEA. Для выработки сеансового ключа используются алгоритмы RSA и Диффи-Хеллмана, для подписи - RSA и DSA. PGP задает форматы пакетов, позволяющие пересылать от одного субъекта к другому сообщения и файлы, а также PGP-ключи (иногда называемые PGP-сертификатами).
Перед работой в системе PGP пользователю необходимо сгенерировать открытый и секретный ключи. Открытый ключ может быть передан абоненту как сообщение электронной почты, как файл или помещен на сервер открытых ключей. Получив копию чьего-либо открытого ключа, пользователь может добавить его на свою связку открытых ключей. Убедиться в том, что ключ не был подделан, можно, сравнивая уникальный отпечаток своей копии ключа с отпечатком оригинальной копии. Отпечаток - это строка из цифр и букв, уникальным образом идентифицирующая владельца ключа. После проверки валидности ключа пользователь подписывает его, подтверждая системе PGP безопасность его использования. При этом пользователь может указать степень доверия, которую он испытывает к владельцу ключа, в смысле его способности ручаться за подлинность ключей третьих лиц. Степень доверия к способности владельца ключа выступать в качестве посредника отражает оценку не только его персональной порядочности, но и компетентности в понимании механизма управления ключами и склонности руководствоваться здравым рассудком при принятии решения о сертификации ключа третьего лица. Пользователь может обозначить лицо как пользующееся полным доверием, ограниченным доверием или не пользующееся доверием. Эта информация о степени доверия к конкретному владельцу ключа хранится на связке вместе с соответствующими ключами, но при экспорте ключа из связки она не передается, так как считается конфиденциальной.
При оценке валидности открытого ключа в системе PGP проверяется уровень доверия, приданный пользователем всем подписям, которыми он сертифицирован. Система вычисляет взвешенное значение валидности, при этом две подписи лиц, пользующихся ограниченным доверием, приравниваются к подписи одного лица, пользующегося полным доверием. Ключи, сертифицированные посредниками, которым доверяет пользователь, PGP считает валидными. Ключи, принадлежащие этим посредникам, сами должны быть сертифицированы пользователем или другими посредниками, которым пользователь доверяет. Таким образом, формируется сеть поручительства участников системы PGP за достоверность распространяемых ключей, так называемая сеть доверия. Предоставление всем пользователям возможности действовать в качестве посредников считается целесообразным для децентрализованных сред.
PGP поддерживает, в качестве частного случая своей обобщенной модели распределенного доверия, централизованный сценарий, когда сертификаты открытых ключей пользователей заверяет своей подписью лицо, пользующееся общим доверием - УЦ . Любому открытому ключу, заверенному подписью УЦ, можно доверять в том смысле, что он принадлежит тому, чье имя он несет. Все пользователи должны обладать копией открытого ключа УЦ для проверки его цифровой подписи. PGP обеспечивает интегрированную поддержку распространения и поиска открытых ключей на серверах ключей. Единый УЦ особенно подходит для больших централизованно управляемых организаций, правительственных или корпоративных. Некоторые организационные среды используют иерархию удостоверяющих центров, которая лежит в основе стандартной схемы, основанной на централизованном контроле и принудительно централизованном доверии. Иерархия удостоверяющих центров обычно диктует пользователю, кому он должен доверять. Децентрализованный вероятностный метод определения валидности ключей, реализованный PGP, позволяет пользователю самостоятельно принимать решение о доверии, строя свою собственную пирамиду сертификации.
Между PGP-ключами (или сертификатами) и сертификатами открытых ключей X.509, а также между соответствующими моделями доверия имеются существенные отличия, препятствующие взаимодействию сообщества пользователей PGP с другими сообществами, которые используют сертификаты формата X.509 (например, сообществом пользователей S/MIME). Это намного серьезнее, чем проблема несовместимости протоколов, потому что непохожа и несовместима основа базовых сервисов безопасности, обеспечиваемых открытыми ключами. Возможным решением может быть адаптация сертификатов X.509 v3 в дополнение к PGP-сертификату (или вместо него). Версия Open PGP 6.5. способна поддерживать сертификаты X.509, но, позволяя пользователям Open PGP подключаться к PKI на базе X.509, она не решает проблему несовместимости основных протоколов Open PGP и S/MIME. Другим возможным решением может быть разработка продуктов, поддерживающих сертификаты и PGP и X.509 v3, но это из-за существенных различий в моделях доверия усложнит администрирование и управление.
Сертификаты SET
Протокол SET, который базируется на техническом стандарте, разработанном компаниями VISA и Master Card, обеспечивает безопасность электронных расчетов по пластиковым картам через Интернет: гарантирует конфиденциальность и целостность информации о платежах, аутентификацию счета владельца карты и дает возможность подтвердить право коммерсанта (продавца) проводить финансовые операции с финансовым учреждением . В среде SET инфраструктура открытых ключей является фундаментом, на котором базируется вся система аутентификации участников расчетов.
Цифровые сертификаты, также известные как электронные мандаты или цифровые удостоверения личности, используются для связывания открытых ключей и субъектов и выпускаются доверенной третьей стороной или компанией - УЦ. Сертификаты владельцев карт выдаются только с разрешения финансового учреждения - эмитента этих карт, снабжаются его цифровой подписью и не могут быть изменены третьей стороной. Сертификаты содержат данные о номере счета и периоде действия, которые шифруются с использованием известного алгоритма шифрования с секретным ключом - Data Encryption Standard (DES). Запрашивая сертификат, владелец карты сообщает о своем намерении стать участником электронной торговли. Эти сертификаты передаются продавцам вместе с запросами о покупке и платежными инструкциями.
Сертификаты продавцов снабжаются цифровыми подписями их финансовых учреждений, открывающих счета продавцов и обрабатывающих авторизации и платежи по картам. Эти финансовые учреждения являются получателями платежей, переводимых посредством системы межбанковских расчетов. Чтобы участвовать в системе SET, и получатели платежей, и эмитенты карт также должны иметь сертификаты от каждой ассоциации платежных карт. Сертификаты SET проверяются в иерархии доверия. Каждый сертификат связан с сертификатом подписи того субъекта, который снабдил его цифровой подписью. Следуя по цепочке доверия до известной доверенной стороны - головного УЦ, - можно убедиться в валидности сертификата.
Конфиденциальность и целостность сообщений, которыми обмениваются участники системы защищенных электронных транзакций, обеспечивается механизмом двойных подписей. Содержание каждого сообщения шифруется при помощи случайно сгенерированного симметричного ключа шифрования. Этот ключ, в свою очередь, шифруется с использованием открытого ключа получателя сообщения. Созданный в результате последней операции так называемый цифровой конверт отправляется получателю вместе с зашифрованным сообщением. После получения цифрового конверта получатель расшифровывает его при помощи своего секретного ключа, чтобы получить случайно сгенерированный симметричный ключ для расшифровки исходного сообщения отправителя. Протокол SET предоставляет участникам сервис аутентификации на базе сертификатов формата X.509 и имеет средства аннулирования, реализованные с помощью списка аннулированных сертификатов. Спецификации SET , и задают стандарт поддержки платежей по кредитным картам в распределенных сетях. SET адаптирует формат сертификата открытого ключа X.509 и задает свои собственные специфические дополнения, которые поддерживаются только в SET-совместимых системах . SET также предъявляет определенные требования профиля к стандартным дополнениям. Ниже иллюстрируется структуру сертификата SET.
|Версия |
|Серийный номер |
|Идентификатор алгоритма подписи |
|Имя издателя |
|Период действия (не ранее/не позднее) |
|Имя субъекта |
|ИНформация об открытом ключе субъекта |
|Уникальный идентификатор издателя |
|Уникальный идентификатор субъекта |
|Дополнения |
Структура сертификата SET
|Стандартные дополнения | Специфические SET-дополнения |
|Идентификатор ключа УЦ | Тип сертификата |
|Назначение ключа | Данные продавца |
|.... | Сертификат карты |
|Туннелирование |
|Спецификатор SET |
Отметим, что на вышеуказанной схеме представлены не все возможные дополнения. Поскольку не-SET-приложения не понимают частные дополнения, задаваемые SET, нельзя ожидать, что не-SET-приложение (например, электронная почта на базе S/MIME) примет к использованию сертификат SET. Это действительно так, хотя формат сертификата SET согласуется с форматом сертификата X.509 v3. Дополнение Тип сертификата является критическим, следовательно, не-SET-приложение должно отвергать SET -сертификат. Пометка определенных дополнений как критических является общепринятой практикой для того, чтобы определенный тип сертификата мог использоваться только в контексте данного приложения. Этот пример характеризует ситуацию, когда конечному пользователю требуется несколько сертификатов.
Атрибутные сертификаты
Обычно предполагается, что связывание открытого ключа и субъекта при помощи сертификата должно быть долговременным. Большинство сертификатов открытых ключей подписи конечных субъектов имеют срок действия один или два года. Сертификаты могут использоваться для аутентификации пользователей, и информация, идентифицирующая субъекта, может учитываться при принятии решения об управлении доступом. Однако во многих случаях сведения о субъекте, содержащиеся в сертификате открытого ключа, не являются критерием принятия решения о его правах доступа, которые зависят от роли субъекта, категории допуска, принадлежности к некоторой группе или платежеспособности.
Информация для авторизации часто имеет меньший срок действия, чем сертификат открытого ключа. Она могла бы указываться в дополнениях сертификата открытого ключа, но это не является выходом по двум причинам. Во-первых, подобный сертификат должен аннулироваться при любых изменениях информации для авторизации. Во-вторых, УЦ, выпускающий данный сертификат, не имеет полномочия подписывать эту информацию, а должен связываться с источником информации о правах доступа конкретного пользователя.
Атрибутный сертификат X.509 связывает атрибуты прав доступа с владельцем сертификата и предназначен для использования в Интернет приложениях . Поскольку атрибутный сертификат не содержит открытого ключа, то его используют вместе с сертификатом открытого ключа. Аутентификация субъекта осуществляется при помощи сертификата открытого ключа, а связывание атрибутов с данным субъектом - посредством атрибутного сертификата.
Атрибутные сертификаты могут применяться в сервисах аутентификации источника данных и неотказуемости. В этом случае в сертификаты включают дополнительную информацию о субъекте, который ставит цифровую подпись. Эта информация позволяет удостовериться, что субъект имеет право подписывать данные. Род проверки зависит от содержания данных, которыми обмениваются стороны или которые должны быть заверены цифровой подписью.
Атрибутный сертификат X.509 напоминает сертификат открытого ключа этого же формата, но имеет другие функциональные возможности. Он представляет собой структурированную двоичную запись формата ASN.1 и подписывается издателем сертификата. Атрибутный сертификат содержит девять полей: версия, владелец, издатель, идентификатор алгоритма подписи, серийный номер, период действия, атрибуты, уникальный идентификатор издателя и дополнения (см. ниже). Владелец атрибутного сертификата характеризуется подобно субъекту сертификата открытого ключа подписи, но может быть задан по имени, издателю и серийному номеру сертификата открытого ключа, либо при помощи хэш-кода сертификата или открытого ключа.
|Версия (v.1 или v.2) |
|Владелец сертификата |
|Имя издателя |
|Идентификатор алгоритма подписи |
|Серийный номер |
|Период действия (не ранее/не позднее) |
|Атрибуты |
|Уникальный идентификатор издателя |
|Дополнения |
Структура атрибутного сертификата
Атрибуты описывают информацию о полномочиях владельца атрибутного сертификата. Как и сертификат открытого ключа подписи, атрибутный сертификат может содержать дополнения. Наряду с имеющимися в системе сервисами аутентификации, атрибутные сертификаты обеспечивают защищенную передачу информации о полномочиях их владельцев . Эту технологию могут применять, например, приложения удаленного доступа к сетевым ресурсам (таким, как web-серверы и базы данных), а также приложения, которые управляют физическим доступом в помещения и к аппаратному обеспечению.