Кратко

  • В редакции 04 профиля SCITT доказательство включает лист-кандидат и путь из соседних хешей с признаком «слева/справа», но не содержит ни размера дерева, ни явного индекса листа.
  • Пересчитать корень и проверить подпись COSE по-прежнему можно. Неоднозначность возникает, когда результат проверки превращают в утверждение о порядке или позиции.

Для дерева из двух листьев путь 1 соответствует индексу 1. Для деревьев из трёх, пяти и девяти листьев тот же путь соответствует индексам 2, 4 и 8. Бит не меняется. Меняется невидимый для квитанции контур дерева.

Эта деталь вышла в публичное обсуждение во время IETF Last Call по редакции 04 CCF Profile for COSE Receipts. Datatracker указывает поток IETF, предполагаемый статус Proposed Standard, передачу в IESG и текущее состояние «In Last Call». Обсуждение идёт с 24 августа по 7 сентября 2026 года. Документ остаётся Internet-Draft, а не RFC; замечание не означает ни принятия, ни отклонения.

Проверенный корень не является координатой

Профиль использует правило построения, знакомое по Certificate Transparency. Если листьев больше одного, дерево делится по наибольшей степени двойки, меньшей общего размера. При размере, равном степени двойки, дерево сбалансировано. В промежуточных случаях справа остаётся меньшая ветвь.

В разделе 3 доказательство состоит из листа и массива соседних хешей. У каждого хеша есть булево значение стороны. Проект говорит, что последовательность сторон можно читать снизу вверх как двоичное разложение индекса. В сбалансированном дереве это верно. Для всех форм, которые создаёт то же правило деления, — нет.

6 сентября Henri Sirkkavaara исправил свой первоначальный отзыв, проверив размеры от 2 до 11. Для 2, 4 и 8 все индексы совпали. Каждый размер, не являющийся степенью двойки, содержал хотя бы один лист, чей путь декодировался в неверный порядковый номер.

Emek Can Dogru независимо воспроизвёл результат и опубликовал программу из одиннадцати строк. В диапазоне до 1 024 только десять степеней двойки дали точный результат для каждого листа. В остальных 1 013 размерах обнаружилось хотя бы одно расхождение. Исходный текст проверки показывает структурную неоднозначность, а не взлом хеша.

Алгоритм из раздела 3.2 от этого не перестаёт работать. Проверяющая сторона берёт хеш кандидата, добавляет соседей с указанной стороны и получает корень. Если подпись COSE покрывает получившийся корень, включение кандидата подтверждено. Глобальный номер листа для такого расчёта не требуется.

Значит, квитанция отвечает на узкий вопрос: «Включён ли этот кандидат под этот подписанный корень?» Она не всегда отвечает на другой: «Каким по счёту он был?» Ошибка появляется не в вычислении, а в интерфейсе или политике, которые незаметно подменяют первый вопрос вторым.

В соседних стандартах система координат задаётся явно

RFC 9162 принимает размер дерева и индекс листа как отдельные входы проверки включения в Certificate Transparency 2.0. Профиль COSE из RFC 9942 кодирует обе величины и подчёркивает, что индекс определяется относительно конкретного размера.

Это не служебные украшения. Они задают координатную систему, в которой слово «позиция» имеет общее значение. Номер без размера неполон; путь без размера и номера может описывать несколько мест.

Конкретное развёртывание CCF может знать больше. Документация Microsoft показывает получение квитанции по идентификатору транзакции; commit_evidence может раскрывать полный TxID. В профиле SCITT есть строка internal-evidence, но проверяющая сторона вправе её игнорировать, а раздел 3 не определяет её как переносимый формат позиции. Внешний контекст может помочь одной системе, не делая саму квитанцию самодостаточной.

Участники назвали замечание неблокирующим и продолжили поддерживать публикацию. Речь не шла о поддельной подписи, коллизии, неверном корне, сбое реализации или инциденте. В сообщении о возможной правке Sirkkavaara отметил, что длина пути тоже требует знания размера, и предложил явный индекс.

Смысл расширяется уже после проверки

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

Минимальная начальная спецификация Heng Lu предлагает стандартизовать узкий общий инвариант, а усиленные гарантии принимать там, где они нужны. Слои реальности не позволяют математическому отношению незаметно стать институциональным рассказом о порядке. Приоритет работающего кода требует сохранять реальные входы проверки, а не позднее толкование зелёного индикатора.

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

Источники

  1. Запись документа в IETF Datatracker
  2. История событий в Datatracker
  3. CCF Profile for COSE Receipts, редакция 04
  4. Объявление IETF Last Call
  5. Исправление Henri Sirkkavaara
  6. Независимая проверка Emek Can Dogru
  7. Сообщение о варианте исправления
  8. Код воспроизведения
  9. RFC 9162
  10. RFC 9942
  11. RFC 9943
  12. Документация по проверке CCF
  13. Heng Lu: минимальная начальная спецификация
  14. Heng Lu: слои реальности
  15. Heng Lu: приоритет работающего кода