Матрица совместимости ГОСТ CMS: структура, алгоритмы, испытания¶
Это практический контрольный список для технического задания и приёмки обмена документами между НАЙС.ОС и другой реализацией ГОСТ CMS. Таблица описывает методику; она не заявляет, что все комбинации уже поддержаны. Для проверенных фактов см. матрицу возможностей НАЙС.ОС.
Совместимость по слоям¶
| Слой | Проверяемое свойство | Документ |
|---|---|---|
| Внешний формат | DER / PEM / MIME; attached / detached | RFC 5652, RFC 8551 |
| Хэш | ГОСТ Р 34.11-94, Стрибог-256/512 | RFC 6986, RFC 4490 |
| Подпись | ГОСТ Р 34.10-2001, ГОСТ-2012/256 и /512 | RFC 7091, RFC 9215 |
| Защита содержимого | Выбранный шифр, режим, параметры | Р 1323565.1.025-2019 |
| Ключи получателя | RecipientInfo, VKO, UKM, упаковка CEK |
RFC 7836, RFC 5652 |
| Сертификаты | OID, кривая, X.509, KU/EKU | RFC 9215, RFC 5280 |
| Отзыв/время | CRL, OCSP, TSP, политика времени | RFC 5280, RFC 6960, RFC 3161 |
Матрица испытаний — заполнить реальными результатами¶
| Сценарий | A → B | B → A | Отрицательный сценарий | Статус |
|---|---|---|---|---|
ГОСТ-2012/256 SignedData attached |
— | — | Изменение одного байта | NOT TESTED |
ГОСТ-2012/512 SignedData detached |
— | — | Другой исходный документ | NOT TESTED |
| Исторический ГОСТ-2001 в CMS | — | — | Неизвестный OID/параметры | NOT TESTED |
EnvelopedData для 1 получателя |
— | — | Чужой private key | NOT TESTED |
EnvelopedData для нескольких |
— | — | Отсутствие нужного RecipientInfo |
NOT TESTED |
S/MIME multipart/signed |
— | — | Изменённая каноникализация | NOT TESTED |
| X.509/CRL/OCSP | — | — | Отозванный сертификат | NOT TESTED |
Значения PASS и FAIL добавляйте только с артефактами: SHA-256 входа, командой/версией пакета, stdout/stderr и именем внешней программы. Не переносите статусы из испытания IKEv2 (charon) в CMS: это разные части стека.
Где в НАЙС.ОС выполнять тесты¶
- OpenSSL CMS — разбор и криптографические операции.
- libksba: контейнеры CMS — интеграция с компонентами документа.
- GPGSM: X.509 и CMS — подпись, проверка и работа с сертификатами.
- Обмен с КриптоПро — двусторонний стенд.
- Проверка ошибок и доверие.
Договор интеграции¶
Перед публикацией API зафиксируйте схему JSON-ответов для каждого этапа: parse, signature, certificate_path, revocation, policy; реальные байты SignerInfo, messageDigest, алгоритмические OID; допустимые CMS-форматы; лимиты ресурса. Так результат проверки будет пригоден для расследования и повторного теста.
Далее: методика проверки → модель угроз.
Минимальный набор образцов¶
Для полноценного межвендорного испытания требуется набор проверенных образцов для разных классов данных. Одного файла .p7s недостаточно.
| Файл | Назначение | Что должен доказать |
|---|---|---|
clear.bin |
Исходные байты документа | Отсутствие скрытой перекодировки |
signed-attached.der |
Подпись с вложенным содержимым | Распознавание SignedData |
signed-detached.der + clear.bin |
Подпись с отдельным содержимым | Корректный messageDigest и DER атрибутов |
enveloped.der |
Зашифрованное сообщение | Обработка конкретного RecipientInfo |
chain.pem / DER |
Публичные сертификаты | Построение цепочки по принятой политике |
revoked.crl |
Тестовый подписанный список отзыва | Отрицательная проверка статуса |
bad-*.der |
Намеренно повреждённые копии | Гарантированный отказ по правильной причине |
Сформировать набор нужно в каждой стороне отдельно, а затем перекрёстно проверить. Для двухстороннего обмена сохраняйте отдельные журналы; пример PASS со стороны получателя не заменяет проверку в обратном направлении.
Согласование параметров перед интеграцией¶
Стороны должны заранее обменяться не закрытыми ключами, а описаниями формата. Требуются: допустимые кривые, поддерживаемые режимы хэширования, OID комбинаций, внутреннее представление ГОСТ-подписи, порядок полей и байтов, формат PEM/DER/SMIME, возможность detached-сообщений, профиль RecipientInfo, источник доверия и способ проверки отзыва. Предоставьте публичные демонстрационные сертификаты и эталонные контейнеры, не включая рабочие секреты.
Ведомость ошибок¶
Вместо строки «CMS ошибка» используйте классификацию:
FORMAT_UNSUPPORTED: неизвестный MIME, ASN.1 или CMS-тип.ALGORITHM_UNSUPPORTED: алгоритм/параметры известны спецификации, но отсутствуют в установленной реализации.SIGNATURE_BAD: арифметическая проверка подписи не прошла.CONTENT_MISMATCH: подписан другой набор байтов.CERT_UNTRUSTED: не построена допустимая цепочка.CERT_REVOKEDиREVOCATION_UNAVAILABLE: принципиально разные ситуации.DECRYPT_FAILED: не получен CEK или не завершена расшифровка.POLICY_DENIED: запрет по профилю, назначению или регламенту.
Эти коды — предлагаемый контракт приложения, а не стандартные значения OpenSSL или libksba. В реализации должны существовать тесты, привязывающие каждый код к наблюдаемому событию. Сопоставление входов и выходов удобнее вести по диагностике и модели угроз.