4 Требования к Системам

4.2 Требования к проводимым работам

4.2.1. Реализовать функцию взаимодействия с внешними информационными системами в части получения и передачи сведений о сертификатах УКЭП и о событиях жизненного цикла сертификатов УКЭП посредством прикладного программного интерфейса (API) для использования в высоконагруженном сервисе.

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

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

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

2. Обеспечить форматно-логический контроль сведений о сертификате УКЭП: проверки парсинга с ограничениями согласно таблице 1, фоновые семантические проверки и обязательные для сертификатов УКЭП проверки с формированием перечня предупреждений согласно таблице 2.

3. Реализовать функцию изменения статуса сертификата с проверкой допустимости перехода по статусной модели, идемпотентностью и возвратом кодов ошибок согласно таблице 4.

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

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

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

Внесение сведений о сертификате УКЭП выполняется методом создания записи о сертификате в приватном канале: POST /certificate/guc/create — для канала аккредитации и сертификатов ГУЦ, POST /certificate/qual/create — для приватных каналов квалифицированных сертификатов (!ai Дис: В-1). На вход метода подаётся сертификат (certificate), на выходе возвращается идентификатор вида YYYY-MM-DDTHH:MM:SSZ;hashTBS — конкатенация даты начала действия сертификата (время в формате UTC), знака «;» и значения хэш-функции от TBS сертификата (!ai Дис: В-5 — фактический ответ стенда расширенный). Состав записи о сертификате УКЭП в приватном канале приведён в п. 4.2.4.1.

Процесс внесения сведений должен выполняться в следующей последовательности:

1. Приём и декодирование сертификата: проверка непустого входа, ограничение размера входных данных, определение кодировки (PEM / Base64 / DER), декодирование.

2. Парсинг сертификата: первичная проверка DER-структуры, построение ASN.1-дерева с контролем лимитов (таблица 1), разбор структуры X.509 (tbsCertificate, signatureAlgorithm, signatureValue, поля TBS, имя издателя и владельца, расширения, открытый ключ), вычисление хэша TBS (hashTBS, ГОСТ Р 34.11-2012, 256 бит).

3. Проверка существования сертификата в реестре аккредитации и сертификатов УЦ; отказ при наличии записи с таким идентификатором и logicalCancelFlag = False (!ai Дис: О-2).

4. Форматная проверка сертификата.

5. Для несамоподписанного сертификата — запрос родительских сертификатов из реестра аккредитации и сертификатов УЦ и проверка цепочки доверия; отказ при отсутствии родительского сертификата. Для корневого сертификата — проверка допустимости регистрации корневого сертификата в канале и наличия идентичного сертификата в локальном хранилище.

6. Запрос списка отозванных сертификатов из локального хранилища; криптографические проверки (проверка электронной подписи сертификата средствами СКЗИ, полная криптографическая проверка цепочки доверия и статуса отзыва). Неуспех полной криптографической проверки цепочки доверия и статуса отзыва не завершает выполнение фатальной ошибкой: формируется предупреждение и фиксируется error_depth (!ai Дис: В-13).

7. Регистрация сертификата: создание записи о сертификате, создание записи в истории изменения статуса с событием «1» (начало действия сертификата) (!ai Дис: В-2) и updatedAt = validityNotBefore, установление полей isChecked и logicalCancelFlag в значение False, возврат идентификатора записи.

8. Перенос сведений в публичный канал сертификатов (п. 4.2.4.3) — параллельно с внесением сведений в приватный канал (!ai Дис: В-12).

Фоновые проверки сертификата выполняются после внесения записи о сертификате и формируют перечень предупреждений; по завершении проверок поле isChecked принимает значение True и выполняется перенос статуса в публичный реестр сертификатов.

Ограничения парсинга сертификатов приведены в таблице 1.

Таблица 1. Ограничения парсинга сертификатов

Состав предупреждений форматно-логического контроля для сертификатов УКЭП приведён в таблице 2 (фоновые семантические проверки — общие для сертификатов обоих типов — и обязательные для УКЭП проверки).

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

Помимо перечисленных выполняются общие фоновые семантические проверки сертификата (для сертификатов обоих типов) с формированием предупреждений: корректность версии TBS и уникальных идентификаторов; корректность полей validity (формат дат, порядок интервала, кодирование времени); необычно малые/большие серийный номер, открытый ключ и срок действия; дублирование серийного номера и открытого ключа в канале; пустые имена и атрибуты; корректность расширений subjectAltName, extendedKeyUsage, authorityKeyIdentifier, subjectKeyIdentifier, basicConstraints; корректность значений OID, перечислимых и булевых полей; неизвестные критические расширения; соответствие признаков роли УЦ (cA, keyCertSign, pathLenConstraint); корректность keyUsage и privateKeyUsagePeriod.

Коды ошибок создания записи о сертификате в приватном канале приведены в таблице 3.

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

4.2.1.2 Требования к изменению статуса сертификатов УКЭП

Изменение статуса сертификата выполняется методом POST /certificate/guc/status-update (канал аккредитации и сертификатов ГУЦ) либо POST /certificate/qual/status-update (приватные каналы квалифицированных сертификатов) (!ai Дис: В-1) с указанием идентификатора сертификата (cert), времени вступления изменения в силу (updatedAt), события (event) и причины изменения статуса (reason) (!ai Дис: В-9). При выполнении метода должна проверяться допустимость перехода по статусной модели (п. 4.2.4.2), а также что поле logicalCancelFlag сертификата имеет значение False. Результат изменения переносится в публичный канал сертификатов сервисом-ретранслятором.

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

Таблица 4. Коды ошибок изменения статуса сертификата

4.2.1.3 Требования к логической отмене сертификатов УКЭП

Логическая отмена сертификата выполняется методом POST /certificate/guc/certificate-cancel (канал аккредитации и сертификатов ГУЦ) либо POST /certificate/qual/certificate-cancel (приватные каналы квалифицированных сертификатов) с указанием идентификатора сертификата (cert) (!ai Дис: В-1, Э-7). Метод применяется к сертификату с флагом logicalCancelFlag = False; в результате флаг устанавливается в значение True, и сертификат с флагом True переносится в публичный канал сервисом-ретранслятором.

Коды ошибок логической отмены сертификата приведены в таблице 5.

Таблица 5. Коды ошибок логической отмены сертификата

4.2.1.4 Требования к получению данных сертификатов по заданному фильтру

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

4.2.2. Реализовать функцию взаимодействия с внешними информационными системами в части получения и передачи сведений о сертификатах УНЭП и о событиях жизненного цикла сертификатов УНЭП посредством прикладного программного интерфейса (API) для использования в высоконагруженном сервисе.

Назначение работ. Работы выполняются в соответствии с пунктом 2 Требований к функциям Заявки. Обеспечивается взаимодействие с внешними информационными системами в части получения и передачи сведений о неквалифицированных сертификатах ключей проверки электронной подписи, созданных в соответствии с Правилами, утверждёнными постановлением Правительства Российской Федерации от 01.12.2021 № 2152 (далее — сертификаты УНЭП), и о событиях их жизненного цикла посредством прикладного программного интерфейса (REST API). Сведения о сертификатах УНЭП размещаются в отдельных каналах инфраструктуры Госключ: канале сертификатов издателей Госключ и приватном канале неквалифицированных сертификатов Госключ; издатель сертификата УНЭП идентифицируется по значению атрибута commonName, проверка полномочности издателя по ОГРН и проверка аккредитации издателя не выполняются, поиск сертификатов цепочки доверия выполняется по реестру сертификатов издателей Госключ, а форматно-логический контроль выполняется с применением профильных проверок с кодами вида UNQCERT_*.

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

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

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

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

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

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

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

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

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

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

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

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

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

Форматно-логический контроль сертификатов УНЭП выполняется по определённому типу сертификата — ROOT_CA (корневой), SUB_CA (промежуточный) или END_ENTITY (конечного пользователя); тип сертификата определяется по составу полей сертификата. Жёсткие проверки критичности расширений, предусмотренные для сертификатов УКЭП, в отношении сертификатов УНЭП не выполняются. Состав обязательных для сертификатов УНЭП проверок и предупреждений приведён в таблице 6.

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

4.2.2.3 Требования к изменению статуса сертификатов УНЭП

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

4.2.2.4 Требования к логической отмене сертификатов УНЭП

Логическая отмена сертификата выполняется методами POST /certificate/goskey/certificate-cancel и POST /certificate/unqual/certificate-cancel с указанием идентификатора сертификата (!ai Дис: В-1). Коды ошибок — ERR-0010, ERR-0730 (состав и расшифровка — согласно п. 4.2.1.3, таблица 5).

4.2.2.5 Требования к получению данных сертификатов по заданному фильтру

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

4.2.3. Реализовать функцию взаимодействия с внешними информационными системами в части получения и передачи сведений об аккредитации удостоверяющих центров посредством прикладного программного интерфейса (API) для использования в высоконагруженном сервисе.

Назначение работ. Работы выполняются в соответствии с пунктом 3 Требований к функциям Заявки. Аккредитация удостоверяющих центров и изменение её статуса осуществляются оператором ИС ГУЦ — федеральным органом исполнительной власти, уполномоченным в сфере использования электронной подписи; статусы аккредитации удостоверяющих центров относятся к активам инфраструктуры открытых ключей, регистрируемым в распределённых реестрах. Достоверная фиксация событий жизненного цикла аккредитации (предоставление, приостановление, возобновление, прекращение, аннулирование) обеспечивает возможность предоставления сведений о статусе аккредитации на любой момент времени в прошлом — условие признания действительности квалифицированной электронной подписи (статья 11 Закона № 63-ФЗ) и основу автоматизированного контроля (надзора) в сфере электронной подписи. Обеспечивается приём от головного удостоверяющего центра сведений об удостоверяющих центрах и событиях жизненного цикла их аккредитации через программный интерфейс (REST API) с контролем корректности вносимых сведений, защитой от повторной обработки запросов и ведением статусной модели аккредитации.

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

1. Реализовать функцию регистрации нового удостоверяющего центра.

2. Реализовать функцию изменения сведений об удостоверяющем центре.

3. Реализовать функцию дополнения сведений об удостоверяющем центре.

4. Реализовать функцию создания аккредитации удостоверяющего центра.

5. Реализовать функцию изменения статуса аккредитации удостоверяющего центра.

6. Реализовать функцию отмены события аккредитации удостоверяющего центра.

4.2.3.1 Требования к ведению сведений об удостоверяющем центре

1. Реализовать функцию регистрации нового удостоверяющего центра, обеспечивающую:

   • приём сведений об удостоверяющем центре: ОГРН, ИНН, полное наименование, адрес расположения;

   • форматно-логический контроль поступающих данных, в том числе проверку корректности ОГРН и ИНН по установленным алгоритмам, с отказом в регистрации и возвратом кода ошибки при несоответствии;

   • отказ в регистрации с возвратом кода ошибки, если сведения об удостоверяющем центре уже находятся в реестре.

   Обоснование: постановка удостоверяющего центра на учёт в реестре — отправная точка жизненного цикла его аккредитации; внесение сведений с некорректными ОГРН и ИНН либо повторная регистрация не допускаются. Допускается первичная постановка УЦ на учёт в реестре, с неполными данными и их последующим обогащением.

2. Реализовать функцию изменения сведений об удостоверяющем центре, обеспечивающую:

   • приём изменённых сведений (не менее одного из: полное наименование, адрес расположения) с указанием даты и времени начала действия изменения, причины изменения и ссылки на решение об изменении сведений;

   • контроль целостности запроса, обеспечивающий отказ от повторной обработки одного и того же изменения.

   Обоснование: сведения об удостоверяющем центре изменяются при изменении его реквизитов; каждое изменение фиксируется с датой и временем начала действия, повторная обработка одного и того же изменения не допускается.

3. Реализовать функцию дополнения сведений об удостоверяющем центре, обеспечивающую:

   • приём дополнительных сведений (не менее одного из: сайт, адрес электронной почты, контактный телефон, сведения о программно-аппаратных комплексах);

   • контроль полноты сведений о программно-аппаратном комплексе: в случае заполнения хотя бы одного из полей (псевдоним ПАК, средство УЦ, класс средств электронной подписи) остальные поля также должны быть заполнены;

   • контроль целостности запроса, обеспечивающий отказ от повторной обработки одного и того же дополнения.

   Обоснование: сведения дополняются по мере появления информации о средствах электронной подписи и контактных данных; сведения о программно-аппаратных комплексах должны быть полными, повторная обработка одного и того же дополнения не допускается.

4.2.3.2 Требования к ведению аккредитации удостоверяющего центра

1. Реализовать функцию создания аккредитации удостоверяющего центра, обеспечивающую:

   • приём сведений: дата и время начала аккредитации, дата и время окончания действия аккредитации, причина, ссылка на решение;

   • установление аккредитации статуса «предоставлена»;

   • отказ с возвратом кода ошибки, если период аккредитации совпадает с периодом действующей аккредитации удостоверяющего центра.

   Обоснование: предоставление аккредитации — основание для выдачи удостоверяющим центром квалифицированных сертификатов ключей проверки электронных подписей; период предоставляемой аккредитации не должен совпадать с действующим.

2. Реализовать функцию изменения статуса аккредитации удостоверяющего центра, обеспечивающую:

   • приём нового статуса с указанием даты и времени начала действия изменения, причины и ссылки на решение;

   • проверку допустимости изменения статуса по статусной модели (п. 4.2.3.3) с отказом и возвратом кода ошибки при недопустимом изменении;

   • при аннулировании аккредитации — установление даты и времени начала действия изменения равными дате начала аккредитации.

   Обоснование: приостановление, возобновление, прекращение и аннулирование аккредитации — действующие сценарии управления аккредитацией со стороны оператора ИС ГУЦ; недопустимые изменения статуса должны отклоняться, нарушения процессов изменения статуса выявляются автоматическим контролем (надзором) в сфере электронной подписи.

3. Реализовать функцию отмены события, обеспечивающую:

   • отмену последнего неотменённого события аккредитации удостоверяющего центра;

   • запрет отмены события предоставления аккредитации;

   • возврат к предыдущему состоянию аккредитации при отмене;

   • фиксацию признака отмены, времени отмены и хэша запроса на отмену;

   • контроль уникальности запроса на отмену, обеспечивающий отказ от повторной обработки одного и того же запроса.

   Обоснование: ошибочно внесённое событие аккредитации должно быть отменено с возвратом к предыдущему состоянию; событие предоставления аккредитации отмене не подлежит, повторная обработка одного и того же запроса на отмену не допускается.

4.2.3.3 Требования к реализации статусной модели изменения состояния аккредитации

1. Аккредитация удостоверяющего центра может находиться в одном из следующих состояний: «предоставлена», «прекращена», «приостановлена», «возобновлена», «аннулирована».

2. Допустимы следующие изменения состояния аккредитации:

   • «предоставлена» → «приостановлена», «прекращена», «аннулирована»;

   • «приостановлена» → «возобновлена», «прекращена», «аннулирована»;

   • «возобновлена» → «приостановлена», «прекращена», «аннулирована»;

   • «прекращена» → «аннулирована».

3. Изменения состояния, не указанные в пункте 2, должны отклоняться с возвратом кода ошибки.

4.2.4. Реализовать функцию регистрации в распределённых реестрах сведений о сертификатах УКЭП и о событиях жизненного цикла сертификатов УКЭП для использования в высоконагруженном сервисе.

Назначение работ. Работы выполняются в соответствии с пунктом 4 Требований к функциям Заявки. Обеспечивается ведение в распределённых реестрах данных о сертификатах УКЭП и о событиях их жизненного цикла. Достоверная фиксация сведений о сертификатах УКЭП и событиях их жизненного цикла, а также возможность проверки статуса сертификата и статуса аккредитации выдавшего его удостоверяющего центра на любой момент времени в прошлом — условия признания действительности усиленной квалифицированной электронной подписи (статья 11 Федерального закона № 63-ФЗ). Данные о сертификатах УКЭП разделяются между двумя каналами распределённого реестра: приватным каналом сертификатов УЦ, содержащим сведения из сертификата (в том числе персональные данные владельца), сам сертификат и события его жизненного цикла, и публичным каналом сертификатов УЦ, содержащим открытый ключ, сведения о периоде действия сертификата и события его жизненного цикла. Для сертификатов УКЭП обязательна проверка аккредитации издателя сертификата — как при внесении сведений о сертификате, так и при определении его статуса на заданную дату.

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

1. Реализовать ведение в приватном канале сертификатов УЦ записей о сертификатах УКЭП с составом полей согласно таблице 7.

2. Обеспечить ведение истории изменения статуса сертификата с составом полей согласно таблице 8 и ведение статусной модели сертификата согласно таблицам 9–10.

3. Обеспечить перенос сведений о сертификатах УКЭП и событиях их жизненного цикла в публичный канал сертификатов УЦ с составом полей согласно таблице 11.

4. Обеспечить формирование идентификаторов записей о сертификатах единым механизмом (п. 4.2.4.4).

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

Доступ к чтению и записи в приватном канале сертификатов УЦ имеют УЦ-владелец канала и ЕСИА. Приватный канал может содержать персональные данные владельца сертификата.

Запись о сертификате УКЭП в приватном канале содержит следующие сведения (таблица 7).

Таблица 7. Состав записи о сертификате УКЭП в приватном канале

* отмечены обязательные поля.

Внесение сведений о сертификате УКЭП в приватный канал выполняется методом создания записи о сертификате (п. 4.2.1.1).

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

Для каждого сертификата УКЭП ведётся история изменения статуса сертификата с составом полей согласно таблице 8.

Таблица 8. Состав записи истории изменения статуса сертификата

* отмечены обязательные поля.

Статусная модель сертификата приведена в таблицах 9–10. Сертификат может находиться в агрегированных состояниях «Действует» и «Не действует». События и причины изменения статуса приведены в таблице 9.

Таблица 9. События и причины изменения статуса сертификата

Состояние «Не действует» включает также случаи: срок действия сертификата не наступил; срок действия сертификата истёк.

Таблица 10. Допустимые переходы между причинами изменения статуса

«+» — переход допустим, «-» — переход недопустим. Изменения статуса, не предусмотренные таблицей, должны отклоняться. Идемпотентность запроса изменения статуса обеспечивается проверкой перехода по статусной модели.

Изменение статуса сертификата выполняется методом согласно п. 4.2.1.2, логическая отмена сертификата — методом согласно п. 4.2.1.3.

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

Публичный канал сертификатов УЦ содержит сведения о сроках действия сертификатов, выданных удостоверяющим центром, и информацию об изменении их статусов. Доступ к записи в канале имеет ЕСИА; доступ к чтению — у всех участников канала. Персональные данные владельца сертификата и сам сертификат в публичный канал не переносятся.

Таблица 11. Состав записи о сертификате УКЭП в публичном канале

* отмечены обязательные поля.

Перенос сведений в публичный канал выполняется сервисом-ретранслятором ЕСИА: после внесения сведений в приватный канал сертификатов сервис-ретранслятор перехватывает событие о внесении, запрашивает копирование данных из приватного канала и вызывает внутренний метод чейнкода публичного канала на запись данных (!ai Дис: В-12). Переносятся: _id, hashTBS, issuerUUID, serialNumber, issuerOGRN, subjectPublicKey, validityNotBefore, validityNotAfter, privateKeyUsagePeriod; при переносе формируются модель сведений о сертификате (с полями isChecked = False, logicalCancelFlag = False, createdAtCC) и модель истории с записью события «1» (начало действия сертификата) (!ai Дис: В-2). Изменения статуса и логическая отмена переносятся в публичный канал соответствующими внутренними методами чейнкода.

4.2.4.4 Требования к формированию идентификаторов записей о сертификатах

Идентификаторы записей о сертификатах формируются автоматически единым механизмом:

• внешний идентификатор сертификата (cert) (!ai Дис: В-12) — конкатенация даты начала действия сертификата validityNotBefore (время в формате UTC, YYYY-MM-DDTHH:MM:SSZ), знака «;» и значения хэш-функции от TBS сертификата hashTBS (ГОСТ Р 34.11-2012, 256 бит);

• идентификатор записи в CouchDB (_id) — формируется чейнкодом по данным сертификата: структура включает версию чейнкода, контрольную сумму, тип актива (для КСКПЭП — значение 2), идентификатор реестра, идентификатор издателя сертификата и идентификатор актива (74 младших бита хэша серийного номера сертификата) (!ai Дис: М-4); при формировании проверяется уникальность идентификатора, коллизии разрешаются повторным хэшированием с фиксацией в сервисной базе данных сервисного чейнкода;

• идентификатор записи об истории статуса сертификата — комбинация uuid сертификата и суффикса HIST;

• issuerUUID — uuid сертификата издателя; для самоподписанного сертификата равен _id.

Значение идентификатора одного актива одинаково для разных каналов.

(!ai Дис: В-6) По обновлённым диаграммам последовательности закрепление глобального идентификатора выполняется отдельной транзакцией через RegistryContract с фиксацией записи в журнале коллизий; в снимке 261002 и в редакции 260714 такой отдельной транзакции нет — состав требования подлежит уточнению.

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

Назначение работ. Работы выполняются в соответствии с пунктом 5 Требований к функциям Заявки. Обеспечивается ведение в распределённых реестрах данных о сертификатах УНЭП и о событиях их жизненного цикла. Сертификаты УНЭП выпускаются в инфраструктуре Госключ и не требуют проверки аккредитации издателя: у сертификатов УНЭП не применяются проверка полномочности издателя по ОГРН и проверка аккредитации издателя, а статус сертификата на заданную дату определяется только по истории событий сертификата без обращения к реестру аккредитации. Сведения о сертификатах УНЭП размещаются в отдельных каналах инфраструктуры Госключ: канал сертификатов издателей Госключ предназначен для регистрации корневых и подчинённых сертификатов издателей, приватный канал неквалифицированных сертификатов Госключ — для регистрации сертификатов конечных пользователей; издатель сертификата УНЭП идентифицируется по значению атрибута commonName (CN), а не по ОГРН, вследствие чего поле issuerOGRN при переносе сведений о сертификате УНЭП в публичный канал сертификатов УЦ остаётся пустым. Ведение сертификатов УНЭП в отдельных каналах обусловлено различием нормативного регулирования: требования к форме квалифицированного сертификата ключа проверки электронной подписи установлены приказом ФСБ России от 27 декабря 2011 г. № 795, требования к сертификатам УНЭП — Правилами, утверждёнными постановлением Правительства Российской Федерации от 01.12.2021 № 2152.

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

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

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

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

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

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

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

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

Внесение сведений о сертификате УНЭП в приватный канал выполняется методом создания записи о сертификате (п. 4.2.2.1); состав записи о сертификате УНЭП идентичен составу записи о сертификате УКЭП в приватном канале (п. 4.2.4.1). Коды ошибок создания записи — ERR-0010, ERR-0701 … ERR-0728 (состав и расшифровка — согласно п. 4.2.1.1, таблица 3).

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

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

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

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

4.2.5.4 Требования к формированию идентификаторов записей о сертификатах

Идентификаторы записей о сертификатах УНЭП формируются автоматически единым механизмом (п. 4.2.4.4); для типа актива НСКПЭП в структуре идентификатора записи в CouchDB применяется значение 3.

4.2.6. Реализовать функцию регистрации в распределённых реестрах сведений об аккредитации удостоверяющих центров для использования в высоконагруженном сервисе.

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

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

1. Реализовать ведение записи удостоверяющего центра, содержащей сведения: ОГРН и ИНН удостоверяющего центра, полное наименование, адрес расположения, сайт, адрес электронной почты, контактный телефон, сведения о применяемых программно-аппаратных комплексах (псевдоним ПАК, средство УЦ, класс средств электронной подписи, срок действия закрытого ключа).

2. Обеспечить хранение истории изменения и дополнения сведений об удостоверяющем центре, включая идентификаторы изменения и дополнения записи, причину изменения сведений и ссылку на решение об изменении сведений.

3. Реализовать ведение записи об аккредитации удостоверяющего центра, содержащей сведения: дату начала аккредитации, дату окончания действия аккредитации, статус (предоставлена, прекращена, приостановлена, возобновлена, аннулирована), причину изменения статуса и ссылку на решение об изменении статуса.

4. Обеспечить хранение истории аккредитации, включая сведения об отменённых событиях (признак отмены, время отмены, хэш запроса на отмену события).

5. Обеспечить форматно-логический контроль поступающих данных: проверку корректности ОГРН и ИНН по установленным алгоритмам, представление даты и времени в формате RFC 3339, время — UTC, без долей секунды, ограничение длин значений полей.

6. Обеспечить формирование идентификаторов записей единым механизмом и автоматическое ведение служебных сведений (версия записи, время внесения сведений в реестр, время обновления записи в реестре).

4.2.6.1 Требования к реализации функции ведения записей в БД Глобального состояния (world state)

Для обеспечения хранения сведений об удостоверяющих центрах и их аккредитации необходимо реализовать ведение в БД Глобального состояния записей следующих видов:

• запись «Удостоверяющий центр» — актуальные сведения об удостоверяющем центре;

• запись «История изменения данных удостоверяющего центра» — версии сведений об удостоверяющем центре после их изменения и дополнения;

• запись «Аккредитация удостоверяющего центра» — актуальные сведения об аккредитации удостоверяющего центра;

• запись «История аккредитации удостоверяющего центра» — события жизненного цикла аккредитации.

Каждая запись должна содержать вид записи, версию записи и служебные сведения о времени внесения и обновления записи в реестре. Идентификаторы записей должны формироваться автоматически единым механизмом. Состав и значения полей записей должны соответствовать требованиям пунктов 4.2.1–4.2.5 настоящего раздела.

4.2.7. Реализовать функцию маршрутизации запросов в распределённых реестрах для использования в высоконагруженном сервисе.

Назначение работ. Работы выполняются в соответствии с пунктом 7 Требований к функциям Заявки. В высокодинамичных средах, характеризующихся частым созданием записей об активах, со временем происходит деградация производительности реестров; подсистема ИС ГУЦ «Распределённые реестры объектов инфраструктуры открытых ключей» (далее — Реестры PKI) относится к таковым. В связи с этим обеспечивается механизм ротации каналов, под которым понимается периодическое создание нового канала, миграция на него актуальной бизнес-логики и участников с сохранением возможности доступа к данным старых каналов. Межканальная маршрутизация запросов к объектам и разрешение возможных коллизий между объектами обеспечиваются сервисным чейнкодом, размещаемым в канале ГУЦ (!ai Дис: В-7).

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

1. Реализовать функцию регистрации реестра в сервисном чейнкоде, обеспечивающую: приём всех полей сервисной базы данных, кроме идентификатора реестра; присвоение идентификатора реестра (0 — при регистрации нового издателя актива; значение, увеличенное на 1, — при ротации канала, но не более 31); фиксацию момента ввода канала в эксплуатацию.

2. Реализовать функцию ротации канала, обеспечивающую: создание нового канала с миграцией на него актуальной бизнес-логики и участников с сохранением возможности доступа к данным ранее созданных каналов; задействование ротации по мере наполнения канала и периодической ротации; вывод канала из эксплуатации по истечении времени жизни всех активов с фиксацией момента вывода канала из эксплуатации; перевод выведенного из эксплуатации канала в «холодный» режим (!ai Дис: В-7).

3. Обеспечить расчётные сроки эксплуатации каналов до ротации (таблица 13).

4. Обеспечить ведение сервисной базы данных сервисного чейнкода, содержащей сведения о реестрах (действующих и ротированных), с составом полей согласно таблице 15.

5. Обеспечить формирование идентификатора объекта по данным актива: по значению ОГРН УЦ — для сведений об аккредитации удостоверяющего центра; по значению хэша серийного номера и Issuer.OGRN (или хэша от поля Issuer) — для сведений о сертификате; по значению электронной подписи и ОГРН издателя сертификата подписи (или хэша от поля Issuer издателя) — для сведений об электронной подписи.

6. Обеспечить структуру идентификатора объекта — 128-битовый вектор (RFC 9562) с составом полей согласно таблице 16 и соответствием типов актива согласно таблице 17.

7. Реализовать функцию маршрутизации запроса к объекту канала по идентификатору объекта: определение типа и ключевой даты искомого актива, версии сервисного чейнкода; вычисление издателя актива; поиск реестра актива для данного издателя; возврат пары значений «наименование канала + наименование чейнкода» (!ai Дис: В-7, Р-8).

8. Реализовать функцию определения реестра по данным актива (формирование идентификатора объекта и его маршрутизация) и функцию подбора всех возможных (по версиям сервисного чейнкода) реестров для данного актива и его издателя.

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

10. Реализовать функцию определения ключевой даты актива по данным актива.

11. Реализовать функцию определения версии сервисного чейнкода — текущей либо актуальной на заданный момент времени.

12. Обеспечить разрешение коллизий между владельцами реестров (issuerID, issuerIDAddon, roundsNum): при обнаружении коллизии создаётся дополнительная запись в сервисной базе данных; при маршрутизации проверяется наличие записи о коллизии, данные о записи уточняются по точному значению идентификатора.

13. Обеспечить разрешение коллизий между объектами реестра (collisionID, uniqueIDForCollision): при обнаружении коллизии создаётся дополнительная запись в сервисной базе данных; при маршрутизации проверяется наличие записи о коллизии, данные о записи уточняются по точному значению идентификатора.

4.2.7.1 Требования к функции ротации каналов

Ротация канала выполняется вручную следующей последовательностью действий (таблица 14).

Таблица 13. Расчётное время эксплуатации каналов до ротации

Таблица 14. Последовательность действий при ротации канала

Ротация канала для активов отражается изменением значения идентификатора реестра: для нового создаваемого канала идентификатор увеличивается на 1. Момент ввода канала в эксплуатацию фиксируется в сервисной базе данных и выступает временем начала периода вносимых в канал активов; момент вывода канала из эксплуатации фиксирует начало работы канала в «холодном» режиме.

Каждому поколению каналов соответствует индекс ротации (0 … N+1): канал ГУЦ (mcc), приватные каналы сертификатов ГУЦ, публичные и приватные каналы квалифицированных и неквалифицированных сертификатов УЦ, канал электронных подписей; системные имена каналов и чейнкодов включают индекс поколения. Сервисный чейнкод (service_cc) развёрнут у каждого участника (ГУЦ, УЦ) и при переходе к очередному поколению каналов переводится на новое поколение (!ai Дис: В-7).

4.2.7.2 Требования к ведению сервисной базы данных сервисного чейнкода

Таблица 15. Состав сервисной базы данных сервисного чейнкода

Информация о созданном (затем ротируемом) канале указывается в поле registryID с указанием даты dateTimeOpened, выступающей в качестве времени начала периода вносимых активов в канал. Поле dateTimeClosed указывает на время вывода канала из эксплуатации: с этого времени канал принимает только информацию об изменении жизненного цикла активов (до истечения времени их действия), а также работает в «холодном» режиме.

4.2.7.3 Требования к структуре идентификатора объекта и типам актива

Таблица 16. Структура идентификатора объекта

Таблица 17. Соответствие типов актива

Совокупность типа актива, идентификатора реестра и идентификатора владельца реестра однозначно определяют конкретный реестр и тип актива. Исключением является канал аккредитованных УЦ, в котором содержатся активы двух типов (УЦ и КСКПЭП).

В рамках текущей модели идентификатора объекта возможно 32 ротации канала. Увеличение количества ротаций возможно за счёт перераспределения битов идентификатора владельца реестра с переходом на новую версию сервисного чейнкода, что приводит к большему количеству записей в сервисной базе данных, разрешающих возникающие коллизии между идентификаторами владельцев реестра. Количество ротаций в зависимости от распределения битов указано в таблице 18.

Таблица 18. Количество ротаций канала в случае перераспределения битов

* вероятность отсутствия коллизии определяется согласно схеме «парадокса дней рождений».

Переход на 256-битовый идентификатор объекта настоящим требованием не предусматривается.

4.2.7.4 Требования к методам сервисного чейнкода

Для обеспечения работы с активами в каналах реализуются методы сервисного чейнкода согласно таблице 19 (входные данные — аргументы методов, выходные данные — результаты методов).

Таблица 19. Методы сервисного чейнкода

Разрешение возможных коллизий между владельцами реестров обеспечивается полями issuerID, issuerIDAddon, roundsNum: при обнаружении коллизии создаётся дополнительная запись в сервисную базу данных; при обеспечении маршрутизации производится проверка наличия записи о коллизии в сервисном чейнкоде, после чего данные о записи уточняются по точному значению идентификатора.

Разрешение возможных коллизий между объектами реестра обеспечивается полями collisionID, uniqueIDForCollision: при обнаружении коллизии создаётся дополнительная запись в сервисную базу данных; при обеспечении маршрутизации производится проверка наличия записи о коллизии в сервисном чейнкоде, после чего данные о записи уточняются по точному значению идентификатора.

Сервисный чейнкод содержится в канале ГУЦ.

4.2.7.5 Требования к методам формирования идентификатора объекта по данным актива

Для работы с активами реализуются методы получения идентификатора объекта по данным актива согласно таблице 20.

Таблица 20. Методы формирования идентификатора объекта по данным актива

(!ai Дис: В-4) В снимке 261002 подтверждён только метод getUUIDFromCertificate; методы для сведений об аккредитации и об электронной подписи в обновлённых источниках не описаны — состав методов подлежит уточнению.

4.2.8. Реализовать функцию формирования представления данных о сертификатах УКЭП и о событиях жизненного цикла сертификатов УКЭП на основании записей в распределённых реестрах для использования в высоконагруженном сервисе.

Назначение работ. Работы выполняются в соответствии с пунктом 8 Требований к функциям Заявки. На основании записей в распределённых реестрах формируются представления данных о статусе сертификата УКЭП: история статуса сертификата, статус сертификата на заданный момент времени, периоды действия сертификата — с учётом статуса аккредитации издателя сертификата. Представления предоставляются через программный интерфейс публичного канала сертификатов УЦ. Возможность проверки статуса сертификата и статуса аккредитации выдавшего его удостоверяющего центра на любой момент времени в прошлом — условие признания действительности усиленной квалифицированной электронной подписи (статья 11 Федерального закона № 63-ФЗ).

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

1. Реализовать функцию получения истории статуса сертификата.

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

3. Реализовать функцию получения периодов действия сертификата.

4.2.8.1 Требования к получению истории статуса сертификата

Получение истории статуса сертификата: GET certificate-validity/qual/all?cert=YYYY-MM-DDTHH:MM:SSZ;hashTBS (!ai Дис: В-1); возвращается история изменения статуса сертификата. Коды ошибок: ERR-0010 (пустой запрос), ERR-0729 (отсутствует сертификат) (!ai Дис: В-11).

4.2.8.2 Требования к получению статуса сертификата на заданный момент времени

Получение статуса сертификата на заданный момент времени: GET certificate-validity/qual/by-date?cert=YYYY-MM-DDTHH:MM:SSZ;hashTBS&time='YYYY-MM-DDTHH:MM:SSZ' (!ai Дис: В-1). Возвращается результат по каждому сертификату цепочки доверия (target_cert, sub_ca, root_cert): идентификатор сертификата (certId), статус сертификата в цепочке (localStatus со значениями status True/False, details: notYetValid — срок действия ещё не наступил; issued — действует с момента выпуска; expired — срок действия истёк; annulled — аннулирован; revoked — действие досрочно прекращено/приостановлено; resumption — действие возобновлено; date — дата события, определяющего статус; reason — причина отзыва), статус аккредитации УЦ издателя (accreditationStatus), а также статус секретного ключа (privateKeyStatus, для проверяемого сертификата), признак завершения фоновых проверок isChecked (!ai Дис: Д-3) и итоговый статус (resultStatus) (!ai Дис: В-3).

Статус сертификата на заданную дату определяется по истории изменения статуса сертификата: для даты проверки выбирается запись с максимальным значением updatedAt, не превышающим дату проверки; учитываются события «выпуск», «прекращение», «возобновление», «аннулирование», а также выход даты проверки за пределы периода действия сертификата. Статус аккредитации издателя определяется на дату начала действия сертификата (validityNotBefore) запросом к реестру аккредитации и сертификатов УЦ. Итоговый статус: если у всех сертификатов цепочки localStatus.status = true и accreditationStatus = true, то resultStatus = true; если хотя бы у одного сертификата localStatus.status = false или accreditationStatus = false, то resultStatus = false. Статус секретного ключа: True, если дата проверки попадает в период действия секретного ключа (включая границы); False — вне периода; если период не указан, статус ключа не указывается. Коды ошибок: ERR-0010, ERR-0729 (!ai Дис: В-11).

4.2.8.3 Требования к получению периодов действия сертификата

Получение периодов действия сертификата: GET certificate-validity/qual/periods?cert=YYYY-MM-DDTHH:MM:SSZ;hashTBS (!ai Дис: В-1). Периоды действия вычисляются по истории изменения статуса: событие «1» (начало действия) (!ai Дис: В-2) задаёт период от validityNotBefore до validityNotAfter; событие «2» (прекращение) обрывает период; событие «0» (аннулирование) исключает все периоды действия с даты начала действия сертификата; событие «3» (возобновление) начинает новый период. Периоды действия целевого сертификата — пересечение периодов действия всех сертификатов цепочки доверия (начало — максимум начал периодов, окончание — минимум окончаний периодов), пересекающиеся и соприкасающиеся периоды объединяются. Если аккредитация издателя не действует на дату начала действия сертификата, периоды действия отсутствуют. Коды ошибок: ERR-0010, ERR-0729 (!ai Дис: В-11).

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

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

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

1. Реализовать функцию получения истории статуса сертификата.

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

3. Реализовать функцию получения периодов действия сертификата.

4.2.9.1 Требования к получению истории статуса сертификата

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

4.2.9.2 Требования к получению статуса сертификата на заданный момент времени

Получение статуса сертификата на заданный момент времени: 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) (!ai Дис: В-3). Статус сертификата на заданную дату определяется по истории изменения статуса сертификата (запись с максимальным updatedAt, не превышающим дату проверки). Итоговый статус: если у всех сертификатов цепочки localStatus.status = true, то resultStatus = true; если хотя бы у одного localStatus.status = false, то resultStatus = false. В отличие от сертификатов УКЭП, обращение к реестру аккредитации не выполняется и поле accreditationStatus не определяется; коды ошибок — ERR-0010, ERR-0729 (!ai Дис: В-11).

4.2.9.3 Требования к получению периодов действия сертификата

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

4.2.10. Реализовать функцию формирования представления данных об аккредитации удостоверяющих центров на основании записей в распределённых реестрах для использования в высоконагруженном сервисе.

Назначение работ. Работы выполняются в соответствии с пунктом 10 Требований к функциям Заявки. Сведения об аккредитации удостоверяющих центров предоставляются внешним потребителям по запросу, в том числе о статусе аккредитации на любой момент времени в прошлом. Возможность получить историю аккредитации, периоды её действия и статус на заданную дату необходима для признания действительности квалифицированной электронной подписи (статья 11 Закона № 63-ФЗ), а массовая выборка сведений по заданным фильтрам — для внешних информационных систем и автоматизированного контроля (надзора) в сфере электронной подписи. Представления формируются на основании записей в распределённых реестрах и предоставляются через программный интерфейс (REST API); изменение сведений реестра по результатам запросов не выполняется — функции предоставляются только для чтения.

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

1. Реализовать функцию получения истории аккредитации удостоверяющего центра.

2. Реализовать функцию получения периодов действия аккредитации удостоверяющего центра.

3. Реализовать функцию получения статуса аккредитации на заданную дату.

4. Реализовать функцию получения сведений по фильтру.

4.2.10.1 Требования к получению истории аккредитации удостоверяющего центра

Функция получения истории аккредитации удостоверяющего центра должна обеспечивать:

• приём запроса с идентификатором удостоверяющего центра (ОГРН);

• возврат всех событий аккредитации удостоверяющего центра, упорядоченных по версии, дате и времени начала действия изменения и времени внесения сведений в реестр;

• отказ с возвратом кода ошибки при отсутствии удостоверяющего центра в реестре либо записей об аккредитации.

Обоснование: полная история событий аккредитации — требуется для подробного анализа и проверки всех событий статуса аккредитации УЦ в прошлом.

4.2.10.2 Требования к получению периодов действия аккредитации удостоверяющего центра

Функция получения периодов действия аккредитации удостоверяющего центра должна обеспечивать:

• приём запроса с идентификатором удостоверяющего центра (ОГРН);

• вычисление периодов, в течение которых аккредитация действовала, с учётом отменённых событий;

• возврат перечня периодов с указанием даты и времени начала и окончания каждого периода.

Обоснование: периоды действия аккредитации позволяют потребителям установить, действовала ли аккредитация на интересующий момент, без обработки полной истории событий.

4.2.10.3 Требования к получению статуса аккредитации на заданную дату

Функция получения статуса аккредитации на заданную дату должна обеспечивать:

• приём запроса с идентификатором удостоверяющего центра (ОГРН) и моментом проверки;

• определение статуса аккредитации на указанный момент с учётом отменённых событий;

• возврат признака действия аккредитации на указанный момент (действует / не действует);

• отказ с возвратом кода ошибки, если момент проверки раньше даты начала аккредитации.

Обоснование: проверка статуса аккредитации на момент подписания — условие признания действительности квалифицированной электронной подписи (статья 11 Закона № 63-ФЗ).

4.2.10.4 Требования к получению сведений по фильтру

Функция получения сведений по фильтру должна обеспечивать:

• приём параметров фильтрации: статус аккредитации; период по дате и времени окончания действия аккредитации; период по дате и времени начала аккредитации; период по дате и времени обновления сведений об аккредитации; период по дате и времени обновления сведений об удостоверяющем центре; комбинации статуса аккредитации с каждым из указанных периодов;

• при указании только нижней границы периода — возврат удостоверяющих центров со значениями после указанной границы; при указании только верхней границы — до указанной границы;

• возврат перечня удостоверяющих центров, удовлетворяющих заданным параметрам, с актуальными сведениями об удостоверяющем центре и его аккредитации.

Обоснование: массовая выборка сведений по фильтрам обеспечивает использование данных реестра внешними информационными системами и автоматизированным контролем (надзором) без обработки полной истории.