Проверка доверия: сертификаты, время, CRL и OCSP в ГОСТ CMS¶

Цель главы: разделить корректную математическую ГОСТ-подпись, доверие к X.509-сертификату и решение прикладной политики о приёме электронного документа. Для проверяющего эти результаты связаны, но не тождественны.

Модель валидации¶

[CMS + исходный документ]
         │
         ▼
[ГОСТ-подпись] ── ошибка ──> FAIL: crypto
         │ PASS
         ▼
[Сертификат подписанта и цепочка X.509] ── ошибка ──> FAIL: trust
         │ PASS
         ▼
[Время, keyUsage / EKU, CRL / OCSP] ── ошибка ──> FAIL: validity
         │ PASS
         ▼
[Политика применения: алгоритм, профиль, роль, статус]
         │
         ▼
[Решение о принятии] ──> журнал доказательств

Нельзя выводить доверие из сообщения signature verified без проверки цепочки, ограничений сертификата и статуса отзыва. Общая PKIX-модель изложена в RFC 5280; кодировки ГОСТ-2012 в сертификатах и CRL — в RFC 9215. Для контейнера используется RFC 5652 §5.

Что делает цепочка сертификатов¶

Конечный сертификат содержит открытый ключ подписанта и ограничения его применения. Промежуточный CA удостоверяет следующий сертификат, корневой доверенный CA задаётся в доверенном хранилище проверяющей стороны. Помещение Certificate внутрь SignedData.certificates лишь облегчает доставку: эта запись не переносит доверие автоматически.

При построении цепочки важны basicConstraints, keyUsage, ограничения имён, алгоритмов, сроков и политики. Например, keyCertSign относится к удостоверению сертификатов, а digitalSignature — к соответствующим операциям конечного сертификата; интерпретировать их надо по применимому профилю. Смотрите OpenSSL PKI, корневой CA и ключевую политику.

Время подписи и доказательство существования¶

Поле signingTime, включённое в signedAttrs, может быть криптографически связано с подписью, но оно передаётся самим подписантом. Это не равнозначно независимой доверенной отметке времени. Для временного штампа TSP предусмотрен RFC 3161. Для ретроспективной проверки нужен заранее установленный регламент: какой момент считается временем подписи, какие статусы сертификатов допустимы и как сохранять свидетельства проверки.

Проверка отзыва — три состояния¶

Состояние	Как интерпретировать
`good` при достоверном актуальном источнике	Статус отзыва допускает дальнейшую проверку; это ещё не общий PASS
`revoked`	Сертификат отозван; по строгой политике использование отклоняется
`unknown` / недоступен источник	Нельзя считать сертификат автоматически действительным; решение определяет явно установленная политика

CRL описан в RFC 5280, OCSP — в RFC 6960. OCSP и CRL — разные механизмы, к которым предъявляются разные требования доступности, свежести и подписи ответов. Не следует переносить результаты проверки CRL системного strongSwan на OpenSSL CMS — это независимые приложения.

Режимы отказа¶

Strict / fail-closed: при невозможности установить статус сертификата операция не считается успешной. Повышает стойкость к неизвестному отзыву, но повышает зависимость от инфраструктуры CA.
Soft-fail: определённые сбои проверки статуса могут быть допущены политикой. Должны документироваться и быть видимы в результате.
Offline validation: требует контролируемых, свежих и подписанных материалов доверия; простого кэша недостаточно для заявлений об актуальном статусе.

Связь с НАЙС.ОС¶

На испытанной НАЙС.ОС 5.2 системный strongSwan IKEv2 прошёл строгие сценарии отсутствующей, отозванной и недоступной по HTTPS CRL. Но эти испытания не подтверждают автоматическую реализацию идентичной политики во всех CMS-клиентах. Для каждого клиента отдельно проверяйте версию RPM, конфигурацию доверия, требуемый алгоритм и реальные ошибки.

Для воспроизводимой проверки контейнера пользуйтесь диагностикой CMS и матрицей совместимости, а для теории подписи — SignedData.

Первоисточники¶

Далее: модель угроз → проверка контейнеров.

Профиль проверки: пример требований для эксплуатации¶

Ниже приведён образец регламента, а не автоматическое поведение какой-либо установленной программы. Его нужно адаптировать к назначению документа и требованиям организации:

Принимать только явно разрешённые семейства ГОСТ, наборы параметров и форматы подписей; отклонять неизвестные OID.
Считать сертификат допустимым только после успешного построения цепочки до заданного локального CA, проверки подписи цепочки и необходимых ограничений X.509.
Проверять срок действия относительно выбранного политикой момента; отдельно хранить основание выбора момента (текущая дата, доверенный TSP, архивный профиль).
Для отзыва принимать только ответ доверенного источника, проверенный по подписи и сроку; фиксировать используемую CRL/OCSP и её временные поля.
При недоступности источника статуса выдавать отдельный код REVOCATION_UNAVAILABLE, а не маскировать проблему под SIGNATURE_INVALID.
Для нескольких подписантов зафиксировать требование ко всем подписям или выбранному набору; нельзя выбирать «любую годную» без политики.
Журналировать результат каждой стадии раздельно и исключать из логов закрытые ключи и защищённые данные.

Как связаны CRL и OCSP¶

CRL обычно публикует список отозванных сертификатов и сведения о сроке его актуальности (thisUpdate, nextUpdate). Проверяющая сторона сопоставляет удостоверяющий центр и серийный номер сертификата с записью списка. Подпись CRL защищает от подмены, но без проверки свежести документ может использовать устаревшие сведения. OCSP позволяет запросить статус отдельного сертификата у ответчика; при этом необходимо установить полномочия подписанта OCSP-ответа и проверить его временную применимость. Это разные способы получения доказательств статуса.

Практическая ситуация: сертификат подписанта отозван после времени создания документа. Верификация ранее выпущенной подписи требует политики ретроспективной проверки и источников достоверного времени. Одна текущая CRL без временного регламента не отвечает на все вопросы долгосрочной сохранности доказательств. Не обещайте архивную достоверность подписи без явно определённого набора свидетельств.

Контрольный лист администратора¶

Вопрос	Что нужно иметь
Где список доверенных CA?	Путь и способ штатного обновления trust store
Кто публикует CRL/OCSP?	Проверенный URL, сертификат и правила доступа
Что происходит при ошибке сети?	Документированный strict/soft-fail
Чем подтверждается время?	Политика и, если нужно, доверенное свидетельство TSP
Что делать с legacy-алгоритмами?	Отдельные правила чтения и создания новых объектов
Как проверить результат?	Сохранённые `parse / crypto / trust / policy` и воспроизводимый тест