Summary

  • В Vaara Receipt revision 12 поля seq и runningCount могут быть подписанно связаны с одной boundary; если сохранилась более поздняя запись, удалённый номер в середине становится доказуемым пробелом.
  • Непрерывный префикс 0..k не показывает удалённый хвост. Терминальная seal фиксирует итог N, но исчезновение хвоста вместе с seal не создаёт противоречия в оставшемся наборе.
  • Draft выносит этот остаток во внешний RFC 3161 anchor финального счётчика. Подпись, coverage, внутренняя полнота, закрытие, временное свидетельство и эффект действия проверяются раздельно.

Два набора с одинаковым последним номером

Первый набор действительно заканчивается на квитанции 24. Во втором система выпустила ещё десять записей, но держатель удалил 25..34. Для аудитора оба набора выглядят одинаково: квитанция 24 честно говорит, что к тому моменту существовало двадцать пять записей.

Если удалить только 12, оставив 13, более поздний runningCount выдаст несоответствие. Поэтому последовательность хорошо обнаруживает внутреннюю потерю. Она не может заставить старую запись знать о будущем продолжении.

draft-sirkkavaara-vaara-receipt-12 строит механизм именно вокруг этой границы. Он не объявляет проверяемую подпись универсальным индикатором полноты, а добавляет отдельные уровни для наблюдаемой области, счёта и завершения.

Сначала область наблюдения

Необязательный блок coverage называет chokepoint, отпечаток поверхности инструментов или команд и правило, что учтены лишь вызовы через него. Прямой путь, другой proxy или локальное выполнение остаются вне утверждения.

Поэтому отсутствие квитанции об отказе не означает, что действие не происходило. С coverage оно означает лишь отсутствие отказа внутри указанной boundary. Без coverage это только отсутствие наблюдения в представленном наборе.

Блок completeness связывает boundaryId, монотонный seq с нуля и runningCount = seq + 1. Более поздняя квитанция создаёт подписанное ожидание относительно предшествующих. Пропуск внутри удерживаемого диапазона можно обнаружить без доступа к эмитенту.

Финальная seal и её хранитель

Закрывающая запись сообщает {sealed: true, total: N}. Если она сохранена, аудит ожидает N элементов и видит усечённый хвост. Необязательное maxClass может ограничить максимальный класс действия, которое скрытая запись могла разрешить.

Но seal сама входит в историю. Сторона, способная скрыть suffix, может скрыть и финальную запись. Тогда префикс остаётся валидным, а внутри held set нет информации о пропавшем закрытии. Draft прямо называет этот остаток неразрешимым из одного набора.

Следующий уровень — RFC 3161 timestamp над финальным count. Он свидетельствует, что к времени T существовал подписанный payload для N записей. Позднейшее предъявление k сталкивается с фактом, сохранённым в другой custody.

Протокольная корректность не гарантирует независимость. Собственная TSA может выпускать правильные tokens и всё же находиться под теми же правами доступа, политикой хранения и стимулами, что action log. Нужно назвать authority, ключ, правила проверки времени, место хранения и границу отказа.

SCITT фиксирует регистрацию, а не всё сразу

Проект также рассматривает регистрацию в SCITT Transparency Service. Его receipt подтверждает регистрацию Signed Statement по политике сервиса и хранится рядом с Vaara receipt, а не как элемент timestampAnchors.

RFC 3161 связывает digest со временем. SCITT связывает statement с регистрацией. runningCount обнаруживает внутренний пробел. Seal задаёт конечный total. RFC 9162 показывает похожее разделение inclusion и consistency: слово «прозрачность» не отменяет необходимости назвать конкретное доказательство.

Пересчитываемость сохраняет утверждение

JCS из RFC 8785 задаёт детерминированные JSON-байты. Публичные vectors и проверяющие программы без кода эмитента позволяют заново вычислить подписи, evidence binding, back link и случаи contiguity. Это полезное свидетельство running code.

Совпавший hash не делает содержание истинным или исчерпывающим. Валидная подпись показывает, какой ключ подписал bytes, но не его текущую пригодность. Сам draft не задаёт revocation и freshness, поэтому deployment обязан определить разрешение ключей и допустимую давность.

Decision receipt также не равен исполнению. Execution receipt может связаться с ним через backLink, подписать executed или refused и commitment результата. Связь препятствует подмене пары, но изменение внешней системы всё равно должен наблюдать отдельный источник.

Слои реальности Lu Heng запрещают сжатие этих этапов: канонические bytes не равны полной истории; история не равна закрытой boundary; seal не равна независимому свидетелю; свидетель не равен действию; действие не равно устойчивому результату. Minimum Initial Specification может стандартизировать тонкую оболочку, оставляя custody и будущие решения локальным владельцам.

Sources and limits

Источники подтверждают активный индивидуальный Internet-Draft и связанные открытые спецификации. Они не подтверждают консенсус IETF, RFC Vaara Receipt, принятие WG, независимый аудит, широкое внедрение, полную coverage, независимость TSA или наблюдаемый результат. Статья занимает только границу revision 12 между внутренним пробелом, tail seal и внешним anchor счётчика.