WEB board

P0 РЕШЕНИЕ ВЛАДЕЛЬЦА: ключ подписи лежит на машине координатора — ревизор не признаёт свойство owner-signature

Вердикт FACTCHECK-V2M-R20 (19.08), finding R20-AUD-002 HIGH/BLOCKING. Подпись математически верна (signerId nc-owner, отпечаток sha256:74a4dcad3a69c8adec6b073d8a327091c697d5f1520e3375627e8ad0d815b364, verification PASS), и мы САМИ раскрыли, что криптооперацию выполнил координатор ключом владельца. Ревизор: криптография доказывает использование ключа, но НЕ доказывает (1) что операцию выполнил лично владелец, (2) что его сообщение в Telegram привязано именно к преимиджу 87753e73…, (3) что делегация была формально ограничена, (4) что ключ остаётся ИСКЛЮЧИТЕЛЬНО под контролем владельца. В пакете нет owner-signed delegation object, связывающего coordinator key / envelopeSha256 / releaseId / allowed verdict / scope / expiry / revocation. ⚠️КАСАЕТСЯ И РОЛЕЙ: в ROLES-CLOSURE-V5-SIGNED использован ТОТ ЖЕ ключ 74a4dcad; там владелец подписывал ЛИЧНО (это плюс), но сам ключ физически лежит на ноутбуке ~/.ssh/nc-owner-sign.pem, к которому имеет доступ координатор — та же претензия применима.

## 2026-08-23 BOARDSWEEP: DEAD-SOUL-CLAIM
- Evidence: updatedAt=2026-08-19T20:57:40.777Z, older than 24h at sweep cutoff 2026-08-22T17:35:00Z; no active owner-signature wave or process named in the workspace. Candidate for return to todo; status unchanged.
- buildFixed: <empty>; canonical: v4-081ff4fb5 / 081ff4fb5f6110f8001daec7ed910ccef2e395dc.
- Status preserved by sweep: in_progress.

jq {signerId,keyFingerprint,allowedReleaseIds} factcheck-trust-policy.json; find . -type f | grep -Ei delegat|authoriz|signing-ceremony|custody -> package-bound delegation evidence отсутствует.

Владелец выбрал путь и он реализован: (а) новый owner-exclusive ключ на устройстве владельца + новый внешний policy pin + переподпись + отзыв прежнего разделяемого ключа [рекомендация ревизора и координатора]; ИЛИ (б) delegated-signing: owner-signed delegation certificate (coordinator key, exact envelopeSha256, releaseId, allowed verdict, scope, expiry, revocation), координатор подписывает СВОИМ ключом, верификатор проверяет цепочку; ИЛИ (в) trust policy честно называет ключ coordinator/release key, а не nc-owner.

[24.08 ~00:10] OWNER-РЕШЕНИЕ (voice 23:04): вариант (б) — доверенность. План: (1) сгенерировать ОТДЕЛЬНЫЙ координаторский ed25519-ключ (не owner-ключ); (2) составить owner-signed delegation object: coordinator pubkey fingerprint + scope (какие releaseId/типы подписей) + expiry + revocation-условие; (3) владелец подписывает доверенность ЛИЧНО (одноразовое действие — обсудить механику: его машина или контролируемая сессия); (4) дальнейшие релизы подписываются координаторским ключом, цепочка: owner→delegation→coordinator; (5) в пакеты класть delegation вместе с подписью. Закрывает findings R20-AUD-002 (и аналог в ролях). Родня: WEB-284, WEB-088, WEB-320.
[25.08 ~17:30Z] СВИП: решение реализовано двухфазным конвертом rolespack14b — подпись фазы 1 честно задекларирована как shared release key nc-team-release (не owner-exclusive), фаза 2 = подпись ревизора в его слот. Ревизор в вердикте 25.08 по фактчеку ЯВНО принял эту trust policy (PASS). Ждём FINAL GO по ролям (конверт у ревизора) → закрывать.

[BOARDTRIAGE] Последнее движение: 25.08 17:30Z. Двухфазная trust policy принята ревизором; оставшийся FINAL GO относится к приёмке ролей WEB-108. Рекомендуется закрыть как superseded.

РЕШЕНИЕ ВЛАДЕЛЬЦА ПРИНЯТО 19.08: вариант (в) — честное переименование. Ключ (тот же, отпечаток 74a4dcad…) в trust policy и signature переименовывается nc-owner → nc-team-release; добавляется custodyModel: shared-operational с пояснением, что ключ у команды и координатор оперирует машиной, где он лежит; из верификатора и документации убираются формулировки owner signature (статус owner-signature-verified → release-signature-verified); fail-closed НЕ ослабляется (негативный тест R19-AUD-002 обязан остаться зелёным); добавляется тест, что в пакете не осталось строк, заявляющих owner-подпись при team-ключе. Волна r21 выполняет. ⚠️ПОСЛЕДСТВИЕ, зафиксировано осознанно: пакеты БОЛЬШЕ НЕ ЗАЯВЛЯЮТ свойство «подписано лично владельцем». Для фактчека это приемлемо (там свойство не требовалось). ДЛЯ РОЛЕЙ (ROLES-CLOSURE-V5-SIGNED) блокер 3 был именно про owner authorization: владелец подписывал ЛИЧНО, но ключ общий, поэтому ревизор может не признать криптографическую эксклюзивность. Остаточное доказательство для ролей: сырая запись MessageLog (id cmszxc6hk01dgvnvsbf1ruqh6, userId cmmqphkdw0000247m2m56dl0l = _@wool2.online, 2026-08-19 10:03:47.288, «Кап подтверждаю») + факт, что команду openssl выполнял владелец на своей машине. Если ревизор не примет — точечно выпустить owner-exclusive ключ ТОЛЬКО под эту подпись (владелец предупреждён заранее).