Испытания совместимости ГОСТ: матрица и протокол результата¶
Шаблон независимых проверок двух реализаций и критерии корректного заявления о совместимости.
Документация ПО — НАЙС.ОС CLOUD. Это самостоятельная учебно-справочная статья. Команды приведены для изучения и диагностики; операции с ключами, дисками и действующими сервисами выполняют только после резервного копирования и проверки назначения.
Почему нужен двусторонний тест¶
Если продукт A может проверить подпись B, это ещё не означает, что B сможет проверить подпись A. Сообщения могут отличаться по структуре CMS, алгоритмическим параметрам и набору атрибутов. Аналогично шифрование документа для одного получателя не доказывает корректную обработку нескольких получателей. Поэтому испытания проводятся для обеих сторон и для положительных/отрицательных сообщений.
Матрица испытаний¶
| Функция | A → B | B → A | Негативные тесты |
|---|---|---|---|
| X.509 | Импорт и разбор сертификата | Импорт и разбор сертификата | Неверные параметры и повреждённый DER |
| Подпись файла | Подпись → проверка | Подпись → проверка | Изменённый байт исходного файла |
| CMS SignedData | Attached/detached | Attached/detached | Повреждение signedAttrs |
| CMS EnvelopedData | Шифрование для B | Шифрование для A | Неправильный RecipientInfo |
| PKCS#12 | Экспорт/импорт разрешённого ключа | Обратный импорт | Неверный пароль/неподдерживаемый OID |
| TLS | Клиент A → сервер B | Клиент B → сервер A | Неподдерживаемый профиль/сертификат |
| IKEv2/ESP | Шлюз A → шлюз B | Обратные параметры и rekey | Неверный transform/сертификат |
| DNSSEC | Подпись A → валидация B | Подпись B → валидация A | Неверный RRSIG/DS |
Требуемые данные испытания¶
- Точное название и версия продуктов, версии библиотек и операционной системы.
- Идентификатор исходного профиля и раздел первоисточника.
- OID, размеры ключа, набор параметров и сериализация.
- Комплект публичных учебных фикстур с SHA-256.
- Команды/действия, журнал соединения и описание результата.
- Отрицательные тесты и разбор ожидаемых отказов.
- Подпись/утверждение протокола ответственной группой и дата.
Статусы в документации¶
Используйте планируется, реализовано, локально испытано, межвендорно испытано, одобрено для конкретного применения как независимые состояния. Последний статус не вытекает из первых четырёх: требования к СКЗИ и область действия сертификата оцениваются отдельно.
Шаблон карточки протокола¶
Профиль: ГОСТ-CMS/X.509, RFC 9215 + применимые требования
Реализация A: имя / версия / Provider
Реализация B: имя / версия / Provider
Ключ: тип, длина, OID параметров (без секрета)
Операция: A создаёт, B проверяет
Фикстуры: SHA-256 исходного документа, подписи, сертификата
Результат: PASS / FAIL / SKIP
Негативные тесты: PASS / FAIL / SKIP
Ограничения: известные отличия или неполное покрытие
Только реальные карточки после стенда можно использовать для внешних заявлений об «официальной совместимости». Наличие RFC и одинакового алгоритма — лишь предпосылка.
Первоисточники и дополнительное чтение¶
- RFC 9215 — ГОСТ-2012 в сертификатах и списках отзыва.
- Р 1323565.1.025-2019 — российские рекомендации по CMS.
- RFC 9367 — ГОСТ в TLS 1.3.
- RFC 9227 — ГОСТ-профиль ESP и IKEv2.