ГОСТ-сертификаты: X.509, CRL, OCSP и отметки времени

Подпись на алгоритме ГОСТ не равнозначна доверенной подписи. Программа должна проверить сертификат подписанта, цепочку доверия, имя и назначение ключа, время действия, а также статус отзыва сертификата. Российские рекомендации для этих операций обновлялись и после перехода к ГОСТ 2012.

Четыре первоисточника для современного PKI

Документ	Что регулирует	Статус в Росстандарте
Р 1323565.1.023-2022	ГОСТ Р 34.10/34.11-2012 в сертификатах X.509, CRL и запросах PKCS#10	Действует; заменяет редакцию 2018 года
Р 1323565.1.059-2024	Получение актуального статуса сертификата через OCSP	Действует с 1 января 2025 года
Р 1323565.1.044-2022	Применение российских криптоалгоритмов в протоколе штампов времени (TSP)	Действует с 1 января 2023 года
RFC 9215	Международно опубликованные идентификаторы и кодировки ГОСТ-2012 в X.509	Informational, март 2022 года

Практическая модель проверки

Сначала удостоверяемся, что подпись математически соответствует открытому ключу. Затем выясняем, доверяем ли удостоверяющему центру, выдавшему сертификат, соответствует ли сертификат назначению и указанной личности. После этого проверяем, не был ли сертификат отозван и на какой момент времени нужно оценивать его действительность.

CRL — подписанный список отозванных сертификатов. OCSP — протокол запросов о статусе конкретного сертификата. Нельзя говорить «есть ГОСТ X.509, значит есть ГОСТ OCSP»: подписи ответов OCSP, допустимые идентификаторы, цепочки и политика проверки должны соответствовать отдельно согласованному профилю.

Протокол TSP позволяет получить доказательство существования данных к определённому времени. Однако метка времени и момент проверки статуса отзыва — разные сущности. Для долгосрочной верификации электронных документов важно сохранять нужные свидетельства и учитывать правила проверки на прошлый момент.

Безопасный просмотр сертификата

openssl x509 -in certificate.pem -noout -text
openssl x509 -in certificate.pem -noout -dates -subject -issuer -serial

Команды показывают поля, но не доказывают, что нужные ГОСТ-алгоритмы доступны для криптографической проверки, а доверенная цепочка и статус отзыва установлены. Для DER используйте -inform DER; передаваемые файлы должны быть доступны оператору законно.

В НАЙС.ОС практические процедуры размещены в разделе сертификатов и разделе доверия; здесь приведены основания выбора профиля.

Чек-лист межвендорной совместимости

• Одинаковы ли параметры ГОСТ Р 34.10-2012 и идентификаторы signatureAlgorithm/SubjectPublicKeyInfo?
• Правильно ли читаются байтовый порядок координат ключа и подписи, а также DER-обёртка?
• Доверен ли корневой УЦ и имеются ли промежуточные сертификаты?
• Учитываются ли keyUsage, extendedKeyUsage, basicConstraints и имя субъекта?
• Есть ли действующий и проверенный ответ OCSP либо подходящий CRL?
• Нужен ли TSP и согласован ли источник доверенного времени?

Доверенная цепочка: разные операции и их порядок

сертификат конечного узла
    ├── корректная ГОСТ-подпись и параметры открытого ключа
    ├── соответствие имени/назначения (SAN, KU, EKU)
    ├── построение пути: промежуточный CA → доверенный корневой CA
    ├── проверки времени/ограничений/политики
    └── статус: CRL или OCSP
             |
             v
       принято либо отклонено

ГОСТ-сертификат — это X.509-объект с определёнными OID и кодировками, а не самостоятельная гарантия доверия. RFC 5280 определяет общую обработку пути и CRL; RFC 9215 дополняет его идентификаторами ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012. Российские рекомендации содержат национальный профиль: при межвендорном обмене необходимо сверить именно требования обеих сторон.

CRL: что означает действительная проверка

CRL имеет издателя, период действия thisUpdate/nextUpdate, номер CRL и список отозванных серийных номеров. Корректная цифровая подпись CRL ещё не означает, что проверяется нужный сертификат нужного издателя; важны сопоставление ID, полномочия подписанта CRL и временная актуальность. Строгая политика должна отказывать при невозможности получить достоверный статус, если у проверяющей стороны нет допустимой действующей CRL.

OCSP: что нельзя выводить из поддержки X.509

OCSP — ответ о состоянии конкретного сертификата, подписанный уполномоченным ответчиком. Проверяются nonce/привязка запроса, серия и CA, полномочия ответчика, подпись, сроки, допустимость good/revoked/unknown. Не следует считать good неограниченной по времени гарантией и подменять неполученный статус согласием с сертификатом. ГОСТ OCSP как отдельный профиль требует тестов серверной и клиентской частей.

TSP и долгосрочная проверка

Отметка времени свидетельствует, что определённый хэш существовал не позднее утверждаемого момента, при условии доверия к службе времени. Она не равна «сертификат был действителен на тот момент». Для архивной проверки электронных документов необходимы доказательства подписи, статуса сертификата и времени, согласованные с политикой.

Подтверждённый сценарий НАЙС.ОС 5.2

Системный strongswan-6.1.0-1.niceosc5 проверен с ГОСТ-512 CA, сертификатами двух узлов, CRL 0x1002 и revocation = strict: действующий сертификат был принят, отозванный — отвергнут, отсутствие CRL — fail-closed, CRL по HTTPS получена самим charon через curl. При этом автоматический online OCSP и постоянное пересмотрение действующих SA не заявлены. Подробности в практике IKEv2 RPM.

Ключевые вопросы безопасности

Чем защищён ключ УЦ? Где хранятся сертификаты и актуальные CRL? Можно ли подменить CRL старой версией? Как распространяются сведения об отзыве? Какую политику применять при недоступности источника? Как доказывается отзыв для уже открытого соединения? Эти вопросы не решает сама подпись. Паспорт угроз, управление ключами и модель CMS-доверия дополняют нормативные документы.

Первичные протоколы: RFC 5280, RFC 6960, RFC 3161, RFC 9215. Национальные профильные документы перечислены выше; при использовании проверяйте статус каждого в карточке Росстандарта.

Источники

Карточки Р 1323565.1.023-2022, Р 1323565.1.059-2024, Р 1323565.1.044-2022, RFC 9215, RFC 5280.