Перейти к содержанию

Действующие российские рекомендации по CMS: Р 1323565.1.025-2019

Почему это главный современный российский источник по CMS

Рекомендации Р 1323565.1.025-2019 «Форматы сообщений, защищённых криптографическими методами» введены 1 декабря 2019 года. В официальном фонде Росстандарта они обозначены как действующие. Область применения — защита сообщений CMS с использованием ГОСТ Р 34.10 (электронная подпись), ГОСТ Р 34.11 (хэширование), ГОСТ Р 34.12 и ГОСТ Р 34.13 (шифрование и режимы работы).

Первоначальная история российских форматов CMS отражена в RFC 4490 (2006): ГОСТ 28147-89, ГОСТ Р 34.11-94, ГОСТ Р 34.10-94/2001. Публикация проекта ТК26 2014 года помогает понять развитие ГОСТ-2012, но это архивный проект первой редакции, а не подтверждённый конечный стандарт. При выборе современного российского профиля CMS начинать следует с Р 1323565.1.025-2019 и сопоставления с используемым ПО.

Где стандарт CMS, а где алгоритм ГОСТ

ContentInfo — верхний контейнер CMS. Он содержит OID типа содержимого и его структуру. Подписанное сообщение содержит SignedData с SignerInfo, сертификатами и, при необходимости, атрибутами подписи. Зашифрованное сообщение содержит EnvelopedData с информацией о получателях и защищённым содержимым.

Ни CMS, ни ГОСТ по отдельности не гарантируют межпрограммный обмен. Две реализации должны согласовать OID подписи и хэша, набор параметров кривой, порядок байтов, поля RecipientInfo, алгоритм обёртывания ключа, кодировку DER и структуру сертификата. Если подпись проверяется, это не означает, что та же программа сможет расшифровать EnvelopedData.

Контрольные вопросы для интеграции

  1. Представлен файл как PEM/Base64 или бинарный DER? Имеется ли отделённое содержимое для SignedData?
  2. Каким OID обозначена подпись и каким OID — хэш? Используются параметры ГОСТ 2001 или ГОСТ 2012?
  3. Как упакованы данные подписи и открытого ключа: байтовый порядок и точная структура?
  4. Как для EnvelopedData получен и защищён CEK, какой алгоритм применяется для KEK и используется ли VKO/UKM?
  5. Проверяется ли статус сертификата по CRL или OCSP? Требуется ли доверенная отметка времени?
  6. Что подтверждено испытанием со второй стороной, а что только описано техническим документом?

Сопоставление эпох

Источник Назначение Как применять
RFC 4490 (2006) Старые ГОСТ-преобразования в CMS Разбор исторических сообщений
Проект ТК26 (2014) Эволюция ГОСТ 2012, VKO, S/MIME История проектирования, не нормативный итог
Р 1323565.1.025-2019 Российские рекомендации для защищённых CMS Основная точка отсчёта в РФ
RFC 9215 (2022) OID/форматы ГОСТ-2012 для X.509 Понимание ключей, сертификатов, CRL
RFC 9548 (2024) Перенос ГОСТ-ключей в PFX Контейнеры закрытых ключей

Практическое исследование контейнера

Для просмотра структуры CMS в НАЙС.ОС используйте руководство по ASN.1 и диагностику CMS. Успешный синтаксический разбор ASN.1 ещё не подтверждает корректность подписи, доверия сертификату или поддержку алгоритмов ГОСТ.

Что обязан понимать читатель CMS-профиля

CMS отделяет математику подписи от структуры, в которой эта подпись передаётся. Даже когда обе стороны реализуют ГОСТ Р 34.10-2012, несовпадение AlgorithmIdentifier, способа кодирования подписи либо набора подписанных атрибутов приведёт к отказу. Поэтому рекомендуемый порядок анализа: ASN.1-оболочка → профиль OID → хэш/подпись → путь сертификата → проверка статуса → политика использования результата.

Исходный документ ──> хэш ГОСТ ──> SignerInfo.signature
                          |             |
                          |             +--> сертификат и OID параметров
                          +--> signedAttrs (если присутствуют)
                                      |
                                      v
                             SignedData / ContentInfo
                                      |
                                      v
                              DER и транспорт S/MIME

Проверка SignedData по этапам

  1. Установите, какое содержимое подписано — внутри контейнера или отдельным файлом. При отсоединённой подписи отсутствие исходных байтов делает проверку невозможной.
  2. Разберите ContentInfo, SignedData, SignerInfo и подписанные атрибуты; сравните OID и параметры с выбранным профилем.
  3. Проверьте подпись именно над теми байтами, которые предписаны CMS, с учётом DER-кодирования атрибутов.
  4. Проверьте сертификат подписанта и область применения: keyUsage, EKU, доверенный УЦ, период действия, CRL/OCSP.
  5. Если необходима проверка на исторический момент, отдельно спроектируйте хранение временных свидетельств и отметки времени; текущее состояние УЦ недостаточно для ретроспективного вывода.

Проверка EnvelopedData

В EnvelopedData обычно различают CEK (шифрование содержимого) и средства защиты CEK для получателя. Условия совместимости: способ создания общего секрета VKO, случайный UKM, алгоритм обёртывания, параметры кривой, OID, IV/nonce, кодирование RecipientInfo. Нельзя считать подтверждённым шифрование контейнера только потому, что openssl list показывает kuznyechik.

Отдельные вопросы российского профиля

Р 1323565.1.025-2019 должна рассматриваться вместе с требованиями к формату ключей из RFC 9215 и общим синтаксисом RFC 5652. Исторический RFC 4490 нужен для чтения старых объектов; применение прежних наборов параметров в новых системах следует отдельно обосновывать. Проект ТК26 2014 года полезен для объяснения эволюции, но не заменяет действующую рекомендацию.

Техническая диагностика и доказательства

В НАЙС.ОС исследование контейнера разделяется на три независимые процедуры: декодирование ASN.1/DER, криптографическая проверка и оценка доверия. Для обмена с другой системой фиксируйте результат отдельно для SignedData и EnvelopedData; проверка только одной операции недостаточна.

Частые отказы: unsupported algorithm (неподдерживаемый OID/EVP), bad signature (байты или порядок), unable to get issuer certificate (цепочка), revoked (статус), no recipient matches (шифрование/идентификаторы). Не следует маскировать ошибки доверия переключением в режим проверки только математики без явной пометки.

Связанные руководства: подписанное CMS, шифрованное CMS, OpenSSL CMS, GPGSM, libksba.

Источники

Доступная карточка Росстандарта подтверждает статус и область применения, но не заменяет проверку полного текста требований при формировании конкретного межвендорного профиля.