Summary

  • draft-nikolaichuk-scitt-continuity-receipts-01 proposes a signed Recovery Statement for a stateful asset and an RFC 9942 Receipt proving that the statement was registered in a specific Transparency Service and log position.
  • A SCRAPI service may first return HTTP 202 with an entry identifier. The draft says that identifier is not a Receipt; releasing the artifact then leaves the recovery unwitnessed until the Receipt resolves.
  • Even a valid Receipt proves registration of an issuer's assertion, not that recovery occurred, attestation succeeded, recovered bytes match the original, or operational behaviour is equivalent.

The release gate has two clocks

Imagine a recovery job completing at 02:14. The sealed material has been opened inside an attested environment. The database, model or application image has been reconstructed. Its digest has been calculated. A consuming system is ready to take it.

At 02:15 the Transparency Service returns HTTP 202 and an entry identifier. The operator can now see that the registration request was accepted. There is still no Receipt.

That minute is the real subject of Continuity Receipts: Registering the Recovery of a Stateful Asset as a Signed Statement in a Transparency Service, revision 01, posted on 29 September 2026. The document is an individual Informational Internet-Draft, not a Working Group adoption or an RFC. Its most useful contribution is not another green status. It is a prohibition against treating two unlike clocks as one.

The recovery clock says the bytes exist. The witness clock says an issuer-signed statement about those bytes has entered a named append-only log. If the asset is released while the second clock is still pending, the system has chosen availability over witnessed continuity. That may sometimes be necessary. It must not be disguised as completion.

Seven steps, seven owners of fact

The proposed flow starts with an attester in the recovery environment producing Evidence. A Verifier appraises it and emits Attestation Results. A key-release mechanism then releases sealed key material. The environment decrypts the material, reconstructs the artifact and calculates recovered-digest over the plaintext actually produced.

A Recovery Authority observes that bounded event, builds the continuity claims and signs them as an RFC 9943 Signed Statement. A Transparency Service applies its Registration Policy and appends the statement. A Relying Party later verifies the Receipt, the issuer, the claims, the attestation references and its own acceptance policy.

This is a chain of responsibility, not one act performed by a universal verifier. The key-release system can decide that material may be disclosed to an environment without proving what the environment later constructed. The Recovery Authority can sign what it says it observed without becoming independent of the recovery process. The Transparency Service can prove that the signed assertion was registered without auditing its truth. The consumer still owns the decision to use the output.

This separation follows Lu Heng's reality-layer discipline. A symbolic record is valuable when its authority is bounded. It becomes dangerous when registration is allowed to stand in for observation, or observation for outcome.

What the Receipt witnesses—and what it cannot

The draft states the boundary unusually early. A Continuity Receipt proves that a specific Recovery Statement, signed by a specific Issuer, was registered in a specific Transparency Service at a specific position in its append-only log, with a service-signed proof.

It does not prove that the Recovery Event occurred. It does not prove that the recovered bytes match the original artifact. It does not establish that referenced Attestation Results were verified or favourable. It does not establish that the environment occupied the state described. It does not show that Registration Policy checked any of those propositions.

That is not a defect in the Receipt. A witness that honestly says what it witnessed is stronger than a service that quietly adopts an audit role it cannot perform. Registration makes the assertion permanent, attributable, ordered and difficult to retract without detection. Those are substantial properties. They are simply not truth by themselves.

The interface consequence is severe: “registered” cannot be the only visible state. A conforming verifier must keep issuer assertions separate from independently established facts. A product that reduces both to one boolean restores the ambiguity the draft is trying to remove.

The asynchronous acceptance is the dangerous seam

The current SCITT Reference API draft permits a service to accept a Signed Statement and respond with HTTP 202 plus an entry identifier, while the Receipt is resolved later through the entry resource. Revision 01 therefore requires an explicit operating choice: block until the Receipt exists, or proceed without it.

The entry identifier is useful. It can support polling, reconciliation and later attachment of the Receipt. But it is evidence of an accepted workflow, not evidence of inclusion. The draft's memorable line is exact in its logic: a stored entry identifier with no Receipt beside it is a promise, not a proof.

A high-availability recovery design may still proceed. A hospital, exchange or control system may value restored service more than immediate registration during a Transparency Service outage. The honest state is then “released, unwitnessed,” with a named exception authority, expiry, consumer scope and reconciliation deadline. The unsafe design says nothing, shows green and allows the absence of a Receipt to disappear into the success path.

Measure the output, not the hope

The most important payload field is recovered-digest. It must be calculated over the plaintext bytes that actually exist at the end of recovery. It must not be copied from an expected digest in backup metadata. The expected value can be a comparison input; it cannot masquerade as a measurement.

The same refusal to normalize reality applies to environment measurements. Native algorithm and native length matter. The draft uses an adjacent implementation's treatment of AWS Nitro PCR0 and AMD SEV-SNP launch measurements as a warning: both are 48-octet SHA-384 values, while that code truncates them to 32 octets. The loss is not cosmetic. It breaks exact comparison with a policy surface that uses the full value.

This is Running-Code Primacy at the byte boundary. A field named “measurement” carries authority only if it was measured from the deployed object in the representation the policy actually evaluates.

Attestation has availability and freshness costs

Attestation Results can be referenced, embedded or separately registered. Referencing keeps the Recovery Statement compact but makes verification depend on later retrieval of the exact bytes. Embedding improves self-containment while potentially publishing hardware, region and workload information. Registering the Results separately gives them their own Receipt and log position, but adds another object and service dependency.

Freshness is also an explicit fact, not an adjective. The draft permits nonce, epoch identifier, timestamp or none. With none, the issuer discloses that the underlying Evidence was not challenge-bound and is replayable. A populated attestation field can therefore be authentic yet stale, or available yet unfavourable. A dashboard that displays it as “attested” has discarded the decision-bearing part.

Fidelity has three states, not one comforting word

The optional equivalence claim can be byte-identical, operational or none. Byte identity requires equality between the measured recovered digest and the plaintext digest recorded at sealing time, checked by the issuer. Operational equivalence means the artifact passed a defined test—a load, start or health probe—and must reference the definition and result. The draft calls that a weak claim.

Absence means none. There is deliberately no code point for semantic or behavioural equivalence. A database that starts may have lost records. A model that loads may answer differently. An application that passes a health probe may still violate the state its users depend on.

This is the second release gate. A Receipt can arrive while equivalence remains none. Registration and fidelity are orthogonal.

Two kinds of order must not be merged

prev-event links can form a Continuity Chain for successive recoveries of one subject. That link records the issuer's asserted lineage: when statement N was signed, the issuer regarded N-1 as the preceding recovery.

The append-only log establishes something else—global registration order. A gap between the two can mean the issuer did not know about an intervening recovery or chose not to acknowledge it. The verifier must report the gap rather than repair it. Entry IDs and leaf indices help locate records; only the prior Statement digest makes the cryptographic link.

Across multiple Transparency Services, even that order stops composing cleanly. Each service can prove its own history, not a universal order among services. Over years, inclusion proofs also need consistency Receipts connecting newer tree heads to earlier ones. Membership in an isolated root is not evidence that yesterday's log was extended rather than replaced.

Privacy can remove the policy surface

Attaching recovery claims lets a Transparency Service inspect them for Registration Policy, but may expose stable asset subjects, recovery frequency, region, provider relationships and hardware identifiers. Detaching the payload protects those details from the log, yet prevents the service from applying claim-dependent policy and forces the Relying Party to obtain the payload elsewhere.

A pseudonymous subject can reduce public correlation. It also breaks cross-organisation joining, turns the issuer secret into a long-lived linkability key and splits the chain when that key rotates. There is no cost-free privacy switch. The choice determines who can verify continuity later.

The prototype is not the specification

Revision 01 records that its adjacent reference implementation does not implement the document. It emits no RFC 9942 COSE Receipts, uses different log-link structures, contains incomplete attestation verification and lacks nonce-bound Evidence. Its reconstruction component is a deterministic order-3 byte-level Markov chain behind a frozen interface, not proof of semantic restoration.

That candour is useful. The draft has a specified state; the code has an observed state; deployment evidence is absent. Calling the three “implemented” would turn a documentation relationship into an operational fact.

Sources and limits

These sources define proposed formats, existing receipt and attestation architecture, and an adjacent implementation account. They do not establish a deployed Continuity Receipt system, a successful or failed recovery, an attack, a design partner, interoperability, adoption or semantic fidelity. The release dossier below is operational analysis, not language already required by the draft.