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)
Авторы: , , , , , ,
Перевод: Мельников Дмитрий Анатольевич
5.1.1.3. Субполе «signatureValue»

Это субполе содержит цифровую подпись, которая была вычислена по последовательности символов в ASN.1/DER-коде, содержащейся в поле «tbsCertList». Последовательность символов в ASN.1/DER-коде, содержащаяся в поле «tbsCertList», представляет собой входные данные функции вычисления подписи. Это значение подписи закодировано в формате битовой последовательности («BIT STRING»), и включено в субполе «signatureValue». Детали этой процедуры представлены в стандартах RFC-3279, RFC-4055 и RFC-4491.

УЦ, которые также выпускают СОС, могут использовать один закрытый ключ или разные закрытые ключи для цифровой подписи сертификатов и СОС. Когда применяются разные закрытые ключи, тогда каждый из открытых ключей, связанных с этими закрытыми ключами, указывается в отдельном сертификате. В одном сертификате в субполе «Key usage» поля «Расширения» установлен флаг «keyCertSign», а в другом сертификате в субполе «Key usage» поля «Расширения» установлен флаг «cRLSign» (4.2.1.3). Если используются разные закрытые ключи, то сертификаты, издаваемые УЦ, содержат идентификатор первого ключа УЦ, а соответствующие СОС содержат идентификатор второго ключа УЦ. Использование отдельных сертификатов УЦ при подтверждении подлинности подписей сертификатов и подписей СОС может обеспечить лучшие показатели защищённости. Тем не менее, такой подход влечёт за собой дополнительные расходы для прикладных систем, а также он может ограничить функциональную совместимость. Многие прикладные системы формируют МС, а затем подтверждают подлинность такого маршрута. Проверка СОС, в свою очередь, требует отдельного МС, который должен формироваться и проверяться на предмет его подлинности относительно сертификата УЦ, необходимого для подтверждения подлинности подписи в СОС. Прикладные системы, которые осуществляют проверку СОС, обязаны проводить ПрПП (процедуру подтверждения подлинности) МС, если сертификаты и СОС включают цифровые подписи, сформированные с помощью одного и того же закрытого ключа УЦ. Целесообразно, чтобы такие прикладные системы проводили ПрПП МС, если сертификаты и СОС включают цифровые подписи, сформированные с помощью разных закрытых ключей УЦ.

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