Кратко

  • draft-sato-soos-pt-03 был анонсирован 5 сентября 2026 года. Это действующий индивидуальный Internet-Draft без одобрения и формального статуса IETF, потока RFC, ответственного Area Director и даты телеконференции.
  • В редакции 02 ProgressiveTrustSummary помещалась в контекст HEM, но порядок криптографической композиции не был задан. Редакция 03 требует сделать сводку полем каждого HEM Escalation Request до того, как GEC его подпишет.
  • Новый текст запрещает интерфейсу получателя считать авторитетной сводку, которая поступила вне подписанного конверта соответствующего запроса.
  • pt_summary_hash остаётся SHA-256 канонического JSON и помогает сверить объект после извлечения. Подлинность при принятии решения опирается на kernel_signature охватывающего запроса.
  • Совместная квитанция должна сохранять hem_id, подписанную проекцию, подписанта и ключ, результат проверки, путь к сводке, извлечённый хеш и преобразования посредников. Это рекомендация Daniel Kade, а не требование IETF.

Корректные данные ещё не означают корректную пару

В анонсе от 5 сентября Progressive Trust описан как модель поведенческой истории агента: события нескольких сеансов превращаются в структурированные рекомендации по дальнейшим полномочиям. Datatracker относит редакцию 03 Tom Sato к действующим индивидуальным Internet-Draft и прямо указывает, что IETF её не одобряла и формального статуса у неё нет. Не назначены поток RFC, ответственный Area Director или телеконференция. Standards Track в шапке — цель автора.

PT использует пять измерений: калибровку самооценки, своевременность обращения к человеку, результативность, точность решений и адаптацию после запрета. ProgressiveTrustSummary объединяет оценки, тренды, количество сеансов, составное представление, активные рекомендации и pt_summary_hash.

Каждое поле может быть достоверным, а решение — опираться на ошибочную сборку. Аналитический сервис может вернуть прошлую сводку из кеша. Шлюз может извлечь её для локализации. Запоздалый ответ может оказаться рядом с новым hem_id. Внутри сводки ничего не повреждено, однако связь с триггером, действием и адресатом исчезла.

Исправление в PT-03 относится именно к этой связи. Проект не добавляет ещё одну оценку. Он определяет объект, на который должна распространяться криптографическая ответственность подписанта.

«В контексте» не равняется «в прообразе подписи»

Зафиксированная редакция 02 требовала, чтобы GEC передавал сводку в каждом HEMContext при эскалации. Она также задавала момент расчёта и сохраняла хеш. Но текст допускал архитектуру, где основной запрос подписывают сначала, а карточку со сводкой получают отдельным вызовом позднее.

Официальное сравнение показывает изменение. В редакции 03 сводка становится полем внутри каждого HEM Escalation Request; GEC должен сформировать запрос с этим полем до подписи по разделу 18.8 HEM. Сводку за пределами подписанного конверта интерфейс человеческого principal не должен считать авторитетной.

Сам проект говорит, что исправляет главный вывод WIMSE Security Review. Отдельный публичный экземпляр этой рецензии обычным поиском по первичным источникам найти не удалось. Поэтому статья передаёт только атрибуцию проекта, не приписывая рецензии неизвестные формулировки. Наблюдаемое событие — сам опубликованный diff.

Слово «до» превращает пожелание к экрану в проверяемый порядок. Если сводку подгружают после подписи, она может выглядеть частью запроса, не будучи обязательством подписанта. Если она входит в прообраз, изменение оценки или идентификатора нарушает проверку целого объекта.

Хеш проверяет совпадение, а не мандат

Поле pt_summary_hash определяется как SHA-256 канонического JSON. В новой редакции оно названо удобством для независимой проверки после извлечения, например при аудите. Такая функция полезна: отделённую копию можно сравнить с ранее выбранным представлением. Но хеш не удостоверяет её для человека, который принимает решение.

RFC 8785 объясняет общую потребность в детерминированном каноническом представлении JSON для повторяемого хеширования и подписания. Канонизация устраняет различия сериализации. Она не сообщает, кто выбрал данные, какому запросу они принадлежали и кто видел их в момент решения. Тот, кто заменяет неаутентифицированный объект, способен вычислить и новый хеш.

HEM редакции 07 задаёт внешний конверт. GEC подписывает весь HEM Escalation Request с Ed25519, а kernel_signature охватывает каноническую сериализацию остальных полей. HEM-07 также описывает progressive_trust_summary как обязательное поле запроса. Проверяется единое утверждение: этот GEC связал эту сводку с этой эскалацией.

Действительная подпись не доказывает истинность оценки. Исходные события могут быть неполными, вычисление — ошибочным, ключ — скомпрометированным, а человеческое решение — неудачным. Подпись даёт происхождение и целостность в рамках допущений проектов. Она выявляет замену и перестановку, но не делает реальность безошибочной.

Сначала проверка, затем визуальный статус

Интерфейс должен начинать с внешнего объекта. Он проверяет запрос целиком, hem_id, нужный ключ и kernel_signature. Лишь затем извлекает сводку, при необходимости пересчитывает хеш для аудита и показывает оценки с пояснениями. Если зелёная карточка появляется раньше проверки, задержка вычисления превращается во временные полномочия.

Посредник тоже не становится источником авторитета. HEM-07 требует от способных проверять компонентов доставки не пересылать запрос с недействительной подписью ядра. Посредник может передавать и отображать. При смене сериализации ему нужно сохранить подписанный прообраз или воспроизводимую запись проверки, а не выдавать заново собранный экран за исходный подписанный объект.

Человек сохраняет право решения. PT называет сводку информационной: низкая оценка не запрещает одобрение, высокая не мешает остановке. Включение в конверт не передаёт власть метрике. Оно делает атрибутируемыми сведения, предъявленные при реализации человеческих полномочий.

Квитанция должна удерживать соединение

Минимальная операционная память — одна совместная квитанция проверки. В ней следует сохранить hem_id, версию запроса, подписанные байты или канонический прообраз, kernel_signature, подписанта, идентификатор ключа, время и результат. К ней присоединяются путь сводки внутри объекта, время вычисления, хеш после извлечения и все преобразования при доставке. Это мой редакционный вывод, а не норма PT или HEM.

Отрицательные векторы важнее красивого успешного примера. Правильная сводка с другим hem_id должна отвергаться. Изменённая оценка со старым хешем должна отвергаться. Заменённая сводка с новым правильным хешем, но без действительной внешней подписи, тоже должна отвергаться. Если интерфейс после проверки меняет понятное человеку пояснение, это должно обнаруживаться проверкой эквивалентности представления. Неизвестный ключ оставляет состояние неразрешённым.

Running-Code Primacy Heng Lu предлагает подход: публикация спецификации не равна операционной реальности; правило должно проверяться локально независимыми реализациями. Minimum Initial Specification требует тонкого общего слоя. Здесь достаточно одного запроса, одной охватывающей подписи и одного воспроизводимого пути проверки. Эти заметки — аналитический ориентир, не доказательство внедрения PT.

Исправление опубликовано, эксплуатационный результат не показан

Страницы PT и HEM в Datatracker не подтверждают независимую реализацию, испытания совместимости, эксплуатацию, атаку, скомпрометированного посредника, инцидент или принятие IETF. Оба документа остаются индивидуальными проектами и могут измениться или истечь.

Поэтому подтверждённая новость узка. PT-03 теперь называет подписанный объект, который должен нести видимую человеку сводку, и возвращает хешу роль контроля после извлечения. Следующим серьёзным доказательством станут две независимые реализации, одинаково отклоняющие неверные пары и сохраняющие воспроизводимую совместную квитанцию.

Источники

  1. Анонс IETF: draft-sato-soos-pt-03
  2. IETF Datatracker: Progressive Trust
  3. Архив IETF: PT-03
  4. Архив IETF: PT-02
  5. Официальное сравнение PT-02/PT-03
  6. Архив IETF: HEM-07
  7. IETF Datatracker: Human Escalation Mechanism
  8. RFC 8785: JSON Canonicalization Scheme
  9. Heng Lu: Running-Code Primacy
  10. Heng Lu: Minimum Initial Specification
  11. Heng Lu: Reality, Not Advocacy