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

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

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

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

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

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

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

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

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

• ведение сведений об электронной подписи как самостоятельном активе.

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

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

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

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

4. Обеспечить ведение истории изменения статуса сертификата с составом полей согласно таблице 5 и ведение статусной модели сертификата согласно таблицам 6–7.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Проверка существования сертификата в реестре аккредитации и сертификатов УЦ; отказ при наличии записи с таким идентификатором и logicalCancelFlag = False.

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

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

6. Запрос списка отозванных сертификатов из локального хранилища; криптографические проверки (проверка электронной подписи сертификата средствами СКЗИ, полная криптографическая проверка цепочки доверия и статуса отзыва).

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

8. Перенос сведений в публичный канал сертификатов (п. 4.2.2.3) — параллельно с внесением сведений в приватный канал.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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