S/MIME, ГОСТ и совместимость между приложениями¶

S/MIME — это не самостоятельный шифр¶

S/MIME использует привычную структуру электронной почты MIME и добавляет подписанные или зашифрованные криптографические объекты. Внутри таких объектов может находиться CMS. Поэтому три технологии решают разные задачи:

MIME — представление почтового сообщения, заголовки, вложения и кодирование частей.
CMS — формализованный контейнер подписей, сертификатов, получателей и зашифрованного содержимого.
ГОСТ — выбранные алгоритмы хэширования, электронной подписи, шифрования и вывода ключей.

Программа должна корректно реализовать все три уровня, чтобы обработать письмо с ГОСТ. Поддержка только ГОСТ-алгоритмов в OpenSSL не равна полной совместимости S/MIME.

Что сообщает micalg¶

Параметр micalg используется при определённых вариантах подписанных MIME-сообщений для указания алгоритма хэширования. В RFC 4490, §7.1 указан gostr3411-94. В проекте ТК26, §9.1 предложены gostr3411-2012-256 и gostr3411-2012-512.

Это объявление алгоритма, а не доказательство того, что письмо безопасно или что подпись успешно проверена. При анализе полученного сообщения необходимо сверять MIME-заголовки с фактическим криптографическим контейнером.

Что такое SMIMECapabilities¶

Атрибут SMIMECapabilities позволяет отправителю сообщить, какие криптографические алгоритмы или параметры он способен обрабатывать. В RFC 4490 и проекте ТК26 приведены варианты кодирования для ГОСТ.

Важно понимать разницу:

Возможность, заявленная в атрибуте, не заменяет испытание реального сообщения.
Для ГОСТ 28147-89 могут быть значимы параметры набора подстановок.
Получателю всё равно нужны подходящий закрытый ключ, цепочка сертификатов и работающая реализация RecipientInfo.

Пример несовместимости¶

Система А отправляет подписанное письмо с ГОСТ Р 34.10-2012/256 и Стрибог-256. Система Б умеет проверять только ГОСТ Р 34.10-2001 и хэш ГОСТ Р 34.11-94. Обе системы могут иметь маркетинговую пометку «поддержка ГОСТ», но прямой обмен невозможен.

Другой случай: обе стороны поддерживают ГОСТ Р 34.10-2012, однако первая использует KeyAgreeRecipientInfo с VKO и одним KeyWrapAlgorithm, а вторая умеет только другой формат переноса CEK. Подписи могут быть полностью совместимы, но шифрование — нет.

Поэтому составлять матрицу совместимости следует по функциям, а не по общему признаку «ГОСТ есть».

Возможность	Что необходимо согласовать
Подпись	Схема ГОСТ Р 34.10, хэш, OID, подписанные атрибуты
Доверие	Сертификат, ключевое назначение, цепочка, CRL/OCSP
Зашифрованное сообщение	Шифр содержимого, параметры, доставка CEK
Обмен ключами	VKO, параметры кривой, UKM, key wrap
Почтовая обёртка	MIME-тип, кодировки, `micalg`, detached/attached
Архивирование	Контейнер, отметки времени, долгосрочная проверка при необходимости

Чем отличаются сертификат, CMS и PFX¶

X.509 описывает сертификат открытого ключа. CMS описывает подписанное или зашифрованное сообщение. PKCS#12/PFX используется для хранения или переноса ключей и сертификатов. Внешне это могут быть похожие бинарные файлы, но они имеют разные назначения и несовместимые ASN.1-структуры.

Для современных ГОСТ-сертификатов используется RFC 9215, а для контейнеров ключей с ГОСТ имеется отдельная спецификация RFC 9548. Наличие ГОСТ-PFX не означает, что любой полученный сертификат подходит для электронной подписи или шифрования.

Практический маршрут в НАЙС.ОС¶

Для работы с реальным письмом или файлом определите его тип, извлеките CMS-контейнер по правилам MIME, разберите структуру, затем проверьте криптографическую операцию и цепочку доверия. Команды для этих этапов приведены в OpenSSL CMS, GPGSM и справочнике по сертификатам.

Почтовая оболочка, криптоконтейнер и сертификат: три разных объекта¶

Internet Message (RFC 5322)
   └── MIME body (RFC 2045 и др.)
         ├── application/pkcs7-mime      → вложенный CMS
         └── multipart/signed           → сообщение + отдельно CMS-подпись
                     │
                     ▼
                 SignedData / EnvelopedData
                     │
                     ▼
                 алгоритмы ГОСТ + сертификаты + политика доверия

Внешний MIME Content-Type помогает почтовому клиенту выбрать обработчик, но истинные алгоритмы, OID и структура определяются внутренним объектом CMS. Наличие smime-type=signed-data не доказывает, что внутри подпись прошла проверку, а расширение .p7m не гарантирует, что сообщение зашифровано.

Основная спецификация S/MIME 4.0 — RFC 8551; CMS — RFC 5652. Профили ГОСТ устанавливаются отдельно. Исторический RFC 4490 разбирайте с учётом возраста применяемых алгоритмов; для современных российских требований используйте Р 1323565.1.025-2019.

Что меняется в письме при транспортировке¶

Промежуточные серверы способны менять MIME-кодировки, переносы строк и заголовки. Для непрозрачного application/pkcs7-mime это одна ситуация, для multipart/signed с каноникализацией подписываемой MIME-части — другая. Подпись должна проверяться по точно определённому набору байтов, а не по визуально одинаковому тексту из почтового клиента. Нормализация CRLF, декодирование quoted-printable и формирование повторной MIME-оболочки требуют правил из применимого S/MIME-профиля.

Договор совместимости между клиентами¶

Поддерживаемые CMS-типы и формы opaque/detached.
OID ГОСТ-подписи, хэша, шифрования и управления CEK.
Формат сертификатов и цепочек, наличие CRL/OCSP, политика проверки.
micalg и SMIMECapabilities: используется ли только для объявления возможностей или для фактического выбора алгоритма.
Кодировки MIME и каноникализация; порядок вложения sign/encrypt.
Имена вложений, защита от опасного содержимого и недоверенных вложенных объектов.
Отрицательные тесты: повреждённая подпись, неправильный сертификат, просроченный/отозванный сертификат, неизвестный OID.

Источники¶

Маршрут чтения: SignedData → Профили → Совместимость

Отправитель → получатель	Подписать/проверить	Зашифровать/расшифровать	Доверие/отзыв	Вывод
НАЙС.ОС → внешняя система	Заполнить после теста	Заполнить после теста	Заполнить	Не заявлять без испытаний
Внешняя система → НАЙС.ОС	Заполнить после теста	Заполнить после теста	Заполнить	Не заявлять без испытаний