Кратко

  • draft-nikolaichuk-scitt-continuity-receipts-01 предлагает подписанное заявление о восстановлении stateful-актива и RFC 9942 Receipt, доказывающий регистрацию этого заявления в конкретной позиции SCITT Transparency Service.
  • prev-event выражает признанную эмитентом родословную одного актива, а append-only log — глобальную очередность регистрации. Пробел или расхождение надо показывать, а не исправлять автоматически.
  • HTTP 202 с entry identifier ещё не является Receipt. И само Receipt не доказывает, что восстановление состоялось, аттестация была благоприятной или полученный актив эквивалентен исходному.

Две хронологии одного актива

В журнале Statement B зарегистрирована раньше Statement C. Но C ссылается полем prev-event не на B, а на A. Машина может соблазниться простой коррекцией: раз B находится между ними, надо вставить её в цепочку и получить непрерывную историю.

Именно этого делать нельзя. Порядок лога отвечает на вопрос, когда заявления появились в общей структуре. prev-event отвечает на другой вопрос: какое предыдущее восстановление эмитент признавал, когда подписывал текущее. Расхождение может означать незнание, конфликт представлений или сознательное непризнание. Оно само является фактом аудита.

Такую границу задаёт draft-nikolaichuk-scitt-continuity-receipts-01 от 29 сентября 2026 года. Это индивидуальный Internet-Draft с предполагаемым статусом Informational, не принятый документ рабочей группы SCITT и не RFC. Он описывает claims для Recovery Statement и использует существующие механизмы RFC 9943 и RFC 9942, а не создаёт новый лог или формат аттестации.

Событие, заявление и регистрация

Recovery Environment сначала выдаёт Evidence. Verifier оценивает её и формирует Attestation Results. Отдельный механизм разрешает выдачу запечатанного ключевого материала. Среда расшифровывает данные, восстанавливает актив и вычисляет recovered-digest по реально полученному plaintext.

Recovery Authority строит claims, подписывает Statement и называет стабильный идентификатор актива subject. Transparency Service применяет Registration Policy, добавляет Statement в append-only log и возвращает Receipt. Затем Relying Party проверяет Receipt, Issuer, claims, ссылки на аттестацию и собственную политику до того, как использовать актив.

Последовательность важна, потому что полномочия распределены. Система выдачи ключа не заверяет конечные байты. Recovery Authority делает утверждение, но не превращается в независимого аудитора. Transparency Service видит регистрацию, а не восстановление. Потребитель отвечает за эффект.

В терминах Lu Heng это разные слои реальности. Общий протокол полезен ровно до тех пор, пока не заставляет символический объект говорить за физическое действие, которого тот не наблюдал.

Узкое доказательство Receipt

Continuity Receipt подтверждает, что конкретная Recovery Statement, подписанная конкретным Issuer, зарегистрирована конкретным Transparency Service в конкретной позиции его append-only log, а сервис подписал доказательство этого факта.

Receipt не доказывает, что Recovery Event произошёл. Оно не сравнивает результат с исходным активом. Оно не утверждает, что Attestation Results проверены или благоприятны. Оно не подтверждает фактическое состояние среды и не означает, что Registration Policy проверила перечисленные свойства.

Свидетель регистрирует заявление, но не расследует его. Благодаря Receipt заявление становится постоянным, атрибутированным и упорядоченным, его сложнее тихо отозвать. Это сильная функция, если интерфейс не добавляет чужие выводы.

Verifier должен разнести по разным категориям asserted, independently established и unverifiable. Единое «verified» стирает объект доказательства.

HTTP 202 оставляет незасвидетельствованное окно

Текущий SCRAPI допускает асинхронную регистрацию. Сервис принимает Signed Statement и отвечает HTTP 202 с entry identifier, а Receipt становится доступно позднее через entry resource.

Identifier помогает опрашивать и сопоставлять. Он не доказывает inclusion. revision 01 требует явного решения: задержать выдачу актива до Receipt либо продолжить и сохранить состояние unwitnessed до разрешения Receipt. Приравнять 202 к Receipt нельзя.

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

Entry identifier без Receipt — обещание будущего доказательства, а не его замена.

Digest измеряет то, что получилось

recovered-digest вычисляется по plaintext-байтам, существующим в конце Recovery Event. Его нельзя копировать из ожидаемого значения в метаданных запечатанного материала. Ожидаемый digest нужен для сравнения; фактический описывает результат.

Измерение среды сохраняет native algorithm и native length. Проект отмечает, что соседняя реализация обрезает 48-октетные SHA-384 measurements AWS Nitro и AMD SEV-SNP до 32 октетов. Поле остаётся похожим на измерение, но перестаёт быть равным объекту, который использует политика платформы.

Running-Code Primacy означает сохранять фактические байты и решение работающей системы, а не восстанавливать желаемую картину по названию структуры.

Аттестация зависит от способа хранения

Attestation Results можно ссылать, встраивать или регистрировать отдельно. Reference уменьшает Statement и раскрытие, но требует долговременной доступности точных байтов. Embedded улучшает самодостаточность и может раскрыть платформу, регион и hardware identifiers. Registered даёт результату собственное Receipt и позицию, добавляя ещё один объект.

Freshness описывается nonce, epoch ID, timestamp или none. none означает, что Evidence не связана с challenge и допускает replay. Это честное свойство, но не подтверждение текущего состояния.

Подлинный Attestation Result может иметь неблагоприятный outcome. Наличие, подпись, свежесть и оценка — четыре разных факта.

Эквивалентность не следует из запуска

Если equivalence отсутствует, считается none. byte-identical требует равенства измеренного recovered digest и plaintext digest, записанного при sealing, причём Issuer должен проверить сравнение. operational сообщает только об успешном определённом тесте — загрузке, старте или health probe — и требует evidence reference.

Проект прямо называет operational слабым утверждением. База запускается с пропущенными записями. Модель загружается с иным поведением. Приложение отвечает на probe при нарушенных бизнес-инвариантах.

Кода для semantic или behavioral equivalence намеренно нет. Неопределённое понятие нельзя превращать в машинную гарантию после smoke test. Receipt может быть корректным при equivalence = none.

Цепочку нельзя чинить предположением

В Continuity Chain digest предыдущей Signed Statement имеет криптографический смысл. prev-entry-id и prev-leaf-index — лишь подсказки для поиска. Если найдено промежуточное событие, но текущий Issuer на него не сослался, Verifier должен показать gap.

При переходе между несколькими Transparency Services положение усложняется. Каждый сервис доказывает локальный порядок, но эти порядки не дают единой глобальной шкалы. Для долгоживущей проверки нужны и consistency Receipts между Merkle Tree Heads. Inclusion в изолированный root не показывает, что вчерашнее дерево продолжили, а не заменили.

Таким образом, целостность истории состоит минимум из трёх проверок: подписи событий, заявленной связи и непрерывности самого лога. Ни одна не восстанавливает другую.

Приватность может разорвать наблюдаемую историю

Attached payload позволяет Transparency Service применять политику к claims, но открывает stable subject, частоту восстановлений, регион, отношения с провайдером и иногда hardware identifiers. Detached payload скрывает содержание от лога, зато сервис не может проверять невидимые claims, а Relying Party получает зависимость от side channel.

Псевдонимный subject через HMAC ослабляет публичную корреляцию. Два custodian создадут разные subject и не соединят цепочки. Секрет Issuer становится долговременным ключом связи; его утрата делает историю неперечислимой, а ротация делит её.

Приватность определяет будущую проверяемость. Этот выбор нельзя отложить до запроса на удаление из append-only log.

Соседний код остаётся соседним

Документ сообщает, что reference implementation не реализует спецификацию. Он не выпускает RFC-9942 COSE Receipts, использует другие связи лога, не завершает проверку аттестации и не имеет nonce binding. Реконструкция — детерминированная Markov chain третьего порядка на уровне байтов, не подтверждение смысла.

Это не свидетельство производственного сбоя: production deployment не показан. Это честно зафиксированная граница между предложением, кодом и отсутствующими эксплуатационными результатами.

Источники и ограничения

Источники описывают рабочее предложение, опубликованные архитектуры и заявленные ограничения соседнего кода. Они не доказывают deployment, инцидент, атаку, реальное восстановление, совместимость, принятие или semantic fidelity. Приведённое ниже release dossier — операционный анализ Daniel Kade, а не уже стандартизованное требование.