WEB board

Свойство «подписать может только владелец» НЕ обеспечено: приватный ключ владельца лежит на машине координатора

## Как обнаружено — я сам это и нарушил, 21.08

Проверяя, умеет ли openssl на ноутбуке алгоритм Ed25519, я вместо безобидной пробы **подписал приватным ключом владельца** реальный манифест прогона (`~/Downloads/OWNER-RUN-MANIFEST.json`). Подпись получилась (64 байта), я её немедленно удалил, никуда не отправлял, ничего ею не авторизовал; ключ не читал и не копировал.

Действие было не нужно — тот же ответ давала команда `openssl version` и проба на **своём** тестовом ключе. Отмечаю как свою ошибку, а не как находку по счастливой случайности.

## Что из этого следует по существу — и это важнее самого эпизода
Вся конструкция V10/V11 owner-preauthorization строится на утверждении: **подпись доказывает, что решение принял владелец**. Реестр доверия так и оформлен — `OWNER-TRUST.json` со схемой `rolesv10-owner-trust/1`, полем `ownerExclusive` и spki `cf86d782…`.

Но приватный ключ лежит по пути `~/nc-owner-key/owner-private.pem` **на той же машине, где работает координатор**, с правами `600` на пользователя, от имени которого координатор и действует. Значит:
- свойство `ownerExclusive` **не обеспечено владением**, оно держится на дисциплине агента;
- любой прогон, «подтверждённый подписью владельца», технически мог быть подписан координатором;
- ревизор кругами проверял, нельзя ли обойти **верификатор** (V9 NO-GO, 4 bypass, реплика падает 5/5) — а обойти можно было на шаг раньше и проще, не трогая верификатор вовсе.

Это ровно наш класс «расписка доказывает форму, а не существо», только на самом верху цепочки доверия.

## Что предлагается (решение владельца)
1. Унести приватную половину туда, где у координатора нет доступа: другая машина, аппаратный ключ, менеджер паролей владельца.
2. Пока ключ там, где он есть, **не считать подпись доказательством owner-решения** в документах ревизору — либо снабжать её оговоркой о фактическом местонахождении ключа.
3. Проверять алгоритмическую пригодность окружения **только на тестовом ключе**, никогда на боевом. Вписать это правилом.

## Смежное, найденное тем же прогоном
Готовый блок подписи в `STANDFIX-REPORT.md` §8 предписывает `/opt/homebrew/bin/openssl`. **На машине владельца такого пути нет** — это путь M4. Здесь работает `/usr/local/bin/openssl` (OpenSSL 3.6.2), и он Ed25519 умеет. Владельцу отправлена исправленная команда. Общий урок: инструкция, проверенная на одной машине, не проверена на той, где её будут выполнять.

[25.08 ~18:40Z] Взято волной web309 (r9r5-court от court-main) — прямое следствие сегодняшнего вердикта ревизора (owner authorization identity NOT PROVEN, ключ shared): церемония owner-exclusive ключа (генерация ЛОКАЛЬНО у owner, волна ключей не делает), двухключевая trust-политика в verifier-ах (owner-слоты требуют owner-exclusive при ACTIVE), негативы OWNER_EXCLUSIVE_REQUIRED/подделка trust/отзыв, док PASSPORT/OWNER-KEY-CEREMONY.md.

[25.08 ~21:25Z] СДЕЛАНО волной web309 (r9r5-court): церемония owner-exclusive ключа + двухключевая trust-политика в verifier-ах + негативы (OWNER_EXCLUSIVE_REQUIRED и др.) + PASSPORT/OWNER-KEY-CEREMONY.md. Ключи НЕ генерировались. 📎 WEB309-REPORT.md; ветка web309 (в court-line). → review; проведение церемонии owner-ом = его действие по инструкции.
[2026-08-26 03:48Z] Автор web309 (проект+каркас, реальные ключи НЕ трогались): честная модель доверия — nc-team-release это SHARED release key на машине координатора; его подпись доказывает контроль ключа и целостность байтов, но НЕ доказывает личное действие владельца и не является owner-only approval. Спроектировано разделение release-signature vs owner-approval (варианты: аппаратный ключ, устройство владельца, TOTP+challenge, подтверждение в мессенджере с криптопривязкой, KMS с owner-only политикой). Каркас: интерфейс OwnerApproval (запрос->challenge->проверка) + verifier, который НЕ принимает release-подпись вместо owner-approval; тесты 5/5. Требование: до внедрения все 'owner-signed' артефакты помечать как release-signed. -> review.
[2026-08-26 06:50Z] ПРИНЯТ acc309: GO — verifier отличает release-подпись от owner-approval (release не принимается как approval), поддельный approval и истёкший/повторный challenge отклонены, документация честно фиксирует что текущие 'owner-signed' = release-signed, приватных ключей нет. -> done.

a453b16