RFC: 5280
Оригинал: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Предыдущие версии: RFC 2459, RFC 3280, RFC 4325, RFC 4630
Категория: Предложенный стандарт
Дата публикации: (с дополнениями из RFC 6818, Январь 2013)
Авторы: , , , , , ,
Перевод: Мельников Дмитрий Анатольевич

4.2.1. Стандартные субполя поля «Расширения»

Далее рассматриваются стандартные субполя «Расширение сертификата», представленные в Рекомендации ITU-T X.509 3-ей версии и предназначенные для использования в Интернет/PKI-инфраструктуре. Каждое такое субполе имеет свой идентификатор, представленный в Рекомендации ITU-T X.509 3-ей версии. Эти OID в ходят в состав архитектуры «id-ce arc», определяемой следующим образом:

id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
4.2.1.1. Идентификатор ключа УЦ «authorityKeyIdentifier»

Это субполе включает параметр для идентификации открытого ключа, соответствующего закрытому ключу, который используется для подписи сертификата. Это субполе используется там, где издатель обладает несколькими ключами для подписи (либо вследствие нескольких равнозначных ключей, либо вследствие перенастройки/переустановки). Такая идентификация может быть основана, либо на идентификаторе ключа (идентификатор ключа владельца, указанный в сертификате издателя), либо на имени издателя и последовательном номере.

Последовательность «keyIdentifier» в субполе «authorityKeyIdentifier» должна обязательно включаться во все сертификаты, изданные УЦ, придерживающимися данного стандарта, с целью упрощения процедуры формирования МС. Тем не менее, существует одно исключение: если УЦ распространяет свой открытый ключ в форме «само-подписанного» («self-signed») сертификата, то субполе «authorityKeyIdentifier» может быть пропущено. Подпись на таком сертификате формируется с помощью закрытого ключа, который связан с открытым ключом владельца сертификата. (Это подтверждает, что издатель владеет обоими ключами: открытым и закрытым.) В данном случае, идентификаторы ключей УЦ и владельца сертификата могли бы быть идентичными, но только идентификатор ключа владельца необходим для формирования МС.

Значение последовательности «keyIdentifier» должно формироваться из открытого ключа, используемого для проверки подписи сертификата, или способом, используемым для генерирования уникальных чисел. Далее будут рассмотрены два способа формирования идентификаторов ключей из значения открытого ключа. Если идентификатор ключа не был сформирован заранее, то данный стандарт рекомендует использовать один из указанных способов формирования последовательности «keyIdentifier» или использовать аналогичный способ, в котором используется иной алгоритм вычисления хэш-функции. Если же идентификатор ключа был сформирован заранее, то УЦ целесообразно использовать этот идентификатор.

Данный стандарт рекомендует использовать такой подход для всех пользователей сертификатов.

УЦ, придерживающиеся данного стандарта, обязаны помечать данное субполе как «некритичное» («non-critical»).

id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }
AuthorityKeyIdentifier ::= SEQUENCE {
   keyIdentifier             [0] KeyIdentifier           OPTIONAL,
   authorityCertIssuer       [1] GeneralNames            OPTIONAL,
   authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
KeyIdentifier ::= OCTET STRING

Страница 22 из 108

2007 - 2022 © Русские переводы RFC, IETF, ISOC.