Формат сертификатов открытых ключей X.509
Купить SSL сертификат

Формат сертификатов открытых ключей X.509

Формат сертификата открытого ключа определен в рекомендациях Международного Союза по телекоммуникациям ITU (X.509) и документе RFC 3280 Certificate & CRL Profile организации инженерной поддержки Интернета Internet Engineering Task Force (IETF). IETF является открытым интернациональным сообществом исследователей, разработчиков сетевых протоколов, операторов и производителей, занимающихся проблемами развития сетей Интернет и обеспечением непрерывного функционирования существующей инфраструктуры. В настоящее время основным принятым форматом является формат версии 3, позволяющий задавать дополнения, с помощью которых реализуется определенная политика безопасности в системе. Несмотря на то, что документ RFC 3820 адресован Интернет-сообществу, формат сертификата открытого ключа предоставляет гибкий механизм передачи разнообразной информации и применяется в корпоративных PKI.

Сертификат открытого ключа подписи или шифрования представляет собой структурированную двоичную запись в формате абстрактной синтаксической нотации ASN.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" задает синтаксис сертификата, по умолчанию предполагается первая версия сертификата. Если в поле версии указывается 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" содержит отличительное имя субъекта, то есть владельца секретного ключа, соответствующего открытому ключу данного сертификата. Субъектом сертификата может выступать УЦ, РЦ или конечный субъект.

    Поле "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 содержит указатель на уведомление и/или текст уведомления, которое должно появляться на экране дисплея пользователя сертификата (включая подписчиков и доверяющие стороны) до использования сертификата и информировать о политике применения данного сертификата.

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

  •