ПМИ_реестры_сертификатов_УКЭП_А.2_v01_draft

А.2 Проверка создания распределённых реестров данных о сертификатах УКЭП и событиях жизненного цикла сертификатов УКЭП

Настоящая методика обеспечивает проверку реализации требований, изложенных в ЧТЗ п. 4.2.2, в соответствии с пунктами /4.2.2.1, 4.2.2.5, 4.2.2.11 Заявки № ИЭП-1.

Проверки выполняются вызовами методов REST API и наблюдением базы глобального состояния. Во всех шагах проверок действует единственная роль — демонстрирующий; иные роли не предусмотрены. Вызовы методов приватного канала сертификатов УЦ выполняются от имени УЦ-владельца канала; вызовы методов публичного канала — от имени участника канала, имеющего доступ на чтение. Функции доступны в среде развёртывания; IP-адрес среды указывается при подготовке испытаний и приводится в протоколе испытаний (Приложение Б).

Предварительные условия: развёрнут тестовый стенд; развёрнуты каналы квалифицированных сертификатов (канал аккредитации и сертификатов ГУЦ, приватный канал сертификатов ГУЦ, приватный канал квалифицированных сертификатов АУЦ) и публичный канал сертификатов УЦ; демонстрирующему предоставлены тестовые сертификаты УКЭП (корневой сертификат ГУЦ, промежуточный сертификат АУЦ, конечные сертификаты УКЭП — корректные и с заведомыми нарушениями формата), ключ доступа к REST API и учётные данные для подключения к базе глобального состояния (DBeaver).

А.2.1 Проверка создания записи о сертификате УКЭП в приватном канале

Проверка открывает сценарий испытаний сертификатов УКЭП: к её выполнению запись о тестовом сертификате в реестре отсутствует, поэтому регистрация проводится на корректном сертификате УКЭП, выданном тестовым АУЦ, и созданная запись становится исходным состоянием реестра для всех последующих проверок. Подтверждается приём сертификата через REST API: корректный запрос обрабатывается, в ответе возвращается идентификатор записи вида «дата начала действия;hashTBS», а сам идентификатор используется далее во всех запросах сценария. Альтернативные шаги доказывают защиту от повторной регистрации и от пустого запроса: повторная регистрация того же сертификата отклоняется с кодом ошибки ERR-0721, пустой запрос — с кодом ERR-0010.

А.2.2 Проверка форматно-логического контроля сведений о сертификате УКЭП

Проверка подтверждает, что сведения о сертификате УКЭП при внесении подвергаются декодированию, парсингу и форматно-логическому контролю: некорректное транспортное представление сертификата отклоняется с соответствующим кодом ошибки, а нарушения требований к формату квалифицированного сертификата не блокируют регистрацию, но фиксируются перечнем предупреждений в записи о сертификате. Запрос с искажённой кодировкой BASE64 доказывает контроль транспортного представления; запрос с сертификатом, не содержащим обязательных для УКЭП расширений (например, certificatePolicies либо identificationKind), доказывает, что фоновая проверка формирует предупреждения QCERT_* и по завершении проверок поле isChecked принимает значение True. Предупреждения наблюдаются в записи о сертификате при проверке А.2.7.

А.2.3 Проверка проверки цепочки доверия и аккредитации издателя при внесении

Проверка опирается на записи реестра, созданные проверкой А.2.1, и подтверждает проверку цепочки доверия: для несамоподписанного сертификата родительские сертификаты запрашиваются в реестре аккредитации и сертификатов УЦ, а при их отсутствии регистрация отклоняется. Второй шаг подтверждает отличие УКЭП от УНЭП — обязательность проверки аккредитации издателя: для сертификата, выданного АУЦ, не имевшим действующей аккредитации на дату начала действия сертификата, формируется предупреждение QCERT_ISSUER_NOT_ACCREDITED_AT_ISSUANCE; для сертификата, чей издатель не был действителен на эту дату, — QCERT_PARENT_NOT_VALID_AT_ISSUANCE. Альтернативный шаг доказывает криптографическую проверку: сертификат с неверной электронной подписью отклоняется с кодом ошибки ERR-0722.

А.2.4 Проверка изменения статуса сертификата УКЭП

Проверка опирается на сертификат, зарегистрированный проверкой А.2.1 (событие «1» — начало действия сертификата), и проводит его по предусмотренным статусной моделью переходам: прекращение действия сертификата (событие «2» с указанием причины) и возобновление действия сертификата (событие «3»). Каждое изменение статуса фиксируется отдельным событием истории с очередным номером версии. Альтернативные шаги подтверждают форматно-логический контроль запроса и проверку допустимости перехода: запрос без времени вступления изменения в силу отклоняется с кодом ERR-0801, повторная передача изменения с теми же параметрами отклоняется как недопустимый переход с кодом ERR-0805 (идемпотентность). Сформированная цепочка событий используется далее при проверках статуса на дату и периодов действия (А.2.11, А.2.12).

А.2.5 Проверка логической отмены сертификата УКЭП

Проверка опирается на сертификат, зарегистрированный проверкой А.2.1. Подтверждается функция логической отмены: отмена не удаляет запись о сертификате, а устанавливает флаг logicalCancelFlag = True; отменённый сертификат переносится в публичный канал с флагом True (проверка А.2.9). Альтернативный шаг подтверждает обработку некорректного идентификатора: запрос отмены с идентификатором ошибочного формата отклоняется с кодом ERR-0731, повторная отмена — с кодом ERR-0730.

А.2.6 Проверка получения данных сертификатов по заданному фильтру в приватном канале

Проверка опирается на записи о сертификатах, накопленные проверками А.2.1–А.2.3, и подтверждает метод получения данных по заданному фильтру: по значению параметра фильтрации (например, ОГРН владельца) возвращается перечень идентификаторов сертификатов, удовлетворяющих фильтру, а по идентификатору сертификата — модель сведений о сертификате, объединённая с моделью истории. Тем самым подтверждается доступность сведений приватного канала владельцу канала.

А.2.7 Проверка ведения записи «Сертификат» в базе глобального состояния

Способ проверки: наблюдение базы глобального состояния (Описание решения, п. 3.1.1).

Предварительные условия: выполнены проверки А.2.1–А.2.3 (в приватном канале созданы записи о сертификатах, включая запись с предупреждениями); доступ к базе глобального состояния предоставлен.

Проверка подтверждает, что сведения о сертификатах УКЭП, принятые через REST API, доведены до распределённого реестра, а не ограничиваются ответом метода. Наблюдением записи о сертификате в базе глобального состояния подтверждается её структура: идентификатор записи, хэш TBS, uuid сертификата издателя, тип владельца, сведения из сертификата, исходный сертификат, флаги форматной проверки и логической отмены, перечень предупреждений и служебное поле времени создания. Запись с предупреждениями (результат проверки А.2.2) подтверждает доведение результатов форматно-логического контроля до реестра.

А.2.8 Проверка ведения истории изменения статуса сертификата

Способ проверки: наблюдение базы глобального состояния (Описание решения, п. 3.1.2).

Предварительные условия: выполнены проверки А.2.1, А.2.4 (в реестре присутствуют события «начало действия», «прекращение действия», «возобновление действия»); доступ к базе глобального состояния предоставлен.

Проверка опирается на события, сформированные запросами сценария (проверки А.2.1, А.2.4). Наблюдением записи истории подтверждается, что события не перезаписывают друг друга, а накапливаются в массиве истории, где каждое последующее событие получает очередной номер версии, — именно это обеспечивает восстановление статуса сертификата на любой момент времени. Идентификатор записи истории формируется как комбинация uuid сертификата и суффикса HIST. Сформированная история является основой для получения статуса сертификата на заданную дату (проверка А.2.11) и периодов действия (проверка А.2.12).

А.2.9 Проверка переноса сведений о сертификате УКЭП в публичный канал

Способ проверки: наблюдение базы глобального состояния публичного канала (Описание решения, п. 3.2.1).

Предварительные условия: выполнены проверки А.2.1, А.2.4, А.2.5 (в приватном канале имеются запись о сертификате, события изменения статуса и логически отменённый сертификат); доступ к базе глобального состояния предоставлен.

Проверка подтверждает автоматический перенос сведений из приватного канала в публичный канал сервисом-ретранслятором ЕСИА: в публичном канале создаётся запись о сертификате с усечённым составом полей — без персональных данных владельца и без самого сертификата, а события изменения статуса и логическая отмена переносятся в запись истории публичного канала. Тем самым подтверждается разделение данных между каналами, предусмотренное ЧТЗ п. 4.2.2.

А.2.10 Проверка получения истории статуса сертификата УКЭП

Проверка опирается на запись сертификата в публичном канале (проверка А.2.9) и подтверждает метод получения истории статуса: возвращаются все события изменения статуса сертификата, накопленные в публичном канале. Альтернативный шаг подтверждает обработку запроса по сертификату, отсутствующему в реестре: запрос отклоняется с кодом ошибки ERR-0729.

А.2.11 Проверка получения статуса сертификата УКЭП на заданный момент времени

Предварительные условия: выполнены проверки А.2.1–А.2.5, А.2.9 (сформированы история изменения статуса тестового сертификата и запись в публичном канале); в реестре аккредитации и сертификатов УЦ имеются сведения об аккредитации УЦ-издателя.

Проверка подтверждает представление статуса сертификата УКЭП на заданный момент времени: статус определяется по истории событий (для даты проверки выбирается запись с максимальным updatedAt, не превышающим дату проверки), при этом — в отличие от сертификатов УНЭП (проверка А.3.11) — дополнительно запрашивается статус аккредитации издателя на дату начала действия сертификата, и итоговый статус учитывает и статусы сертификатов цепочки доверия, и статус аккредитации. Возвращаются сведения по проверяемому сертификату, промежуточному и корневому сертификатам цепочки, статус секретного ключа и итоговый статус.

А.2.12 Проверка получения периодов действия сертификата УКЭП

Предварительные условия: сформирована история изменения статуса тестового сертификата (проверки А.2.1, А.2.4); в реестре аккредитации и сертификатов УЦ имеются сведения об аккредитации УЦ-издателя.

Проверка завершает сценарий и подтверждает представление периодов действия сертификата: периоды вычисляются по истории изменения статуса и пересечению периодов действия сертификатов цепочки доверия, при этом для сертификатов УКЭП — с учётом статуса аккредитации издателя: если аккредитация не действовала на дату начала действия сертификата, периоды действия отсутствуют. Результат подтверждает, что сведения, последовательно внесённые в реестр запросами сценария, доступны потребителям в сводном виде.