OQ — открытые вопросы (вопросительные моменты) проекта PKI

ID

Вопрос

дата / Где возник/ статус (автор)

В01

Номер Заявки «Хронограф» и номера её пунктов — в черновиках стоят плейсхолдеры ___ (функции ТЗ: 4.2.2.1 — представление, 4.2.2.5 — обработка, 4.2.2.7 — хранение, 4.2.2.11 — взаимодействие с ВИС). Подставить фактические

ЧТЗ 4.2.2/4.2.3, ПМИ А.2/А.3

-В01-

Впредь использовать:
Создание новой функции (без взаимодействия с внешними ИС) 4.2.1.1
Создание новой функции обработки данных 4.2.1.5
Создание функции взаимодействия с внешними ИС 4.2.1.11

260915 22:13
Решено (А.М.)

В02

Состав и порядок подготовки тестовых сертификатов УКЭП для испытаний (издатели, владельцы, периоды действия, дефектные сертификаты)

Список сертификатов для тестирования лучше всего запросить у РТЛабс, а также уточнить их перечень. Я запрошу (А.Б.) (Дис)

В03

Доступ к методам приватного канала сертификатов УЦ на стенде — от имени какого участника выполняются вызовы

260915
ПМИ А.2
открыт (Дис) Для приватного канала УЦ в зависимости от того, какой канал. У нас три канала , в которых используются методы приватного канала квалифицированных сертификатов:
1. канал аккредитации и сертификатов АУЦ,
2. приватный канал сертификатов ГУЦ,
3. приватный канал квалифицированных сертификатов ИИТ. Таблица с участниками и их правами приведена в документе "Описание реестра аккредитации и сертификатов" (А.Б.)

В04

Включать ли проверки А.2 в коллекцию Postman (Приложение А.5.1): текущая коллекция покрывает только проверки А.1

260915
ПМИ А.2
открыт (Дис)
3. Я думаю A2.1, A2.4-A2.12 нужно включить (А.Б.)

В05

Перечень дефектных тестовых сертификатов УКЭП (какие нарушения, какие коды предупреждений); продолжительность фоновых проверок и момент наблюдения isChecked = True

260915
ПМИ А.2.2
открыт (Дис) Договорились, формируется массив этих предупреждений без разграничения на коды. Продолжительность фоновых проверок и момент проставления флага isChecked = True мы можем узнать только экспериментально (А.Б.)

В06

Подготовка сертификата с неверной подписью; охватывать ли отдельными шагами полную криптографическую проверку цепочки (CHAIN_CRYPTO_*) и запрос списка отозванных сертификатов из локального хранилища; включать ли проверку регистрации корневого сертификата (ERR-0723/0724/0725)

260915
ПМИ А.2.3
открыт (Дис) Я думаю не включать. Если будет замечание от заказчика, то в этом случае включить (А.Б.)

В07

Состав цепочки доверия тестовых сертификатов и её влияние на пересечение периодов; включать ли событие «аннулирование» (event = 0) в сценарий

260915
ПМИ А.2.12
открыт (Дис)

В08

Состав и порядок подготовки тестовых сертификатов УНЭП

Список сертификатов для тестирования лучше всего запросить у РТЛабс, а также уточнить их перечень. Я запрошу (А.Б.)

В09

Поведение при регистрации квалифицированного сертификата в канале УНЭП (маршрутизация проверок по channel_type из REGISTRATION_CHANNEL_POLICY) — включать ли отдельную проверку

260915
ПМИ А.3
открыт (Дис) Я думаю надо включать (А.Б.)

В10

Включать ли проверки А.3 в коллекцию Postman (Приложение А.5.1)

260915
ПМИ А.3
открыт (Дис) Надо включить A3.1, A3.4-A3.12

В11

Для УНЭП в источнике не описана фиксация isChecked = True после фоновых проверок (описано только для УКЭП) — считать ли поведение одинаковым

260915
ПМИ А.3.2
открыт (Дис) Поведение считать одинаковым с учетом различий между проверками УКЭП, УНЭП (А.Б.)

В12

Проверка регистрации корневого сертификата в канале издателей Госключ (ERR-0723/0724/0725); полная криптографическая проверка цепочки (CHAIN_CRYPTO_*)

260915
ПМИ А.3.3
открыт (Дис) Провести функциональную проверку, но в ПМИ не включать (А.Б.)

В13

Для УНЭП не описан код ошибки разбора идентификатора cert (у УКЭП — ERR-0731) — проверить фактическое поведение на стенде

260915
ПМИ А.3.5
открыт (Дис) Ожидаем реализацию

В14

Имя поля типа сертификата УНЭП в записи: модель содержит ownerType (типы владельца), проверки формируют registration_json.owner_type (ROOT_CA/SUB_CA/END_ENTITY) — уточнить фактическое имя поля и множество значений на стенде

260915
ПМИ А.3.7, источник п. 4.1.1/4.1.2
открыт (Дис) по идее root_ca, sub_ca, end_entity, но нужно дождаться реализации (А.Б.)

В15

Для УНЭП gherkin алгоритма периодов содержит сценарий «недействующая аккредитация на начало действия», но приложения-алгоритмы и диаграммы УНЭП аккредитацию не используют — уточнить фактическое поведение; включать ли событие «аннулирование» в сценарий

260915
ПМИ А.3.12
открыт (Дис) Для УНЭП не должен учитываться параметр "статус аккредитации". он не участвует в расчете, поэтому связанный сценарий в gherkin надо исключить (А.Б.)

ID

Вопрос

дата / Где возник/ статус (автор)

В16

!ai Дис (гипотеза): блок работ соответствует п. 4.2.4 ТЗ и заголовку-плейсхолдеру «4.2.4 Создание функций маршрутизации запросов…» в ЧТЗ_РР_ОИОК_v02.md; черновик оформлен как этот блок (4.2.4.1–4.2.4.5). Если ЧТЗ по сервисному чейнкоду — отдельный документ со своей нумерацией, блоки перенумеровать

260915
ЧТЗ 4.2.4
открыт (Дис)

В17

Номер и наименование Заявки, обозначения, шифры — плейсхолдеры ___ (в том числе номер пункта Заявки для п. 4.2.4)

260915
ЧТЗ 4.2.4, ПМИ А.4
открыт (Дис)

В18

Наименование документа-основания для обратных ссылок в ПМИ («описание решения, п. 2.1») — уточняется

260915
ПМИ А.4
открыт (Дис)

В19

Автоматизация проверок в ПМИ не отражена (коллекции нет); при появлении коллекции методика дополняется ссылками, приложения перенумеровываются (сейчас: Б — протокол, В — акт)

260915
ПМИ А.4
открыт (Дис) Напрямую методы не используются. Ротация каналов будет проводиться в ручном режиме (А.Б.)

В20

Состав проверок А.4.1–А.4.14 предварительный; идеи тестирования (создание коллизий, контрольная сумма, смена версии s_cc, периодическая ротация, недоступность канала) — в диалоге с А.М.

260915
ПМИ А.4
открыт (Дис) Из возможных проверок для коллизий uuid можно попробовать провести для сертификатов, т.к. серийным номером можно управлять. Но скорее это нужно делать не в рамках ПМИ, а в рамках ручного тестирования. Периодическая ротация - не реализуем на текущий момент (А.Б.)

ID

Замечание

И01

УНЭП: модель приватного канала содержит ownerType (типы владельца), а проверки п. 4.1.2 формируют registration_json.owner_type ∈ {ROOT_CA, SUB_CA, END_ENTITY, null}. Имя поля и множество значений не согласованы

И02

УНЭП, п. 4.7.3 (END_ENTITY): первое условие записано «Если _id=issuerUUID» — противоречит признаку некорневого сертификата (в 4.7.2 корректно «_id≠issuerUUID»). Вероятная опечатка

И03

УНЭП и аккредитация: gherkin п. 4.2.4 содержит сценарий «1.6 Недействующая аккредитация на начало действия», но приложения-алгоритмы, диаграммы 4.2.3.1/4.2.4.1 и итоговый результат УНЭП аккредитацию не используют; в таблице 20 при этом сохранено поле accreditatioStatus. Что считать правильным — требует решения

И04

УНЭП: фиксация isChecked = True и запуск переноса статуса в публичный канал после фоновых проверок описаны только для УКЭП (примечание 8 к п. 3.1.3); у УНЭП аналога нет, при том что публичный канал использует isChecked

И05

Переходы по статусной модели (таблица 7 = таблица 17): смысл групп строк («Предыдущее изменение статуса», «Последующее изменение статуса», «Изменение статуса отсутствует») и порядок применения матрицы не расшифрованы

И06

Причины 11 и 16: упомянуты в gherkin-сценариях («причина 11» с событием 0; «причина 16» с событием 1), расшифровок в документе нет; в диаграмме статусной модели причины 0–10 (без 7)

И07

Идентификаторы (п. 5.2): (а) разрядность идентификатора издателя: 24 бита в п. 5.2 против «32 старших значащих бита» в таблице 25; (б) сумма бит: 74 LSB заявлены, составляющие 4+12+2+62 = 80 бит; (в) cert_id_hash_algorithm определён как «хэширование TBS», а п. 5.2 хэширует serialNumber; (г) шаг 1.7.3 процесса формирует _id по serialNumber + validityNotBefore + Issuer.OGRN — не согласован с п. 5.2; (д) ссылка «Идентификатор реестра назначается согласно таблице 23» — вероятна ошибка ссылки

И08

Аннотации рецензента в тексте документа (С. Лебедева, 23.08.2026): критика формата идентификатора («Критично. Переделать… externalID»); вопрос порядка переноса в публичный канал — до или после фоновых проверок («Критично»); отсутствие basic constraints в модели расширений; «Договорились добавить сюда еще PKUP» (таблица 9). Требуют решения — учесть в ЧТЗ или снять

И09

Таблица 26 (типы записей): колонка keyDateTimeSrc пустая для КСКПЭП и НСКПЭП; размещение сервисного чейнкода (канал, узел) не описано

И10

Таблица 24 (методы формирования UUID): только getUUIDFromCertificate — методы для УЦ и ЭП в документе отсутствуют (вне объёма?)

ID

Замечание

И11

Дубли номеров таблиц: «Таблица 5» (соотношение полей и коды ошибок), «Таблица 8» (логическая отмена и поиск по фильтру), «Таблица 14» (периоды); в главе 4 — «Таблица 19» и «Таблица 20» дважды; подписи не соответствуют содержанию («Таблица 8. Коды ошибок создания записи…» под методом поиска; «Таблица 20. Коды ошибок создания записи…» под методом поиска УНЭП)

И12

Глава 2 (статусная модель) — только диаграмма, текстового описания нет; нумерация процесса п. 3.1.3.1 начинается с пункта 2

И13

Текст vs диаграмма 3.1.3.2: запрос списка отозванных сертификатов из локального хранилища описан только на диаграмме; условие ветки криптографических проверок на диаграмме ошибочно («Отсутствие родительских сертификатов»)

И14

Опечатки: «Приватныe каналs» (п. 4.1), accreditatioStatus (таблицы 12/20; в JSON — accreditationStatus), «полек указывается как target_cert» (таблица 12), validNotBefore (диаграмма 4.2.4.1), subjectPublicKeylnfo (l вместо I)

И15

Артефакты копирования УКЭП→УНЭП: диаграмма 4.2.4.1 («Получение периодов действия аккредитации»), эндпоинт GET /qual-certificates/... в п. 4.1.5, комментарии к /certificate/unqual/*-методам «в приватных каналах квалифицированных сертификатов» (пп. 4.1.2.3, 4.1.3.3)

И16

Имя поля версии истории: versionStatus в модели, version в примере ответа метода изменения статуса (УКЭП); versionStatus в ответе УНЭП

И17

JSON-примеры документа синтаксически некорректны (двойные скобки, пропущенные/лишние запятые) — как эталон тестовых данных использовать нельзя

И18

Приложение «Правила определения типов владельца»: не описывает значение null; регистр констант (UPPER) не совпадает с моделями (lower)

И19

Приложение «Правила регистрации сертификатов в канале»: не содержит терминов КСКПЭП/НСКПЭП и правила для самоподписанных сертификатов; перечень ОГРН ГУЦ/ФК/ЦБ/ФНС в приложении отсутствует (есть только в проверке п. 4.9.2 и на диаграмме «Разделение сертификатов по каналам»)

И20

Диаграммы алгоритмов (приложения, стр. 127–130): пустой блок цикла, ветвление без «Да/Нет», «reason==1 ИЛИ 3» vs «event==1 ИЛИ 3». Алгоритмы существуют только в виде изображений

ID

Замечание

И21

Отказ при регистрации квалифицированного сертификата в канале УНЭП (есть только маршрутизация проверок по channel_type из REGISTRATION_CHANNEL_POLICY; значения: «квалифицированный» / «unqcert_qoskey»)

И22

Коды ошибок для некорректного параметра time в методе «статус на дату» (для обоих типов)

И23

Поведение при исчерпании значений идентификатора реестра и прочие вопросы сервисного чейнкода — частично перекрываются ЧТЗ 4.2.4

И24

Значение «MAC-адрес с дополнением» в структуре _id (п. 5.2)

ID

Замечание

И25

Коды ошибок не определены — ни одного кода ошибки, перечня отказов, реакции на некорректные данные (превышение registryID 31, отсутствие реестра для актива, повторная регистрация). Все негативные ветки ПМИ — с пометкой

И26

Форматы запросов/ответов не определены — аргументы методов заданы обобщённо («an asset as JSON»); форматы полей, обязательность, ограничения не приведены; REST-эндпоинты чейнкода не описаны (способ вызова в ПМИ — нейтрально: «средства вызова методов сервисного чейнкода»)

И27

Формат даты и времени не установлен — поля dateTimeOpened/dateTimeClosed не привязаны к RFC 3339

И28

Расхождение по типам актива — таблица assetType (1–4) против описания GetAssetType («УЦ, СКПЭП, ЭП», диапазон 0..7); термины КСКПЭП/НСКПЭП против «СКПЭП»; OGRN/ОГРН смешаны

И29

Расхождение по границе ротаций — SetRegistry «registryID + 1 (<=31)» против «32 ротации» в п. 2.1 и таблице 6: 32 значения (0–31) = 31 ротация + первичная регистрация либо 32 ротации; поведение при исчерпании не описано

И30

RecordID не описан — возвращается GetRegistersByIssue, в составе БД (п. 2.1) отсутствует; связь с registryID не установлена

И31

Контрольная сумма UUID — формулировка «побитовая сумма последующих триад для последующих 42 бит» неоднозначна; поведение при несоответствии не описано

И32

«Ключевая дата» актива не определена — какая дата ключевая для каждого типа актива, не указано

И33

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

И34

Версионирование s_cc — порядок смены версии, влияние на ранее сформированные идентификаторы и состав признаков типов не описаны

И35

Периодическая ротация — периодичность не определена; каналы в таблице 1 поименованы обобщённо, без привязки к именам из п. 1.1

И36

Две несогласованные схемы именования каналов — п. 1.1 (mcc, mcc_priv, iit_acc_priv…) против приложения (mcc_0, mccpriv_0, aca-1_priv_0 … с индексом поколения); правило формирования имён не задано

И37

Механизм миграции не описан — состав действий по миграции (кроме регистрации канала в s_cc) и судьба идентификаторов активов при ротации не раскрыты

И38

Участники и топология — s_cc развёрнут у каждого участника (по схеме приложения), но требования к размещению service_cc у участников в тексте отсутствуют