ГОСТ в CMS: что определяет RFC 4490¶

Почему документ 2006 года важен до сих пор¶

RFC 4490 (май 2006 года, Proposed Standard) определяет соглашения по использованию ГОСТ Р 34.10-94, ГОСТ Р 34.10-2001, ГОСТ Р 34.11-94 и ГОСТ 28147-89 в CMS. Он нужен для чтения накопленных документов, миграции архивов и диагностики совместимости с реализациями, которые формировались вокруг CryptoPro-параметров раннего поколения.

Не следует понимать название «стандарт» как рекомендацию выбирать именно эти алгоритмы для нового проекта. В RFC описан определённый исторический профиль. Современные алгоритмы ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012 рассматриваются в других документах.

Хэш ГОСТ Р 34.11-94¶

В разделе 2.1 приводится алгоритм с 256-битным результатом и OID 1.2.643.2.2.9 (id-GostR3411-94). В поле AlgorithmIdentifier документ требует NULL в параметрах, одновременно разрешая реализациям принимать отсутствие поля в определённых случаях. Это пример того, как отличие ASN.1-кодирования может влиять на совместимость при одинаковой математической операции.

Хэш — только входные данные для подписи или средство обнаружения изменений. Сам по себе он не устанавливает подписанта. Для современных документов используется семейство ГОСТ Р 34.11-2012 («Стрибог»), а не этот исторический алгоритм.

Электронная подпись¶

Раздел 3 описывает две схемы ГОСТ Р 34.10: 1994 и 2001 годов. Для варианта 2001 года документ связывает подпись с хэшем ГОСТ Р 34.11-94 и описывает представление подписи как 64-байтовую строку s || r: сначала 32 байта s, затем 32 байта r, оба числа записаны в порядке от старшего байта к младшему.

Подпись ГОСТ Р 34.10-2001 в CMS
┌───────────────────────┬───────────────────────┐
│ s (32 байта)          │ r (32 байта)          │
└───────────────────────┴───────────────────────┘
                   всего 64 байта

Если криптографическая библиотека внутри использует другую структуру, ей потребуется корректное преобразование; простая перестановка байтов без понимания формата — типовая причина ошибок проверки.

Управление ключами: VKO и CryptoPro Key Wrap¶

Раздел 4 различает два механизма доставки симметрического ключа содержимого: согласование ключа (KeyAgreeRecipientInfo) и транспорт ключа (KeyTransRecipientInfo). Стороны используют соответствующие асимметрические ключи и правила выработки ключевого материала, а затем защищают сеансовый ключ через механизм wrapping.

В RFC встречаются идентификаторы id-GostR3410-2001-CryptoPro-ESDH, id-Gost28147-89-CryptoPro-KeyWrap и id-Gost28147-89-None-KeyWrap. Они не взаимозаменяемы: отличия касаются структуры контейнера и правил обработки ключей. Даже если отправитель и получатель поддерживают ГОСТ 28147-89, это ещё не означает, что они умеют одинаково доставить ключ содержимого.

Шифрование содержимого ГОСТ 28147-89¶

Раздел 5 описывает OID 1.2.643.2.2.21 (id-Gost28147-89). Его параметры — не просто название шифра:

Gost28147-89-Parameters ::= SEQUENCE {
  iv                  OCTET STRING (SIZE (8)),
  encryptionParamSet  OBJECT IDENTIFIER
}

Восемь байт IV и идентификатор набора параметров входят в смысл конкретного CMS-профиля. Две стороны с несовпадающими encryptionParamSet могут успешно прочитать ASN.1 и при этом не суметь расшифровать данные.

Аутентификация и S/MIME¶

В разделе 6 указан HMAC на основе ГОСТ Р 34.11-94 (1.2.643.2.2.10). В разделе 7 рассмотрены S/MIME-объявления, в том числе micalg="gostr3411-94" и атрибут SMIMECapabilities. В разделе 8 предусмотрено требование уникальности UKM и IV, подчёркнута важность проверки допустимости параметров и разделения назначений ключей.

На практике это объясняет, почему исторический контейнер может читаться одним программным продуктом, но не открываться другим: другая реализация либо не распознаёт конкретные OID, либо не поддерживает согласованный параметрический набор, либо по-иному обрабатывает key wrap.

Исторический профиль и новая криптография¶

Область	RFC 4490	Профиль ГОСТ 2012
Подпись	ГОСТ Р 34.10-94/2001	ГОСТ Р 34.10-2012 (256/512)
Хэширование	ГОСТ Р 34.11-94	ГОСТ Р 34.11-2012 (Стрибог 256/512)
Шифрование содержимого	ГОСТ 28147-89	В проекте ТК26 2014 года также ГОСТ 28147-89
Работа с ключами	Старые VKO/Key Wrap	VKO ГОСТ Р 34.10-2012, новые OID

Последний столбец описывает именно предложенные положения проекта ТК26 2014 года, а не универсальный обязательный профиль для любых сегодняшних систем. Алгоритм «Кузнечик» не следует автоматически считать шифром содержимого всех CMS-контейнеров только потому, что он реализован в ядре НАЙС.ОС.

Первоисточники¶

Правовой и технический статус RFC 4490¶

RFC 4490 опубликован в мае 2006 года и имеет статус Standards Track. Это важно: его нельзя называть «неформальным проектом» или смешивать со статусом информационных публикаций о новых алгоритмах ГОСТ. Документ описывает применение ГОСТ 28147-89, ГОСТ Р 34.11-94, ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001 в CMS. Он полезен для разбора архивов и межоперабельности с legacy-системами, но не служит каталогом всех современных ГОСТ-2012-алгоритмов.

Матрица «старый профиль → современный аналог задачи»¶

Криптографическая задача	В историческом RFC 4490	Что искать в современных профилях
Хэш подписываемого содержимого	ГОСТ Р 34.11-94	Стрибог-256/512 и соответствующие OID
Электронная подпись	ГОСТ Р 34.10-94/2001	ГОСТ Р 34.10-2012/256 или 512
Шифрование содержимого	ГОСТ 28147-89	Кузнечик, Магма и установленные режимы
Обёртывание CEK	Исторические ГОСТ-профили key wrap	VKO, экспорт ключей и профиль сообщения

Это таблица задач, а не таблица совместимых OID. Переход на современные алгоритмы требует перевыпуска или преобразования объекта соответствующим отправителем. Переименование старого OID в новый не делает данные совместимыми.

Что проверять в старом CMS¶

Расшифровать вложенность ContentInfo, не предполагая, что всегда используется SignedData.
Из AlgorithmIdentifier получить не только числовой OID, но и сериализованные параметры (SEQUENCE, NULL или их отсутствие — не взаимозаменяемы произвольно).
Установить реальный алгоритм хэша и подписи через поля SignerInfo и, независимо, алгоритм открытого ключа в X.509-сертификате.
При зашифрованном сообщении исследовать RecipientInfo, параметр UKM, идентификатор параметров ГОСТ 28147-89 и способ обёртывания CEK.
При проверке подписи различать «арифметически верна» и «действительна по политике организации на дату проверки».

RFC 4490 — источник правил конкретного профиля: нельзя распространять его поля и длины без проверки на рекомендации Р 1323565.1.025-2019 и формат ГОСТ-2012.

Историческая совместимость и режим модернизации¶

Legacy-алгоритмы нередко требуются для чтения ранее созданных документов, но это не означает, что их следует разрешать для создания новых долговременно хранимых подписей или сообщений. Раздельно задайте политику read/verify legacy и issue new. Само решение зависит от требований системы, актуальной нормативной базы и управления ключами.

Типичная ошибка миграции: программа распознаёт OID ГОСТ Р 34.10-2001, но отсутствует согласованный набор кривых или шифр для EnvelopedData. Проверка подписи и расшифрование документа требуют разных частей криптопровайдера и имеют разные диагностические следы.

Связанные руководства: форматы OID и DER, подписанные сообщения, управление CEK, работа с КриптоПро. Современная нормативная точка отсчёта для РФ — Р 1323565.1.025-2019.

Маршрут чтения: История ГОСТ-2012 → OID/DER → Матрица совместимости