Профили ГОСТ CMS и жизненный цикл защищённого документа¶
Алгоритмы выбираются один раз при выпуске сообщения, но его проверка и использование могут происходить через годы. Поэтому проекту нужны не только параметры подписи, но и политика формата, хранения доказательств, миграции алгоритмов и повтора проверки.
Состав профиля CMS¶
Документируйте конкретную комбинацию:
[Объект] → [ContentInfo / тип CMS] → [OID и параметры алгоритмов]
→ [схема attached/detached] → [сертификаты и доверие]
→ [время + CRL/OCSP] → [формат хранения доказательств]
Без указания режима шифрования, параметров ключей и представления сертификата строка «CMS ГОСТ» не является достаточной спецификацией. Базовый синтаксис: RFC 5652, действующие российские рекомендации по форматам защищённых CMS: Р 1323565.1.025-2019.
От выпуска до архивирования¶
- Создание. Проверить параметры сертификата и доступные алгоритмы; выбрать единый формат выходных байтов; сформировать сообщение.
- Передача. Сохранить MIME и detached-content без несанкционированного преобразования.
- Получение. Разобрать входные ASN.1 и атрибуты; подтвердить криптографическую проверку и происхождение ключа.
- Проверка статуса. Собрать и сохранить необходимые сведения о цепочке и отзыве.
- Хранение. Зафиксировать исходные байты, целостность и идентифицирующие метаданные, необходимые для последующего перепроверения.
- Миграция. При смене разрешённых алгоритмов выпускать новые сообщения/доказательства установленным процессом, не переименовывать OID старых объектов.
Два отдельных режима: создание нового и чтение архивного¶
Разрешение проверять исторический ГОСТ-2001 не означает разрешение подписывать новые документы на старых алгоритмах. Это должно быть явным решением криптографической политики с учётом действующих требований. См. RFC 4490, историю ГОСТ-2012, алгоритмы, проверку доверия.
Разные временные метки¶
signingTime — заявленное время; отметка по RFC 3161 — отдельный криптографически проверяемый объект; дата файла в системе — метаданные файловой системы. Их нельзя приравнивать. Ретроспективная проверка требует решения о допустимых источниках времени и свидетельствах отзыва.
Интеграция с НАЙС.ОС¶
Для рабочих процедур см. OpenSSL CMS, GPGSM, управление ключами и политику PKI. Отдельный ГОСТ-CRL для strongSwan демонстрирует защиту сетевого канала, но не заменяет политики проверки подписи документа.
Далее: матрица совместимости → проверка контейнеров.
Матрица изменений профиля¶
| Изменение | Риск | Правильная процедура |
|---|---|---|
| Обновление OpenSSL/GPGSM | Новые или удалённые OID и политики | Повторное испытание эталонных контейнеров |
| Смена параметров кривой | Несовместимость SignerInfo/X.509 |
Выпуск новых ключей и сертификатов по профилю |
| Истечение срока сертификата | Невозможность обычной проверки «на сейчас» | Переход на документированную временную политику |
| Отзыв сертификата | Утрата допуска ключа | Фиксация причины и даты, оценка всех зависимых сообщений |
| Изменение формата MIME | Потенциальная порча detached-содержимого | Контроль побайтового представления |
| Смена криптоалгоритма | Старые OID остаются в архивах | Раздельные политики чтения и создания |
| Обновление trust store | Изменение списка доверенных CA | Контроль ожидаемого набора CA, пробная проверка подписей |
Рекомендации по хранению доказательств¶
Неподвижным объектом архива должны оставаться исходные байты CMS и отдельно переданные документы, а не только экспортированный текст. Желательно хранить контрольные суммы, сведения об источнике контейнера, цепочке сертификатов, использованной политике, результате проверки и версии криптографической библиотеки. Политика хранения CRL/OCSP и доверенных отметок времени зависит от назначения системы и нормативного режима; она не выводится из одного RFC 5652.
Если вы создаёте веб-сервис проверки на базе НАЙС.ОС, не подменяйте архив оригинального сообщения нормализованным JSON: JSON полезен для индекса и поиска, но уже не содержит исходную подпись и точный байтовый набор атрибутов. Результаты API должны ссылаться на неизменяемый идентификатор исходного объекта.
Что не подтверждает криптографическая библиотека¶
Успешная проверка ГОСТ Р 34.10 показывает соответствие математического значения подписи ключу и проверяемым байтам. Она сама по себе не подтверждает полномочий подписанта, получение согласия, действительность сделки, точность документа или соблюдение регуляторных требований. Эти вопросы решает бизнес-правило и применимое законодательство. Техническая документация должна сохранять это разграничение.
Варианты сценариев¶
Электронная почта: формат и каноникализация определяются S/MIME, см. RFC 8551 и руководство S/MIME.
Файлы документооборота: важно различать attached/detached, цепочки, статусы сертификатов и политику хранения SignedData.
Зашифрованные архивы: нужен подходящий EnvelopedData, защищённый CEK, доступ к ключам получателей и процедура восстановления при ротации ключей. См. EnvelopedData и VKO.
Серверное API: важно разделять парсинг, криптографию, доверие и политики, вести воспроизводимый журнал и ограничивать недоверенный ASN.1-ввод; см. модель угроз.