Соответствие приказам МИИ РК №522/НҚ и №500/НҚ (в силе с сентября 2026)

[eudj1n]

Сверка v4 с двумя новыми приказами и приведение кода в соответствие.

• №522/НҚ от 28.08.2026 (Минюст 31.08.2026 №39747, в силе с 11.09.2026) — Правила выдачи, хранения и отзыва сертификатов открытого ключа ЭЦП. Регулирует удостоверяющие центры, к нам применимы только профили сертификатов, СОС, OCSP- и TSP-сертификатов. Разбор — rules-2026-compliance.md.
• №500/НҚ от 21.08.2026 (Минюст 24.08.2026 №39672) — Правила формирования и проверки подлинности ЭЦП. Профильный для сервиса документ: описывает саму процедуру. Разбор — rules-2026-verification-compliance.md.

По существу мы обоим соответствовали: профили кодифицируют то, что НУЦ уже выпускает (сверено с ключами NCA SDK 2.0 из репозитория), а костяк процедуры проверки был на месте. Ниже — то, что расходилось.

Профили сертификатов (№522/НҚ)

• Разностный СОС мог подменить полный. Профили структур 13/14 маркируют delta расширением freshestCRL 2.5.29.46, critical вместо deltaCRLIndicator. Расширение внесено в allowlist критичных (указатель охват списка не сужает), а base теперь ищется только среди списков не с delta-эндпоинта: иначе delta без индикатора выигрывала бы отбор по CRLNumber (на бою 57 725 против 1 346), и всё, отозванное только в полном списке, вернулось бы как ACTIVE. Провенанс определяется каталогом кэша, поэтому скачанное по freshestCRL лежит в отдельном crl/<type>/ondemand-delta — иначе та же дыра открывалась бы через on-demand путь.
• Ответ-ошибка OCSP больше не UNKNOWN, а UNAVAILABLE. Он не подписан и о сертификате ничего не сообщает (RFC 6960 §4.2.1), тогда как UNKNOWN в isValid фатален — tryLater от одного из двух обязательных теперь респондеров объявлял валидную подпись недействительной. Там же закрыт NPE на пустом теле ответа: он уходил мимо всех catch и давал 500 на весь verify.
• Зеркала (ocsp1, crl1) больше не удваивают работу. OCSP прекращает обход на первом авторитетном ответе; адреса CRL группируются по точкам распространения (внутри точки это один и тот же список, RFC 5280 §4.2.1.13) и качается первый сработавший.
• freshestCRL теперь читается — адрес delta НУЦ публикует именно там, и для издателя вне конфигурации мы работали на одном полном списке.
• Шаблоны «цифровая система» физлица и юрлица и «Казначейство — Клиент» добавлены в CertificateKeyUser; UID (OID цифровой системы), businessCategory (код клиента Казначейства) и DC (роль) — в CertificateSubject. Все они есть на тестовых ключах и молча выпадали. Попутно чинилось отчество: X500Principal.toString() печатает его как GIVENNAME, а разбор ждал только G, поэтому subject.lastName был пуст на всех сертификатах НУЦ.
• Дефолты: оба адреса респондеров НУЦ; NCANODE_CA_CRL_TTL 1440 → 720 (КУЦ обновляет свой СОС не реже раза в 24 часа).

Процедура проверки (№500/НҚ)

• Срок действия всей цепочки (п. 16), а не только непосредственного издателя: истечение любого звена — отрицательный результат. Обход идёт по уже проставленным issuerCertificate, поэтому лишних поисков не делает, и останавливается там, где издателя в бандле нет — всё из NCANODE_CA_URL считается настроенным якорем доверия (иначе ломалась бы проверка подписей старой ГОСТ-2004 иерархии).
• Истёкший CRL не даёт положительного вердикта (п. 18): новый исход EXPIRED в revocations[].result. Раньше список за пределами nextUpdate в режиме revocationCheck: ["CRL"] молча выдавал «не отозван» всё, что опубликовано после этой даты. Не фатален ровно тогда, когда авторитетный ACTIVE уже получен от OCSP — п. 16 разрешает проверять отзыв «посредством сервиса OCSP либо CRL».
• Назначение ключа должно допускать подпись (п. 16): keyUsage обязан разрешать digitalSignature либо nonRepudiation. Требование относится к сертификату подписывающего лица, поэтому включается параметром isValid(..., requireSigningKeyUsage = true) на путях проверки подписи; /x509/info, /pkcs12/info и verifyCerts описывают сертификат, а не проверяют подпись, и там оно не применяется — у CA-сертификатов НУЦ keyUsage = keyCertSign + cRLSign. Номер политики не enforce'им (условия задаёт УЦ и из сертификата не выводимы) — вместо этого публикуем certificates[].policies.
• Привязка signingCertificateV2 сверяется и обычным /cms/verify (п. 8), а не только AdES-путём.
• NCANODE_SIGN_CERT_CHECK — проверка сертификата подписанта перед подписанием (п. 4) во всех sign-путях, отказ 400 на непригодном ключе. Выключено по умолчанию: включение меняет поведение всех sign-эндпойнтов и добавляет OCSP-запрос на каждое подписание.

Сознательные расхождения (обоснования в rules-2026-verification-compliance.md): не требуем совпадения издателя TSA с издателем подписанта (п. 17.2 — иначе отвергали бы боевые RSA-метки НУЦ на ГОСТ-подписях), не требуем EKU OCSPSigning от самого CA (п. 19.5 — RFC 6960 §4.2.2.2 это разрешает, так НУЦ и отвечает), п. 19.6 читаем как «квитанция должна свидетельствовать о моменте проверки» (буквально невыполним).

Проверка

Тесты 467 → 504, coverage 90%. Эталонные подписи NCALayer прогнаны отдельно — 15/15 (боевая PKI отвечает через раз, при её молчании спека пропускается).

Совместимость

Старые эндпойнты работают как раньше. Новые поля аддитивные (policies, uid, businessCategory, domainComponent, EXPIRED, новые значения keyUser), openapi.yml обновлён. Два изменения поведения по умолчанию:

• истёкший CRL перестаёт давать положительный вердикт — это и есть требование п. 18;
• revocations[] может содержать меньше записей, чем адресов OCSP в AIA: обход прекращается на первом авторитетном ответе. До появления сертификатов с парой респондеров (с 11.09.2026) видимой разницы нет.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ThqBhEqRNDMuHx39ZRxqXo