ЧТЗ_реестры_сертификатов_УНЭП_4.2.3_v01_draft

4.2.3 Создание распределённых реестров данных о сертификатах УНЭП и событиях жизненного цикла сертификатов УНЭП

Работы выполняются в соответствии с пунктами /4.2.2.1, 4.2.2.5, 4.2.2.11 Заявки № ИЭП-1 «Создание реестра сертификатов ключей проверки электронной подписи на базе технологии распределённого реестра».

В отличие от сертификатов УКЭП (п. 4.2.2), ведение сертификатов УНЭП имеет особенности, определяющие состав каналов распределённого реестра, перечень выполняемых проверок и содержание структур данных. Сведения о сертификатах УНЭП размещаются в отдельных каналах инфраструктуры Госключ: канал сертификатов издателей Госключ предназначен для регистрации корневых и подчинённых сертификатов издателей, приватный канал неквалифицированных сертификатов Госключ — для регистрации сертификатов конечных пользователей. Издатель сертификата УНЭП идентифицируется по значению атрибута commonName (CN), а не по ОГРН: издатели Госключ могут не иметь ОГРН, вследствие чего поле issuerOGRN при переносе сведений о сертификате УНЭП в публичный канал сертификатов УЦ остаётся пустым. Вместо типа владельца сертификата (ownerType), определяемого для сертификатов УКЭП, для сертификатов УНЭП определяется тип сертификата — ROOT_CA (корневой), SUB_CA (промежуточный) или END_ENTITY (конечного пользователя), — по которому применяются профильные проверки форматно-логического контроля с кодами UNQCERT_*; жёсткие проверки критичности расширений, предусмотренные для сертификатов УКЭП, в отношении сертификатов УНЭП не выполняются. Проверка полномочности издателя по ОГРН и проверка аккредитации издателя не выполняются ни при внесении сведений о сертификате УНЭП, ни при определении статуса сертификата на заданную дату и периодов его действия: поиск сертификатов цепочки доверия выполняется по реестру сертификатов издателей Госключ (для сертификатов УКЭП — по реестру аккредитации и сертификатов УЦ), статус определяется по истории изменения статуса сертификата и по сертификатам цепочки доверия, а признак accreditationStatus не формируется. Необходимость ведения сертификатов УНЭП в отдельных каналах обусловлена различием нормативного регулирования: требования к форме квалифицированного сертификата ключа проверки электронной подписи жёстко урегулированы приказом ФСБ России от 27 декабря 2011 г. № 795 «Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи» и изменяются редко, тогда как регулирование сертификатов УНЭП является менее детальным: требования к ним установлены Правилами создания и использования сертификата ключа проверки усиленной неквалифицированной электронной подписи в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме, утверждёнными постановлением Правительства Российской Федерации от 1 декабря 2021 г. № 2152, и изменяются часто и непредсказуемо. Поэтому чейнкод каналов сертификатов УНЭП должен допускать определённую гибкость — как в составе выполняемых проверок, так и в содержании структур данных, — а совместное ведение сертификатов УКЭП и УНЭП в общих каналах распределённого реестра сопряжено с высокими рисками: изменения слабо урегулированной части требований затрагивали бы жёстко урегулированную часть и наоборот, а каждая доработка общего чейнкода требовала бы повторной проверки и приёмки функциональности, изменения которой не предусматривались.

Назначение работ. Ведение в распределённых реестрах данных о неквалифицированных сертификатах ключей проверки электронной подписи, созданных в соответствии с Правилами, утверждёнными постановлением Правительства Российской Федерации от 01.12.2021 № 2152 (далее — сертификаты УНЭП), и о событиях их жизненного цикла. Сертификаты УНЭП выпускаются в инфраструктуре Госключ и не требуют проверки аккредитации издателя: в отличие от сертификатов УКЭП (п. 4.2.2), у сертификатов УНЭП не применяются проверка полномочности издателя по ОГРН и проверка аккредитации издателя, а статус сертификата на заданную дату определяется только по истории событий сертификата без обращения к реестру аккредитации.

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

Границы требования. В рамках реализации требования не предусмотрено:

• ведение сведений о сертификатах УКЭП (выполняется в рамках п. 4.2.2);

• ведение сведений об аккредитации удостоверяющих центров (выполняется в рамках п. 4.2.1);

• изменение функциональности ЕПГУ и ИС ГУЦ (и ЕСИА).

Требования к функциям. В рамках данного требования необходимо:

1. Реализовать ведение в приватных каналах неквалифицированных сертификатов записей о сертификатах УНЭП с составом полей согласно п. 4.2.2.1 (модель сведений о сертификате в приватном канале для сертификатов УНЭП идентична модели для сертификатов УКЭП).

2. Реализовать процесс внесения сведений о сертификате УНЭП, обеспечивающий: приём сертификата в кодировках PEM и DER; парсинг сертификата; проверку существования сертификата и поиск сертификатов цепочки доверия в реестре сертификатов издателей Госключ; форматную проверку сертификата; проверку уникальности; криптографическую проверку электронной подписи сертификата; полную криптографическую проверку цепочки доверия и статуса отзыва; запрос списка отозванных сертификатов из локального хранилища; регистрацию сертификата с созданием записи и события «начало действия сертификата»; возврат идентификатора записи. В отличие от процесса внесения сведений о сертификате УКЭП, проверка аккредитации издателя не выполняется, а тип канала регистрации определяется по настроечной политике канала: для канала с типом «неквалифицированный» применяются проверки неквалифицированных сертификатов.

3. Обеспечить форматно-логический контроль сведений о сертификате УНЭП: проверки парсинга с ограничениями согласно п. 4.2.2.1, фоновые семантические проверки (общие для сертификатов обоих типов) и обязательные для сертификатов УНЭП проверки с формированием перечня предупреждений согласно таблице 1.

4. Обеспечить ведение истории изменения статуса сертификата и статусной модели сертификата — для сертификатов УНЭП состав полей истории, события и причины изменения статуса, правила аннулирования и таблица допустимых переходов идентичны приведённым в п. 4.2.2.2 для сертификатов УКЭП.

5. Реализовать функцию изменения статуса сертификата с проверкой допустимости перехода по статусной модели, идемпотентностью и возвратом кодов ошибок (коды ошибок — согласно п. 4.2.2.2).

6. Реализовать функцию логической отмены сертификата.

7. Реализовать метод получения данных сертификатов по заданному фильтру в приватном канале неквалифицированных сертификатов.

8. Обеспечить перенос сведений о сертификатах УНЭП и событиях их жизненного цикла в публичный канал сертификатов УЦ с составом полей согласно п. 4.2.2.3 (состав записи в публичном канале для сертификатов УНЭП идентичен составу для сертификатов УКЭП; поле issuerOGRN для сертификатов УНЭП, издатель которых не имеет ОГРН, пустое).

9. Реализовать представления данных о статусе сертификата УНЭП: историю статуса сертификата, статус сертификата на заданный момент времени, периоды действия сертификата, — без учёта статуса аккредитации издателя (п. 4.2.3.4).

10. Обеспечить формирование идентификаторов записей о сертификатах единым механизмом (п. 4.2.2.5; тип актива для НСКПЭП — значение 3).

4.2.3.1 Требования к ведению сведений о сертификатах УНЭП в приватных каналах

Доступ к чтению и записи в приватных каналах неквалифицированных сертификатов имеют УЦ-владелец канала и ЕСИА. Каналы неквалифицированных сертификатов: канал сертификатов издателей Госключ (регистрация корневых и подчинённых сертификатов издателей Госключ) и приватный канал неквалифицированных сертификатов Госключ (регистрация сертификатов конечных пользователей). Допустимые параметры издателя для каналов приведены в таблице 2.

Внесение сведений о сертификате УНЭП выполняется методом создания записи о сертификате в приватном канале: POST /certificate/goskey/create — для канала сертификатов издателей Госключ, POST /certificate/unqual/create — для приватных каналов неквалифицированных сертификатов. На вход метода подаётся сертификат, на выходе возвращается идентификатор вида YYYY-MM-DDTHH:MM:SSZ;hashTBS. Последовательность процесса внесения сведений — как для сертификатов УКЭП (п. 4.2.2.1), со следующими отличиями:

• проверка существования сертификата и поиск родительских сертификатов цепочки доверия выполняются в реестре сертификатов издателей Госключ (у сертификатов УКЭП — в реестре аккредитации и сертификатов УЦ);

• проверка полномочности издателя по ОГРН и проверка аккредитации издателя на дату начала действия сертификата не выполняются;

• по завершении внесения сведений в приватный канал запускается процедура переноса сведений в публичный канал неквалифицированных сертификатов (каналы: канал сертификатов издателей Госключ, приватный канал неквалифицированных сертификатов).

Состав обязательных для сертификатов УНЭП проверок и предупреждений приведён в таблице 1.

Таблица 1. Предупреждения форматно-логического контроля сертификатов УНЭП

Таблица 2. Каналы неквалифицированных сертификатов и допустимые параметры издателя

Коды ошибок создания записи о сертификате в приватном канале — ERR-0010, ERR-0701 … ERR-0728 (состав и расшифровка — как в п. 4.2.2.1, таблица 4).

4.2.3.2 Требования к ведению событий жизненного цикла сертификатов УНЭП

История изменения статуса сертификата УНЭП ведётся с составом полей и по статусной модели, идентичным приведённым в п. 4.2.2.2 (события 0 — аннулирование, 1 — начало действия, 2 — прекращение действия, 3 — возобновление действия; причины отзыва; правила аннулирования; таблица допустимых переходов).

Изменение статуса сертификата выполняется методами POST /certificate/goskey/status-update (канал сертификатов издателей Госключ) и POST /certificate/unqual/status-update (приватные каналы неквалифицированных сертификатов) с указанием идентификатора сертификата (cert), времени вступления изменения в силу (updatedAt) и события (event). Коды ошибок изменения статуса — ERR-0010, ERR-0729, ERR-0801 … ERR-0805 (п. 4.2.2.2).

Логическая отмена сертификата выполняется методами POST /certificate/goskey/certificate-cancel и POST /certificate/unqual/certificate-cancel с указанием идентификатора сертификата; коды ошибок — ERR-0010, ERR-0730.

Метод получения данных сертификатов по заданному фильтру в приватном канале неквалифицированных сертификатов: GET /certificate/unqual/search?param=Значение для поиска, где param принимает значения: commonName, OGRN, SNILS, INN, INNLE, OGRNIP; фильтрация выполняется по равенству структур. Получение сведений об указанном сертификате: GET /certificate/unqual/{YYYY-MM-DDTHH:MM:SSZ;hashTBS}/info?logicalCancelFlag=False; при отсутствии флага поиска выдаётся информация по всем записям о сертификате в реестре.

4.2.3.3 Требования к ведению сведений о сертификатах УНЭП в публичном канале

Состав записи о сертификате в публичном канале сертификатов УЦ, состав записи истории и порядок переноса сведений сервисом-ретранслятором ЕСИА — как в п. 4.2.2.3. Для сертификатов УНЭП, издатель которых не имеет ОГРН, поле issuerOGRN пустое. Перенос данных в публичный канал неквалифицированных сертификатов применяется для каналов: канал сертификатов издателей Госключ; приватный канал неквалифицированных сертификатов.

4.2.3.4 Требования к представлению данных о статусе сертификатов УНЭП

Представления данных о статусе сертификата УНЭП предоставляются через программный интерфейс публичного канала сертификатов УЦ:

• получение истории статуса сертификата: GET certificate-validity/unqual/all?cert=YYYY-MM-DDTHH:MM:SSZ;hashTBS; возвращается история изменения статуса сертификата; коды ошибок — ERR-0010, ERR-0729;

• получение статуса сертификата на заданный момент времени: GET certificate-validity/unqual/by-date?cert=YYYY-MM-DDTHH:MM:SSZ;hashTBS&time='YYYY-MM-DDTHH:MM:SSZ'; возвращается результат по каждому сертификату цепочки доверия (target_cert, sub_ca, root_cert): certId, localStatus (status, details, date, reason), статус секретного ключа (privateKeyStatus) и итоговый статус (resultStatus). Статус сертификата на заданную дату определяется по истории изменения статуса сертификата (запись с максимальным updatedAt, не превышающим дату проверки). Итоговый статус: если у всех сертификатов цепочки localStatus.status = true, то resultStatus = true; если хотя бы у одного localStatus.status = false, то resultStatus = false. В отличие от сертификатов УКЭП, обращение к реестру аккредитации не выполняется и поле accreditationStatus не определяется; коды ошибок — ERR-0010, ERR-0729;

• получение периодов действия сертификата: GET certificate-validity/unqual/periods?cert=YYYY-MM-DDTHH:MM:SSZ;hashTBS; периоды действия вычисляются по истории изменения статуса и пересечению периодов действия сертификатов цепочки доверия (правила вычисления — как в п. 4.2.2.4), без проверки статуса аккредитации издателя; коды ошибок — ERR-0010, ERR-0729.