Сверка действующих текстов ЧТЗ/ПМИ РР ОИОК с обновлёнными источниками

Что сверялось

Источник

ЧТЗ РР ОИОК v05 (полный текст)

/opt/pki/work/ps01/ЧТЗ_РР_ОИОК_v05.md

ПМИ РР ОИОК v05, приложение А (А.1–А.10, строки 1–121)

/opt/pki/work/ps01/ПМИ_РР_ОИОК_v05.md

Снимок 261002 «Описание структур данных, процессов, методов реестра сертификатов УЦ»

конспект /opt/pki/work/ps01/конспект_261002_реестр_сертификатов.md; выборочная сверка по /opt/pki/tmp/261002_extract.txt

Сценарий показа ротации каналов 260930

конспект /opt/pki/work/ps01/конспект_260930_ротация_каналов.md

Диаграммы последовательности (обновлённые)

/opt/pki/exchange/диаграммы-последовательности.md

№

Место в ЧТЗ/ПМИ (цитата-фрагмент)

Что в снимке 261002

Характер

Предлагаемое действие

Э-1

ЧТЗ 4.2.1.1: «POST /certificate/guc/create — для канала аккредитации и сертификатов ГУЦ, POST /certificate/qual/create»; 4.2.1.2: «POST /certificate/guc/status-update … POST /certificate/qual/status-update»; 4.2.1.3: «POST /certificate/guc/certificate-cancel … POST /certificate/qual/certificate-cancel»

Пути переименованы: POST /guc-certificates/guc/create, POST /qual-certificates/qual/create, …/status-update, …/certificate-cancel (конспект 261002, разд. 3.1–3.3; разд. 7 п. 3)

устарело (ЧТЗ опирается на прежнюю редакцию)

Правка ЧТЗ — после решения В-1 (канонический набор путей)

Э-2

ЧТЗ 4.2.2.1: «POST /certificate/goskey/create», «POST /certificate/unqual/create»; 4.2.2.3: «POST /certificate/goskey/status-update»

Переименовано: POST /goskey-certificates/goskey/create, POST /certificates/unqual/create, POST /goskey-certificates/goskey/status-update, POST /certificates/unqual/status-update (разд. 7 п. 3)

устарело

Правка ЧТЗ — после решения В-1

Э-3

ЧТЗ 4.2.2.4: «POST /certificate/goskey/certificate-cancel и POST /certificate/unqual/certificate-cancel»

В п. 4.1.4 снимка префиксы отмены НСКПЭП не переименованы — совпадают с ЧТЗ, но противоречат общему переименованию снимка (З-7)

неоднозначность источника

Правок не требуется; учесть при снятии З-7 (В-1)

Э-4

ЧТЗ 4.2.1.4: «GET /certificate/qual/search?param=…»; «GET /certificate/qual/{YYYY-MM-DDTHH:MM:SSZ;hashTBS}/info?logicalCancelFlag=False»; 4.2.2.5 — аналогично для unqual

В п. 3.1.6 снимка пример «GET /certificate/qual/search» сосуществует с таблицей «/qual-certificates/ search…»; в п. 4.1.5 — артефактный блок /qual-certificates/…/info (З-7)

неоднозначность источника

В-1; правка — после решения

Э-5

ЧТЗ 4.2.8.1: «GET certificate-validity/qual/all?cert=…»; 4.2.8.2: «…/by-date»; 4.2.8.3: «…/periods»

Переименовано: GET qual-certificate-validity/qual/all, …/by-date, …/periods (разд. 7 п. 3; tmp/261002_extract.txt, стр. 1574, 1628, 1915)

устарело

Правка ЧТЗ — после решения В-1

Э-6

ПМИ А.1 ш. 1–2, А.4 ш. 1–2: «POST /certificate/qual/create», «POST /certificate/qual/status-update», «GET /certificate/qual/{cert}/info»

Переименование (см. Э-1)

устарело

Правка ПМИ — после решения В-1

Э-7

ПМИ А.1 ш. 3: «запрос „Логическая отмена“ (POST /certificate/qual/cancel)»

В ЧТЗ 4.2.1.3 и снимке 261002 метод отмены — …/certificate-cancel (разд. 3.3); имя /cancel используется в сваггере (/certificate/qual/cancel, /certificate/guc/cancel — см. /opt/pki/work/ps01/анализ_коллекции_и_swagger.md, п. 9)

неоднозначность (три источника расходятся)

В-1: закрепить имя метода; затем правка ПМИ либо ЧТЗ

Э-8

ПМИ А.2 ш. 1–2: «POST /certificate/goskey/create», «POST /certificate/unqual/status-update»

Переименование (см. Э-2)

устарело

Правка ПМИ — после решения В-1

Э-9

ПМИ А.8 ш. 1–3: «GET /certificate-validity/qual/all», «…/by-date», «…/periods»

Переименование (см. Э-5)

устарело

Правка ПМИ — после решения В-1

Э-10

ПМИ А.2 ш. 3, А.5 ш. 3, А.9 ш. 1–3; ЧТЗ 4.2.9.1–4.2.9.3: «certificate-validity/unqual/…», «/certificate/unqual/…»

Префиксы НСКПЭП в снимке не изменялись (З-7)

согласовано (оговорка — артефакт п. 4.1.5, см. Э-4)

Правок не требуется

№

Место в ЧТЗ/ПМИ (цитата-фрагмент)

Что в снимке 261002

Характер

Предлагаемое действие

С-1

ЧТЗ 4.2.1.1 п. 7: «создание записи в истории изменения статуса с событием «1» (начало действия сертификата)»; 4.2.4.2 табл. 8: «1 — начало действия сертификата»; 4.2.4.3: «модель истории с записью события «1»»; 4.2.8.3: «событие «1» (начало действия) задаёт период»

«Создается запись в истории изменения статуса: поле «event» принимает значение 16» (п. 3.1.3.3, шаг 3); примеры истории — "event":"16"; при этом табл. 4/10 сохраняют коды событий 0–3 (З-4)

противоречие (с внутренним противоречием снимка)

В-2; правка ЧТЗ — по решению

С-2

ЧТЗ 4.2.4.2 табл. 9: причины прекращения 0–6, 9, 10; возобновления — 8

Причинная модель снимка (gherkin, «Таблица 17»): причины 0,1,2,3,4,5,6,8,9,10,11,16; расшифровок 4–11 и 16 в источнике нет; «событие „аннулирование“ — то 0, то причина 11» (З-4)

новое/неполнота

В-9: дополнить перечень причин либо зафиксировать толкование; расшифровки 4–11/16 запросить у источника

С-3

ПМИ А.1 ш. 2 («история из двух событий: «1»… и «2»»), А.4 ш. 1–2 («event = 1»), А.5 ш. 1–3, А.8 ш. 1, А.9 ш. 1 — ожидаемые JSON содержат "event": "1"

При регистрации event = 16 (З-4). Фактический стенд (сценарий 260930, разд. 5.1, 6.1, 7.1) показывает event = 1

противоречие (ПМИ ↔ снимок; стенд — на стороне ПМИ)

В-2; правка ПМИ — только при выборе варианта «16»

№

Место в ЧТЗ/ПМИ (цитата-фрагмент)

Что в снимке 261002

Характер

Предлагаемое действие

Д-1

ЧТЗ 4.2.8.2/4.2.9.2 и ПМИ А.8 ш. 2, А.9 ш. 2 — расширенный вариант: «по каждому сертификату цепочки доверия (target_cert, sub_ca, root_cert): идентификатор сертификата (certId), статус сертификата в цепочке (localStatus…), статус аккредитации УЦ издателя (accreditationStatus)…»

В снимок 261002 добавлен второй (упрощённый) вариант ответа: {root_cert, sub_ca, target_cert: {cert, event, valid, privateKeyStatus}, resultStatus} (пп. 3.2.5.3, 4.2.3; разд. 7 п. 5; расхождение форматов — З-6)

новое

В-3: какой вариант включать в ЧТЗ/ПМИ (или оба)

Д-2

ЧТЗ 4.2.8.2: «privateKeyStatus… True…/False…; если период не указан, статус ключа не указывается»; ПМИ А.8/А.9 — значение true (boolean)

В табличной форме снимка privateKeyStatus — строка: «Действует / Не действует / Периоды действия секретного ключа отсутствуют»; в варианте 1 — boolean (З-6)

неоднозначность

В-3: закрепить тип значения и поведение при отсутствии периода

Д-3

ЧТЗ 4.2.8.2 — в составе ответа target_cert не упомянут isChecked

В варианте 1 снимка у target_cert есть isChecked; ПМИ А.8 ш. 2 проверяет «isChecked = true»

пробел ЧТЗ

Правка ЧТЗ (добавить isChecked) — после решения В-3

№

Место в ЧТЗ/ПМИ (цитата-фрагмент)

Что в снимке 261002

Характер

Предлагаемое действие

О-1

ЧТЗ 4.2.8.1–4.2.8.3 (и 4.2.9.1–4.2.9.3): «Коды ошибок: ERR-0010…, ERR-0729…»

Таблицы публичного канала содержат слитые коды «ERR-072914» (ERR-0010/ERR-0729/ERR-0714?) и «ERR-07140729» (табл. 11/13/14; З-5); для НСКПЭП — ERR-0729 (табл. 19/21)

дефект источника

В-11: подтвердить толкование (ERR-0729; возможен ERR-0714)

О-2

ЧТЗ 4.2.1.1 п. 3: «отказ при наличии записи с таким идентификатором и logicalCancelFlag = False»

ERR-0721 «Сертификат с таким _id уже существует в реестре» — без оговорки logicalCancelFlag (табл. 5/15)

неоднозначность

Уточнить условие отказа у владельца источника; при необходимости — правка ЧТЗ

№

Место в ЧТЗ/ПМИ (цитата-фрагмент)

Что в обновлённых источниках

Характер

Предлагаемое действие

М-1

ПМИ А.5 ш. 2: «тип сертификата… зафиксирован в записи как END_ENTITY»; ожидаемый JSON — "certType": "END_ENTITY"

Поля certType в моделях снимка нет; тип фиксируется как registration_json.owner_type ∈ {ROOT_CA, SUB_CA, END_ENTITY, null} (п. 4.7); модель приватного канала содержит ownerType с другим словарём (З-11)

противоречие/неоднозначность

В-10: закрепить имя и словарь поля; затем правка ПМИ

М-2

ЧТЗ 4.2.7.3 табл. 16: «5 бит — Идентификатор реестра (начинается с 00000)»; «32 бита — Идентификатор владельца реестра»; «возможно 32 ротации канала»

§5.2 снимка: «13 бит — идентификатор реестра. номер пары канал/чейнкод для данного УЦ (начинается с 0000000000000)»; «24 бита — идентификатор издателя сертификата. 32 MSB от хэша ОГРН…»; внутренние несоответствия (4+12+2+62=80; ссылка «согласно таблице 23») (З-13; tmp/261002_extract.txt, стр. 3631–3633)

противоречие (ЧТЗ — по редакции 260714)

В-4

М-3

ЧТЗ 4.2.7.5 табл. 20: три метода — «getUUIDFromCenterOfAuthority», «getUUIDFromCertificate», «getUUIDFromDigitalSignature»

Табл. 24 снимка содержит только метод 9 «getUUIDFromCertificate»; два других в снимке 261002 отсутствуют (в 260714 — табл. 6; конспект 260930, разд. 8–9)

устарело/не подтверждено

В-4: уточнить состав методов формирования UUID

М-4

ЧТЗ 4.2.4.4: «идентификатор актива (74 младших бита хэша серийного номера сертификата)»

§5.2 снимка: «74 LSB от хэша serialNumber» и ниже «74 LSB от структуры serialNumber» — противоречие внутри источника (З-13)

неоднозначность источника

Зафиксировать толкование ЧТЗ (низкий приоритет)

М-5

ПМИ А.1 ш. 1, А.2 ш. 1, А.4 ш. 1, А.5 ш. 1: ответ на создание записи — {"cert": "YYYY-MM-DDTHH:MM:SSZ;hashTBS"} (совпадает со снимком, пп. 3.1.3.3/4.1.2.3)

Сценарий 260930 (разд. 2.1–2.3, 4.1): фактический стенд возвращает расширенный JSON (id, idCertificate, idIssuerCertificate, uuidIssuerCertificate, parentCertOGRN, accreditationID, isCA, warnings, isChecked, createdAtCC); модели ответов POST и GET различаются (конспект 260930, замечание 6)

противоречие ЧТЗ/ПМИ ↔ фактический стенд

В-5: согласовать модель ответа для ПМИ

М-6

ПМИ А.2 ш. 2: ответ изменения статуса УНЭП — {"version": "2", "event": "2", …}

В п. 4.1.3.3 снимка ответ НСКПЭП использует versionStatus (в КСКПЭП п. 3.1.4.3 — version) (З-10; extract, стр. 1203 и 1556)

противоречие

Правка ПМИ — после снятия З-10 (либо закрепить фактическое имя, сверенное со стендом)

М-7

ЧТЗ 4.2.1.2/4.2.2.3: запрос изменения статуса — «с указанием идентификатора сертификата (cert), времени… (updatedAt) и события (event)» — причина не упомянута

ПМИ А.1 ш. 2 передаёт "reason": "1" и ожидает его в ответе; сценарий 260930 (разд. 6.1–6.2) передаёт и получает reason; пример запроса снимка (п. 3.1.4.3) — без reason, при этом «Таблица 17» оперирует «причиной в запросе» (З-4)

неполнота/неоднозначность

Правка ЧТЗ: дополнить состав параметров (reason)

№

Место в ЧТЗ/ПМИ (цитата-фрагмент)

Что в снимке 261002

Характер

Предлагаемое действие

П-1

ЧТЗ 4.2.1.1 п. 6: «полная криптографическая проверка цепочки доверия и статуса отзыва» — поведение при неуспехе не описано

П. 2.7.5 снимка: неуспех не завершает выполнение фатальной ошибкой — фиксируется предупреждение и «error_depth»; перечень CHAIN_CRYPTO_* (конспект, разд. 5.2; extract, стр. 1032, 3713–3716)

пробел (не связан с изменениями 261002 — присутствует и в прежней редакции)

В-13: решить, дополнять ли ЧТЗ

№

Место в ЧТЗ/ПМИ/источнике (цитата-фрагмент)

Что в обновлённых источниках

Характер

Предлагаемое действие

Р-1

Диаграмма 1 «Выпуск сертификата», группа «Закрепление идентификатора отдельной транзакцией»: REST-прокси → RegistryContract — запись «{сертификат, ОГРН издателя, публичный канал пары}», «фиксация записи в журнале коллизий», ответ {"uuid": "…"}; при регистрации прикладной чейнкод отдельно запрашивает идентификатор (конспект 260930, разд. 8, 13 п. 1)

В снимке 261002 механизма нет: UUID формируется методом getUUIDFromCertificate при проверке коллизий в сервисном чейнкоде (§5.2); в 260714 отдельной транзакции нет; ЧТЗ 4.2.4.4 описывает формирование _id при создании записи (без закрепления отдельной транзакцией); ПМИ соответствующий шаг не проверяет

новое в диаграммах, не согласовано с ЧТЗ и снимком

В-6

Р-2

Диаграмма 1: «RegCC → RegCC: фиксация записи в журнале коллизий»

«Журнал коллизий» как отдельная сущность в снимке 261002 не описан; есть запись о коллизии в сервисной БД (§5.2, табл. 25: collisionID, uniqueIDForCollision; конспект, разд. 3.5); в 260714 термина нет (конспект 260930, разд. 13 п. 2)

новое/неоднозначность

В-6

Р-3

Диаграммы 1 и 2: «определение канала по ОГРН своей организации»; для ГУЦ — примечание «Канал не определяется по ОГРН — вызов направляется в прикладной чейнкод координационного канала» (конспект 260930, разд. 10, 13 п. 3–4)

ЧТЗ 4.2.7 п. 7: маршрутизация — функцией сервисного чейнкода (возврат пары «канал + чейнкод»); снимок 261002 — так же (§5); 260714 — «полностью через сервисный чейнкод»; ни снимок, ни ЧТЗ не описывают выбор канала REST-прокси и термин «координационный канал»

противоречие диаграмм с ЧТЗ 4.2.7 и 261002

В-7

Р-4

ЧТЗ 4.2.7.1 табл. 14 — 10 шагов ротации (по 260714)

Сценарий 260930, разд. 3: «Выполняется ротация, демонстрация в консоли»; шаги, команды и ожидаемые результаты не зафиксированы; в файле 261007 команд ротации нет (только чтение) (конспект 260930, разд. 3, 11, замечание 1)

не подтверждено сценарием

В-8: ПМИ А.7 шаги ротации процедурно не проверяет — принять как ограничение либо дополнить сценарий/ПМИ

Р-5

ПМИ А.7 ш. 1–2: «Вызвать метод „Регистрация реестра“ (POST /registry/set)» с полями mspid, ogrn, x509Address, channel, chaincode, private_channel, private_chaincode, assetType

Endpoint в снимке 261002 отсутствует (SetRegistry — метод сервисного чейнкода, табл. 23; способ вызова не описан). Состав полей воспроизводит коллекцию r1/ПМИ_АКК.postman_collection.json (без assetType), но не совпадает с табл. 25 снимка и табл. 15 ЧТЗ (MSPID, issuerID, issuerIDAddon, roundsNum, assetType, channelName, chaincodeName, …; полей x509Address/private_channel/private_chaincode нет). В 261007 подтверждён только RegistryContract:ListRegistries (чтение)

не подтверждено/несогласованность источников

В-8: согласовать интерфейс и состав полей

Р-6

ЧТЗ 4.2.7.1: «канал ГУЦ (mcc)», «Сервисный чейнкод (service_cc)», системные имена с индексом поколения

261007/260930: стендовые имена — mca-channel, aca-pub-channel, iit-aca-priv-channel-2; main_cc_chaincode, service_chaincode, aca_pub_chaincode, iit_acc_priv_chaincode; диаграммы — «координационный канал»; снимок 261002 системных имён не содержит (З-20). Терминология не унифицирована (конспект 260930, замечание 19)

неоднозначность

В-7: закрепить единую терминологию и системные имена

Р-7

ЧТЗ 4.2.7 п. 2: «создание нового канала с миграцией на него актуальной бизнес-логики и участников с сохранением возможности доступа к данным ранее созданных каналов» (общая формулировка)

Механизм переключения маршрута на новый канал после ротации (как REST-прокси/чейнкод узнаёт о ротации) не описан ни в 260930, ни в диаграммах, ни в снимке 261002 (конспект 260930, разд. 10)

пробел

В-7

Р-8

Диаграмма 1: прямой вызов «BizCC → RegCC» (прикладной чейнкод приватного канала → сервисный чейнкод координационного канала)

В Hyperledger Fabric прямое обращение чейнкода к чейнкоду другого канала штатно невозможно; механизм межчейнкодного взаимодействия в обновлённых материалах не описан (конспект 260930, замечание 20); в снимке 261002 отсутствует

архитектурный пробел

В-6/В-7: уточнить механизм для описания в ЧТЗ