С таким длинным заголовком "Массовая незаконная электронная подпись или мина замедленного действия: Формат МинЦифры №472" и запутанным содержанием появилась статья на Хабре.
Автор задаётся непростым вопросом, как теория в лице приказа Минцифры России от 14.09.2020 № 472 "Об утверждении Формата электронной подписи, обязательного для реализации всеми средствами электронной подписи" соотносится с практикой.
Насчет согласования приказа между регуляторами: МинЦифры должна его (приказ и формат ЭП) была согласовать с ФСБ (федеральный орган исполнительной власти в области обеспечения безопасности) .
Вопрос 3. Существует ли опубликованное или секретное согласование со стороны ФСБ формата, разработанного МинЦифрой (№472)?
Приказы ведомств согласуются с использованием соответствующего листа согласования. Нет никаких сомнений, что 472 приказ Минцифры был согласован со стороны ФСБ России. По-другому и быть не могло с документом, в котором идут ссылки на ПКЗ-2005 и 795 приказ. Для информации, например, в приказе ФСБ России от 20.04.2021 № 154 "Об утверждении Правил подтверждения владения ключом электронной подписи" 5 раз даётся ссылка на 472 приказ Минцифры России.
Смотрим 1 пункт Формата: В составе ЭП должна размещаться информация об исходном электронном сообщении, алгоритмах хэширования и ЭП, параметрах криптографических алгоритмов, времени создания ЭП, сертификат ключа проверки ЭП, иерархически обусловленная последовательность сертификатов, каждый последующий сертификат которой подписан ЭП, основанной на предшествующем сертификате, и иные сведения.
Что напоминает? Правильно, CMS, описывающий шесть типов данных:
- просто данные (data),
- данные с электронной подписью (signed data),
- упакованные данные (enveloped data),
- хешированные данные (digested data),
- зашифрованные данные (encrypted data),
- данные с проверкой подлинности (authenticated data).
Пункт 5:
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmldentifiers,
encapContentlnfo EncapsulatedContentlnfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationlnfoChoices OPTIONAL,
signerlnfos Signerlnfos }
Один в один RFC 5652 Cryptographic Message Syntax (CMS),
Даже номер пункта, описывающий тип содержимого подписанных данных, практически одинаковый - 5.1
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
Регулятор не мог издать приказ в котором бы написал - утвердить в качестве Формата электронной подписи, обязательного для реализации всеми средствами электронной подписи, RFC 5652 Cryptographic Message Syntax (CMS). Это как многие наши ГОСТ по факту являются переводами международных стандартов ИСО и МЭК, так и 472 приказ - перевод RFC 5652.
Телеграм-канал "Об ЭП и УЦ"
https://t.me/ep_uc/1577
