Протокольные профили ГОСТ: карта слоёв и соответствующих RFC¶
Один и тот же криптографический алгоритм может применяться в разных протоколах с разными кодировками, ключевыми расписаниями и политиками отказа. Эта карта связывает базовые алгоритмы, профили, инфраструктурные службы НАЙС.ОС и подтверждённые тесты.
Матрица профилей¶
| Сценарий | Алгоритмические элементы | Протокольные первоисточники | Руководство НАЙС.ОС |
|---|---|---|---|
| Электронная подпись CMS | Стрибог, ГОСТ Р 34.10, DER/OID | RFC 5652, Р 1323565.1.025-2019 | CMS, теория |
| Сертификаты X.509 | ГОСТ подпись, CRL, цепочка доверия | RFC 5280, RFC 9215 | PKI |
| Перенос ключей PFX | PBKDF, шифр, контейнер, MAC | RFC 7292, 9337, 9548 | PKCS#12 |
| TLS 1.3 | MGM, подпись, key schedule | RFC 9846, RFC 9367 | TLS |
| TLS 1.2 | ГОСТ-профиль TLS 1.2 | RFC 9189 | TLS |
| IKEv2 и ESP | PRF HMAC Стрибог, GOST512, MGM-KTREE | RFC 7296, 9227, 9385 | strongSwan |
| DNSSEC | ГОСТ 2012 для DNSKEY/DS/RRSIG | RFC 9558 и 9906 | resolved |
| LUKS2 | Кузнечик-XTS (данные) | Режим XTS и формат LUKS2, не DEC | dm-crypt |
| CMC | CMS, PKCS#10, POP, RA/CA | RFC 10002, 10003, 10004 | CMS/PKI |
Почему матрица не является списком реализованных функций¶
В таблице строки описывают профили стандартов, а не автоматическую поддержку каждым установленным RPM. В НАЙС.ОС 5.2 испытан конкретный ГОСТ IPsec и ряд криптографических операций; для иных профилей может требоваться расширение библиотек или отдельное приложение. Например, возможность хэширования Стрибог в OpenSSL не означает реализацию механизма подписанного DNSSEC ответа в любом рекурсивном DNS-сервере.
Ветвящийся маршрут принятия решения¶
Нужно шифровать, подписывать или устанавливать защищённый канал?
├─ Подписывать документы -> CMS -> X.509 -> проверка статуса
├─ Шифровать документы -> EnvelopedData -> VKO/ключи -> получатели
├─ Соединять сети -> IKEv2/ESP -> ГОСТ Transform ID -> маршруты
├─ HTTP/API -> TLS 1.3 -> полное согласование профиля -> сертификаты
├─ Доверенный DNS -> DNSSEC -> DNSKEY/DS/RRSIG -> якорь
└─ Шифровать диск -> LUKS2 -> dm-crypt -> конкретный режим сектора
Для каждой ветки применяются собственные нормативные документы и измеряемые критерии. Нельзя переносить взаимную аутентификацию ГОСТ IKEv2 на вывод о совместимости ГОСТ TLS или CMS; общие примитивы не определяют формат сети и политику доверия.
Практические пределы каждого сценария¶
- CMS: математическая подпись ≠ полный доверенный документ; требуется контроль содержания, сертификата и времени.
- TLS: наличие EVP-алгоритма ≠ работающий на проводе cipher suite, key share и handshake.
- IKEv2: установленная IKE SA ≠ защита полезных IP-пакетов без CHILD SA.
- DNSSEC: подпись записей ≠ конфиденциальность DNS-запросов.
- LUKS2: XTS для данных ≠ вся контейнерная инфраструктура на ГОСТ.
- CMC: поддержка CMS-формата ≠ работающий клиент регистрации сертификатов.
Инженерные критерии в методике соответствия и обзоре ограничений.