Об утверждении Формата электронной подписи, обязательного для реализации всеми средствами электронной подписи
Приказ Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 14.09.2020 № 472 "Об утверждении Формата электронной подписи, обязательного для реализации всеми средствами электронной подписи"
Текст — по данным ИПС «Законодательство России». Проверено 22.09.2026 17:33. Скачать .doc · Печать
МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ
ПРИКАЗ
Москва
14 сентября 2020 г. № 472
Об утверждении Формата электронной подписи, обязательного для реализации всеми средствами электронной подписи
Зарегистрирован Минюстом России 29 октября 2020 г.
Регистрационный № 60631
В соответствии с положениями пункта 5 части 4 статьи 8 Федерального закона от 6 апреля 2011 г. № 63-ФЗ "Об электронной подписи" (Собрание законодательства Российской Федерации, 2011, № 15, ст. 2036; 2019, № 26, ст. 3889) и абзаца третьего пункта 1 Положения о Министерстве цифрового развития, связи и массовых коммуникаций Российской Федерации, утвержденного постановлением Правительства Российской Федерации от 2 июня 2008 г. № 418 (Собрание законодательства Российской Федерации, 2008, № 42, ст. 4825; 2018, № 40, ст. 6142),
ПРИКАЗЫВАЮ:
1. Утвердить Формат электронной подписи, обязательный для реализации всеми средствами электронной подписи, согласно приложению к настоящему приказу.#❝
2. Направить настоящий приказ на государственную регистрацию в Министерство юстиции Российской Федерации.#❝
УТВЕРЖДЕН
приказом Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации
от 14 сентября 2020 г. № 472#❝
1. Настоящий формат электронной подписи, обязательный для реализации всеми средствами электронной подписи (далее - Формат), устанавливает требования к структуре и содержанию информации в электронной подписи (далее - ЭП).#❝
В составе ЭП должна размещаться информация об исходном электронном сообщении, алгоритмах хэширования и ЭП, параметрах криптографических алгоритмов, времени создания ЭП, сертификат ключа проверки ЭП (далее - сертификат), иерархически обусловленная последовательность сертификатов, каждый последующий сертификат которой подписан ЭП, основанной на предшествующем сертификате, и иные, установленные в соответствии с пунктами 5, 6 и 7 настоящего Формата, сведения.#❝
2. В соответствии с настоящим Форматом средства ЭП должны обеспечивать возможность создания нескольких ЭП в одном документе с сохранением данных, описывающих контекст, содержание, структуру документов, а также обеспечивающих управление документами в используемых информационных системах, - метаданных и сертификатов, на которых основаны эти ЭП, в электронном сообщении.#❝
3. При включении в состав ЭП дополнительной информации, отличной от указанной в пунктах 5, 6 и 7 настоящего Формата, требования к ее назначению и расположению в структуре ЭП определяются заказчиком в техническом задании на разработку (модернизацию) средств ЭП и удостоверяющего центра (далее - УЦ), в соответствии с приказом ФСБ России от 9 февраля 2005 г. № 66 "Об утверждении Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации (Положение ПКЗ-2005)" (зарегистрирован Минюстом России 3 марта 2005 г., регистрационный № 6382), с изменениями, внесенными приказом ФСБ России от 12 апреля 2010 г. № 173 "О внесении изменений в некоторые нормативные правовые акты ФСБ России" (зарегистрирован Минюстом России 25 мая 2010 г., регистрационный № 17350).#❝
4. Формат определяется в соответствии с основами аутентификации в открытых системах1, синтаксисом криптографических сообщений, описанием дополнительных атрибутов криптографических сообщений, спецификацией абстрактной синтаксической нотации версии один2.#❝
5. В случае если участник электронного взаимодействия является владельцем действующего сертификата ключа проверки электронной подписи, Формат имеет вид следующей структуры:#❝
SignedData:.= SEQUENCE { version digestAlgorithms encapContentInfo certificates crls signerinfos |
[0] [1] |
CMSVersion, DigestAlgorithmidentifiers, EncapsulatedContentInfo, IMPLICIT CertificateSet OPTIONAL, IMPLICIT RevocationlnfoChoices OPTIONAL, Signerinfos} |
5.1. Поле version (типа CMSVersion) определяет версию синтаксиса ЭП, которая зависит от сертификатов, типа подписываемых данных и информации о подписывающих сторонах:#❝
5.2. Поле digestAlgorithms (тип DigestAlgorithmldentifiers) включает в себя идентификаторы используемых алгоритмов хэширования и связанные с ними параметры и определяется следующим образом:#❝
В качестве идентификатора алгоритма хэширования указывается объектный идентификатор алгоритма, определенного ГОСТ Р 34.11-2012 "Информационная технология. Криптографическая защита информации. Функция хэширования"3 (далее - ГОСТ Р 34.11-2012). Указанный объектный идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:#❝
id-tc26-gost3411-12-256 OBJECT IDENTIFIER :: = {iso(l) member-body(2) ru(643) rosstandart(7) tc26(l) algorithms(1) digest(2) gost3411-12-256(2)}#❝
id-tc26-gost3411-12-512 OBJECT IDENTIFIER::= {iso(l) member-body(2) ru(643) rosstandart(7) tc26(l) algorithms(1) digest(2) gost3411-12-512(3)}#❝
______________________________
1 Основы аутентификации в открытых системах определены в ГОСТ Р ИСО/МЭК 9594-8-98 "Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификации" (принят и введен в действие постановлением Госстандарта России от 19 мая 1998 г. № 215, опубликован в августе 1998 г. ИПК "Издательство стандартов", ИУС 9-98).
2 Спецификация абстрактной синтаксической нотации версии один определена в ГОСТ Р ИСО/МЭК 8824-1-2001 "Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации" (принят и введен в действие постановлением Госстандарта России от 6 сентября 2001 г. № 375-ст, опубликован в ноябре 2001 г. ИПК "Издательство стандартов", ИУС 11-2001).
3 ГОСТ Р 34.11-2012 "Информационная технология. Криптографическая защита информации. Функция хэширования" (утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 7 августа 2012 г. № 216-ст, опубликован в апреле 2013 г. ФГУП "СТАНДАРТИНФОРМ", ИУС 3-2013, поправка ИУС 6-2018).
5.3. Поле encapContentlnfo (тип EncapsulatedContentlnfo) содержит подписываемые данные (eContent) вместе с их типом (eContentType) и определяется следующим образом:#❝
5.4. В поле certificates (тип CertificateSet) может включаться дополнительная информация о сертификатах. В данное поле может быть включена информация о сертификатах подписывающих сторон.#❝
5.4.1. Основной синтаксис типа Certificate представлен следующим образом:#❝
tbsCertificate signatureAlgorithm signaturevalue | TBSCertificate, Algorithmidentifier, |
Поле signatureAlgorithm (тип SignatureAlgorithmldentifier) определяет идентификатор использованного алгоритма ЭП и связанные с ним параметры:#❝
В настоящем Формате в качестве идентификатора алгоритма ЭП указывается объектный идентификатор алгоритма, определенного ГОСТ Р 34.10-2012 "Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи"1 (далее - ГОСТ Р 34.10-2012). Указанный объектный идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:#❝
id-tc26-gost3410-12-256 OBJECT IDENTIFIER::= {iso(l) member-body(2) ru(643) rosstandart(7) tc26(l) algorithms(1) sign(l) gost3410-2012-256(1)}#❝
id-tc26-gost3410-12-512 OBJECT IDENTIFIER::= {iso(l) member-body(2) ru(643) rosstandart(7) tc26(l) algorithms(1) sign(l) gost3410-2012-512 (2)}#❝
______________________________
1 ГОСТ P 34.10-2012 "Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи" (утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 7 августа 2012 г. № 215-ст, опубликован в апреле 2013 г. ФГУП "СТАНДАРТИНФОРМ", ИУС 3-2013, переиздание сентябрь 2018 г.).
5.4.2. Поле extendedCertificate (типа ExtendedCertificate) определяет расширенный сертификат PKCS #6. Расширенные сертификаты PKCS #6 поддерживаются для совместимости с предыдущими версиями и не применяются.#❝
5.4.3. Поле vlAttrCert (типа AttributeCertificateVl) определяет сертификат атрибута Х.509 версии 1 в соответствии с пунктом 9 Требований к форме квалифицированного сертификата ключа проверки электронной подписи, утвержденных приказом ФСБ России от 27.12.2011 № 795 (зарегистрирован Минюстом России 27 января 2012 г., регистрационный № 23041), используется для совместимости с предыдущими версиями и применению не подлежит.#❝
5.4.4. Поле v2AttrCert (типа AttributecertificateV2) определяет сертификат атрибута Х.509 версии 2 в соответствии с пунктом 9 Требований к форме квалифицированного сертификата ключа проверки электронной подписи, утвержденных приказом ФСБ России от 27.12.2011 № 795:#❝
5.4.5. Поле other (типа OtherCertificateFormat) предназначено для обеспечения возможности поддержки иных форматов сертификатов без внесения изменений в синтаксис криптографических сообщений:#❝
5.5.1. Поле crl (типа CertificateList) определяет список аннулированных сертификатов (CRL). Для вычисления подписи данные, которые должны быть подписаны, представляются в ASN.l-коде по DER-правилам:#❝
CertificateList::= SEQUENCE { | ||
tbsCertList | TBSCertList, AlgorithmIdentifier, BIT STRING} | |
TBSCertList::= SEQUENCE { | ||
version | | Version OPTIONAL, -- если представлено, то должно быть 2-й версии AlgorithmIdentifier, Name, Time, Time OPTIONAL, SEQUENCE OF SEQUENCE { CertificateSerialNumber, Time, Extensions OPTIONAL -- если представлено, то должно быть 2-й версии } OPTIONAL, EXPLICIT Extensions OPTIONAL -- если представлено, то должно быть 2-й версии } |
5.5.2. Поле other (типа OtherRevocationInfoFormat) определяет форматы информации об отзыве без дополнительного изменения синтаксиса криптографических сообщений.#❝
5.6. В поле signerInfos (тип SignerInfos) содержится информация о каждой подписывающей стороне электронного документа.#❝
5.6.1. Поле sid (тип SignerIdentifier) определяет сертификат подписывающей стороны, необходимый для проверки подлинности ЭП.#❝
5.6.2. Поле digestAlgorithm (тип DigestAlgorithmIdentifier) определяет идентификаторы использованного в данной ЭП алгоритма хэширования и связанные с ним параметры.#❝
5.6.3. Поле signedAttrs (тип SignedAttributes) должно определять дополнительную подписываемую информацию (далее - подписываемые атрибуты). Обязательные к включению подписываемые атрибуты определяются следующим образом:#❝
5.6.4. Поле signature (тип SignatureValue) содержит строку бит, полученную в результате процесса формирования ЭП:#❝
5.6.5. Поле unsignedAttrs (тип UnsignedAttributes) определяет дополнительную неподписываемую информацию (далее - неподписываемые атрибуты):#❝
6.1. Тип содержимого (Content-type). Должен быть добавлен в атрибут id-contentType с объектным идентификатором вида "1.2.840.113549.1.3";#❝
6.2. Строка бит, являющаяся выходным результатом функции, отображающей строки бит в строки бит фиксированной длины и удовлетворяющей следующим условиям:#❝
по данному значению функции невозможно на период действия сертификата вычислить исходные данные, отображаемые в этом значении;#❝
для заданных исходных данных невозможно на период действия сертификата вычислить другие исходные данные, отображаемые в этом значении;#❝
6.3. Хэш-код от набора полей сертификата, позволяющих однозначно его идентифицировать, должен быть добавлен в атрибут id-aa-signingCertificateV2 с объектным идентификатором вида "1.2.840.113549.1.9".#❝
7. В случае если участник электронного взаимодействия не является владельцем действующего сертификата ключа проверки электронной подписи, Формат должен иметь вид следующей структуры:#❝
7.1. Структура CertificationRequestInfo в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:#❝
CertificationRequestInfo::= SEQUENCE {#❝
version |
[0] | INTEGER {v1(0)} (v1,...), Name, SubjectPublicKeyInfo{{PKInfoAlgorithms}}, Attributes{{CRIAttributes}}}, где |
subject - имя субъекта, владеющего ключом ЭП, имеющее тип Name, которое заполняется в соответствии с Требованиями к форме квалифицированного сертификата ключа проверки электронной подписи, утвержденными приказом ФСБ России от 27.12.2011 г. № 795;#❝
subjectPKInfo - набор элементов, содержащих информацию о ключе проверки ЭП и имеющих структуру SubjectPublicKeyInfo;#❝
Структура SubjectPublicKeyInfo в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:#❝
SubjectPublicKeyInfo (ALGORITHM: IOSet}::= SEQUENCE {#❝
algorithm subjectPublicKey |
| AlgorithmIdentifier {{IOSet}} BIT STRING}, где |
Поле algorithm структуры SubjectPublicKeyInfo задается структурой AlgorithmIdentifier, описанной в ГОСТ Р ИСО/МЭК 9594-8 и содержащей следующие поля:#❝
для алгоритма ГОСТ Р 34.10-2012 с длиной ключа 256 бит идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:#❝
для алгоритма ГОСТ Р 34.10-2012 с длиной ключа 512 бит идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:#❝
Поле parameters структуры AlgorithmIdentifier имеет структуру GostR3410-2012-PublicKeyParameters, которая в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:#❝
publicKeyParamSet - идентификатор параметров ключа проверки ЭП, соответствующего алгоритму ЭП ГОСТ Р 34.10-2012;#❝
данное поле не следует использовать, если используется алгоритм ЭП ГОСТ Р 34.10-2012 с длиной ключа 512 бит;#❝
данное поле должно присутствовать, если используется алгоритм ЭП ГОСТ Р 34.10-2012 с длиной ключа 256 бит при следующих значениях поля publicKeyParamSet:#❝
при этом он должен быть равен идентификатору алгоритма хэширования ГОСТ Р 34.11-2012 с длиной выхода 256 бит:#❝
данное поле не следует использовать, если используется алгоритм ЭП ГОСТ Р 34.10-2012 с длиной ключа 256 бит при следующем значении поля publicKeyParamSet:#❝
данное поле должно отсутствовать, если используется алгоритм ЭП ГОСТ Р 34.10-2012 с длиной ключа 256 бит при следующих значениях поля publicKeyParamSet:#❝
Поле subjectPublicKey структуры SubjectPublicKeyInfo содержит ключ проверки ЭП, который задается парой координат (x, y), определенной ГОСТ Р 34.10-2012, представляется следующим образом:#❝
ключ проверки ЭП, соответствующий алгоритму ГОСТ Р 34.10-2012 с длиной ключа 256 бит, имеет представление GostR3410-2012-256-PublicKey, которое задается байтовой строкой длины 64 байта, где первые 32 байта содержат представление координаты x в формате little-endian (младший бит записывается первым), а последние 32 байта содержат представление координаты y в формате little-endian;#❝
ключ проверки ЭП, соответствующий алгоритму ГОСТ Р 34.10-2012 с длиной ключа 512 бит, имеет представление GostR3410-2012-512-PublicKey, которое задается байтовой строкой длины 128 байт, где первые 64 байта содержат представление координаты x в формате little-endian, а последние 64 байта содержат представление координаты y в формате little-endian.#❝
7.2. Поле algorithm структуры signatureAlgorithm содержит идентификатор алгоритма ЭП и связанных с ним параметров, который используется при формировании ЭП структуры CertificationRequestInfo с использованием ключа ЭП:#❝
для алгоритма ГОСТ Р 34.10-2012 с длиной ключа 256 бит идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:#❝
7.3. Поле signature структуры CertificationRequest содержит ЭП подписываемой информации.#❝
Результатом работы алгоритма ЭП ГОСТ Р 34.10-2012 с длиной ключа 256 бит является два числа r и s, определенные ГОСТ Р 34.10-2012 и имеющие длину 256 бит каждое.#❝
При использовании алгоритма ГОСТ Р 34.10-2012 с длиной ключа 256 бит поле signature задается битовой строкой (BITSTRING) длины 512 бит; при этом первые 256 бит содержат число s в представлении big-endian (старший бит записывается первым), а вторые 256 бит содержат число r в представлении big-endian.#❝
О каких нормах
Документы того же органа рядом по дате
- О внесении изменения в Положение о комиссии по отбору получателей грантов на реализацию проектов по разработке отечественного программного обеспечения — Приказ Минцифры России от 15.06.2020 № 277
- О внесении изменений в Правила применения оборудования радиодоступа. Часть 1. Правила применения оборудования радиодоступа для беспроводной передачи д — Приказ Минцифры России от 06.07.2020 № 321
- О внесении изменений в российскую систему и план нумерации, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 2 — Приказ Минцифры России от 24.08.2020 № 425
- О признании утратившим силу приказа Министерства связи и массовых коммуникаций Российской Федерации от 29.08.2011 № 213 "Об утверждении Административн — Приказ Минцифры России от 11.09.2020 № 468
- Об утверждении классификатора программ для электронных вычислительных машин и баз данных — Приказ Минцифры России от 22.09.2020 № 486
- Об утверждении нормативов размещения отделений почтовой связи и иных объектов почтовой связи акционерного общества "Почта России" — Приказ Минцифры России от 26.10.2020 № 538
- Об утверждении Перечня должностей федеральной государственной гражданской службы в Министерстве цифрового развития, связи и массовых коммуникаций Росс — Приказ Минцифры России от 26.10.2020 № 540
- О внесении изменений в Правила оказания услуг почтовой связи, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от — Приказ Минцифры России от 19.11.2020 № 602