Continuity Receipts: Registering the Recovery of a Stateful Asset as a Signed Statement in a Transparency Service
draft-nikolaichuk-scitt-continuity-receipts-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Serhii Nikolaichuk | ||
| Last updated | 2026-08-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
ORCID
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nikolaichuk-scitt-continuity-receipts-00
Supply Chain Integrity, Transparency, and Trust (SCITT) S. Nikolaichuk
Internet-Draft Independent
Intended status: Informational 28 August 2026
Expires: 1 March 2027
Continuity Receipts: Registering the Recovery of a Stateful Asset as a
Signed Statement in a Transparency Service
draft-nikolaichuk-scitt-continuity-receipts-00
Abstract
A Transparency Service as defined by RFC 9943 registers Signed
Statements about Artifacts and returns Receipts, encoded per RFC
9942, that prove registration in an append-only log. The Statements
registered today typically describe how an Artifact was built,
tested, or released. They do not describe what happens after that:
the Artifact is sealed, moved, lost, and later re-created somewhere
else, and that re-creation leaves no independently checkable trace.
This document defines a Continuity Receipt: the Receipt obtained when
a recovery event is registered as a Signed Statement in a
Transparency Service. It specifies the Subject and the required
claims of a recovery Statement, how Attestation Results from RFC 9334
remote attestation are carried or referenced by it, and how a
sequence of such Statements under one Subject forms a verifiable
continuity chain across the lifetime of a stateful asset.
The document is deliberately narrow. It defines a payload and a set
of claims, not a new Transparency Service, not a new verifiable data
structure, and not a new attestation format. It also records, rather
than conceals, the divergence between what it specifies and what the
reference implementation currently does.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-nikolaichuk-scitt-continuity-
receipts/.
Discussion of this document takes place on the Supply Chain
Integrity, Transparency, and Trust Working Group mailing list
(mailto:scitt@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/scitt/. Subscribe at
https://www.ietf.org/mailman/listinfo/scitt/.
Nikolaichuk Expires 1 March 2027 [Page 1]
Internet-Draft Continuity Receipts August 2026
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. What This Document Defines . . . . . . . . . . . . . . . 4
1.2. What This Document Does Not Define . . . . . . . . . . . 5
1.3. Relationship to draft-nikolaichuk-rats-tap . . . . . . . 5
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.5. Intellectual Property Notice . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Terms Imported from RFC 9943 . . . . . . . . . . . . . . 7
2.2. Terms Imported from RFC 9334 . . . . . . . . . . . . . . 7
2.3. Terms Defined by This Document . . . . . . . . . . . . . 7
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Placement . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Who Signs, and What That Means . . . . . . . . . . . . . 9
3.3. What a Continuity Receipt Proves . . . . . . . . . . . . 9
4. The Recovery Statement . . . . . . . . . . . . . . . . . . . 10
Nikolaichuk Expires 1 March 2027 [Page 2]
Internet-Draft Continuity Receipts August 2026
4.1. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Payload: continuity-claims . . . . . . . . . . . . . . . 12
4.4. Required Claims . . . . . . . . . . . . . . . . . . . . . 14
4.5. Environment Identity and Measurement Length . . . . . . . 15
4.6. Carrying Attestation Results . . . . . . . . . . . . . . 16
4.7. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 17
4.8. Equivalence: What Was Recovered . . . . . . . . . . . . . 18
5. Continuity Chains . . . . . . . . . . . . . . . . . . . . . . 19
6. The Continuity Receipt . . . . . . . . . . . . . . . . . . . 20
6.1. Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Verifiable Data Structure . . . . . . . . . . . . . . . . 20
6.3. Registration Before Release . . . . . . . . . . . . . . . 21
7. Registration Policy Considerations . . . . . . . . . . . . . 21
7.1. The Detachment Trade-off . . . . . . . . . . . . . . . . 22
7.2. On policy-id . . . . . . . . . . . . . . . . . . . . . . 23
8. Verification . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Divergence from the Reference Implementation . . . . . . . . 24
9.1. What Maps Cleanly: The Hashing . . . . . . . . . . . . . 25
9.2. What Does Not Map: PrevLeafHash . . . . . . . . . . . . . 25
9.3. What Does Not Map: TreeChainHead . . . . . . . . . . . . 26
9.4. Summary of the Migration . . . . . . . . . . . . . . . . 26
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 27
10.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 27
10.2. Hardware Corpus . . . . . . . . . . . . . . . . . . . . 27
10.3. What Has Not Been Demonstrated . . . . . . . . . . . . . 28
10.4. Prior Art the Author Concedes . . . . . . . . . . . . . 29
11. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11.1. What the Receipt Is and Is Not . . . . . . . . . . . . . 30
11.2. Compromise of the Recovery Authority . . . . . . . . . . 30
11.3. Replay and the Missing Nonce . . . . . . . . . . . . . . 30
11.4. Truncated Measurements . . . . . . . . . . . . . . . . . 31
11.5. Debug-Mode Environments . . . . . . . . . . . . . . . . 31
11.6. Split View and Unwitnessed Logs . . . . . . . . . . . . 32
11.7. Availability . . . . . . . . . . . . . . . . . . . . . . 32
11.8. Error Handling . . . . . . . . . . . . . . . . . . . . . 32
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33
12.1. The Fact of Recovery . . . . . . . . . . . . . . . . . . 33
12.2. The Subject as a Permanent Correlator . . . . . . . . . 33
12.3. The Issuer Is Identified by Design . . . . . . . . . . . 34
12.4. Hardware Linkability . . . . . . . . . . . . . . . . . . 34
12.5. Region and Jurisdiction . . . . . . . . . . . . . . . . 35
12.6. Structural Leakage . . . . . . . . . . . . . . . . . . . 35
12.7. Erasure and the Append-only Log . . . . . . . . . . . . 36
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
13.1. Media Type Registration . . . . . . . . . . . . . . . . 36
13.2. Registrations Deliberately Not Requested . . . . . . . . 37
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
Nikolaichuk Expires 1 March 2027 [Page 3]
Internet-Draft Continuity Receipts August 2026
14.1. Normative References . . . . . . . . . . . . . . . . . . 37
14.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Worked Example (Informative) . . . . . . . . . . . . 41
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 42
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction
Supply chain transparency work has concentrated on the forward path
of an Artifact: what source it was built from, what dependencies it
absorbed, who signed it, and what policy admitted it. [RFC9943]
gives that path a durable shape: an Issuer emits a Signed Statement
about a Subject, a Transparency Service applies a Registration Policy
and appends it to an Append-only Log, and the resulting Receipt
[RFC9942] lets any Relying Party check that the Statement was
registered without trusting the Issuer's word about it.
Stateful assets have a second path that is not covered. A trained
model, a database, an index, or a key hierarchy is sealed, written to
storage that its owner does not control, and later re-created --
after a region failure, a provider migration, a hardware refresh, an
acquisition, or the wind-down of the company that produced it. The
re-creation is the moment at which the asset's identity is most in
question and least documented. In practice it produces a support
ticket and, if the operator is careful, a line in a private log.
The question an auditor eventually asks is not "was this built
correctly" but:
* Was this asset re-created, or is it a different asset wearing the
same name?
* From which sealed material, and did that material come from the
environment that claims to have produced it?
* Under whose authority, and under which policy?
* Inside what, and can that be checked by someone who was not there?
Each of those is a statement about an Artifact made by an
identifiable party. That is precisely the object [RFC9943] defines.
This document specifies what such a Statement contains.
1.1. What This Document Defines
1. A recovery event payload, in CDDL [RFC8610], carried as the
payload of a Signed Statement.
Nikolaichuk Expires 1 March 2027 [Page 4]
Internet-Draft Continuity Receipts August 2026
2. The choice of Subject, and the consequences of that choice for
continuity chaining and for privacy.
3. Three carriage modes for RATS [RFC9334] Attestation Results in a
recovery Statement, and the rules governing each.
4. The binding of the resulting Receipt as a COSE Receipt [RFC9942]
with vds = 1 (RFC9162_SHA256).
5. Registration Policy considerations for a Transparency Service
that accepts recovery Statements.
6. An honest account of where the reference implementation diverges
from all of the above (Section 9, Section 10).
1.2. What This Document Does Not Define
* A Transparency Service. Any service conforming to [RFC9943] and
reachable via [I-D.ietf-scitt-scrapi] is in scope as a registrar.
* A new verifiable data structure. Section 6.2 explains why one is
not needed and why requesting one would be a mistake.
* An Evidence format, an Attestation Results format, or an appraisal
policy. Those belong to the RATS architecture [RFC9334] and its
working group.
* The key-release decision that precedes a recovery. That is the
subject of [TAP] and is deliberately not restated here; see
Section 1.3.
* Any claim about whether a recovered asset is semantically or
behaviorally equivalent to the original. See Section 4.8, which
treats the temptation to make such a claim as the principal hazard
of this document.
1.3. Relationship to draft-nikolaichuk-rats-tap
[TAP] specifies the decision: what a Relying Party must consider
before releasing sealed key material to an attested environment, and
what record that decision leaves behind. This document specifies the
aftermath: the recovery that the release enabled, registered in a
Transparency Service so that a third party can check it.
The split is intentional and the two documents are usable separately.
Nikolaichuk Expires 1 March 2027 [Page 5]
Internet-Draft Continuity Receipts August 2026
+================+============================+==================+
| Concern | draft-nikolaichuk-rats-tap | This document |
+================+============================+==================+
| Before or | Authorization, at the time | Record, after |
| after the fact | | the fact |
+----------------+----------------------------+------------------+
| Governing | RATS [RFC9334] | SCITT [RFC9943] |
| architecture | | |
+----------------+----------------------------+------------------+
| Central object | Release Record | Signed Statement |
| | | + Receipt |
+----------------+----------------------------+------------------+
| Who signs | The Sealer | The Recovery |
| | | Authority |
+----------------+----------------------------+------------------+
| Who witnesses | An append-only log, | A Transparency |
| | unspecified | Service |
+----------------+----------------------------+------------------+
| Attestation | Consumed to decide | Referenced as |
| | | evidence for the |
| | | record |
+----------------+----------------------------+------------------+
Table 1: Division of labour between TAP and this document
A deployment MAY use both. Where it does, the TAP Release Record is
one of the inputs referenced by the recovery Statement defined here
(Section 4.3), and the two form a chain: attestation appraised, key
material released, asset recovered, recovery registered. A
deployment MAY equally use this document with any other key-release
mechanism, including the attestation-gated key release facilities
that cloud providers already offer (Section 10.4).
This document does not depend on [TAP] normatively. [TAP] is
referenced informatively throughout, and every field this document
borrows from it is restated here in full so that an implementer needs
only one specification.
1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Nikolaichuk Expires 1 March 2027 [Page 6]
Internet-Draft Continuity Receipts August 2026
1.5. Intellectual Property Notice
The author holds United States provisional patent applications
64/036,136, 64/036,137 and 64/036,139, whose subject matter overlaps
this document. An IPR disclosure has been or will be filed with the
IETF in accordance with BCP 78 and BCP 79 at or before the time this
document is submitted. This notice is informational; the operative
record is the disclosure on the IETF Datatracker, and the boilerplate
in "Status of This Memo" governs.
2. Terminology
2.1. Terms Imported from RFC 9943
This document uses the following terms exactly as defined in
[RFC9943] and does not redefine, narrow, or extend any of them:
Transparency Service, Signed Statement, Transparent Statement,
Receipt, Registration, Registration Policy, Append-only Log,
Statement, Statement Sequence, Issuer, Subject, Artifact, Relying
Party, Verifiable Data Structure.
Where this document writes "Artifact", the [RFC9943] meaning is
intended: a physical or non-physical item moving along a supply
chain. The stateful asset being recovered is an Artifact in that
sense.
2.2. Terms Imported from RFC 9334
This document uses Attester, Verifier, Relying Party, Evidence,
Attestation Results, Attesting Environment and Target Environment
exactly as defined in [RFC9334].
Note that "Relying Party" is defined in both [RFC9943] and [RFC9334]
with compatible but not identical scope. Where the distinction
matters this document writes "SCITT Relying Party" or "RATS Relying
Party".
2.3. Terms Defined by This Document
Recovery Event: The act of re-creating a stateful Artifact from
sealed material inside an environment other than, or later than,
the one that sealed it. A Recovery Event is bounded: it begins
when key material is released and ends when the recovered bytes
exist and have been digested.
Recovery Authority: The entity that observes a Recovery Event and
Nikolaichuk Expires 1 March 2027 [Page 7]
Internet-Draft Continuity Receipts August 2026
issues a Signed Statement about it. The Recovery Authority is the
Issuer in the sense of [RFC9943] and is identified by the iss
claim of the CWT_Claims protected header parameter [RFC9597].
Recovery Statement: A Signed Statement whose payload is a
continuity-claims structure (Section 4.3) and whose Subject is the
Artifact that was recovered.
Continuity Receipt: The Receipt [RFC9942] returned by a Transparency
Service upon Registration of a Recovery Statement. A Continuity
Receipt is an ordinary Receipt; the term names its provenance, not
a new format.
Continuity Chain: The ordered sequence of Recovery Statements
registered under a single Subject, linked by the prev-event field
of Section 4.3. A Continuity Chain is an application-level
construct and is not the same thing as the Transparency Service's
Append-only Log; see Section 5.
Sealed Material: The ciphertext form of an Artifact together with
whatever metadata is needed to locate and order its parts. Sealed
Material is assumed to reside on storage that neither the Issuer
nor the Transparency Service controls.
Recovery Environment: The environment inside which the Recovery
Event takes place. It is an Attester in the sense of [RFC9334].
Producing Environment: The environment inside which the Artifact was
originally sealed. It is an Attester in the sense of [RFC9334].
It is frequently no longer reachable at recovery time, which is
why its identity must be carried rather than queried.
3. Architecture
3.1. Placement
The Recovery Authority is an Issuer. Nothing else about the SCITT
architecture changes. The following sequence shows where a Recovery
Event sits; steps 1 to 3 are outside the scope of this document.
Nikolaichuk Expires 1 March 2027 [Page 8]
Internet-Draft Continuity Receipts August 2026
1. Attester (Recovery Environment) produces Evidence
2. Verifier appraises Evidence, emits Attestation Results
3. Key release mechanism releases sealed key material
(TAP Sealer, AWS KMS condition key, Azure SKR, KBS, ...)
4. Recovery Environment decrypts Sealed Material, reassembles
the Artifact, computes recovered-digest
5. Recovery Authority builds continuity-claims, signs it as a
Signed Statement, sub = Artifact identifier
6. Transparency Service applies Registration Policy, appends to
the Append-only Log, returns a Receipt
7. Recovery Authority attaches the Receipt to the Signed
Statement (unprotected header label 394), producing a
Transparent Statement
8. Any Relying Party verifies the Receipt offline against the
Transparency Service public key
Steps 5 through 8 are what this document specifies.
3.2. Who Signs, and What That Means
The Recovery Authority signs. It is not the Recovery Environment,
and this distinction is load-bearing.
The Recovery Environment can attest to its own measurement; it cannot
credibly attest that it is the environment a particular custodian
authorized to hold a particular asset. The Recovery Authority is the
party with that context: it holds the relationship to the asset
owner, it knows which policy applied, and it can be held to the
statement afterward. It is typically the same entity that operates
or commissions the key release in step 3.
Collocating the Recovery Authority inside the Recovery Environment is
permitted and is often desirable, because it shortens the gap between
the recovered bytes and the signature over their digest. It does not
merge the roles: an implementation that collocates them MUST still be
able to state, in the attestation field, which appraisal it relied
on, because a signature produced inside an environment is not by
itself evidence about that environment.
3.3. What a Continuity Receipt Proves
This is stated early and normatively because every subsequent section
depends on it, and because the most likely misuse of this document is
to read a Receipt as more than it is.
Nikolaichuk Expires 1 March 2027 [Page 9]
Internet-Draft Continuity Receipts August 2026
A Continuity Receipt proves exactly one thing: 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, and that the Transparency Service signed a proof of that
fact.
A Continuity Receipt does NOT prove:
* that the Recovery Event occurred;
* that the recovered bytes match the original Artifact;
* that the Attestation Results referenced by the Statement were
themselves verified, or that they were favourable;
* that the Recovery Environment was in the state the Statement
describes;
* that the Registration Policy of the Transparency Service checked
any of the above.
The Transparency Service witnesses an assertion. It does not audit
it. An implementation MUST NOT present a Continuity Receipt in any
interface in a manner that implies otherwise, and a verifier MUST
report the Issuer's assertions and the independently established
facts as two separate categories (Section 8).
The value of the Receipt is not that it makes the assertion true. It
is that the assertion becomes permanent, attributable, ordered, and
impossible to retract quietly. That is a smaller property than it
first appears, and it is still worth having, because the current
alternative is a private log the custodian can edit.
4. The Recovery Statement
4.1. Envelope
A Recovery Statement is a Signed Statement per [RFC9943]: a tagged
COSE_Sign1 [RFC9052], signed with an algorithm from [RFC9053].
Nikolaichuk Expires 1 March 2027 [Page 10]
Internet-Draft Continuity Receipts August 2026
Recovery_Statement = #6.18(COSE_Sign1)
Recovery_Protected_Header = {
&(alg: 1) => int,
&(content_type: 3) => tstr / uint,
&(CWT_Claims: 15) => Recovery_CWT_Claims,
? &(kid: 4) => bstr,
? &(x5t: 34) => COSE_CertHash,
? &(x5chain: 33) => COSE_X509,
* label => any,
}
Recovery_CWT_Claims = {
&(iss: 1) => tstr,
&(sub: 2) => tstr,
? &(iat: 6) => int,
* label => any,
}
The CWT_Claims header parameter (label 15) is defined in [RFC9597];
the claims inside it are CWT claims [RFC8392].
An Issuer:
* MUST include CWT_Claims with both iss and sub, as required by
[RFC9943];
* MUST set content_type to application/continuity-recovery+cbor
(Section 13) when the payload is attached;
* SHOULD set iat to the time of signing, which is distinct from
recovered-at in the payload and MAY differ from it;
* MUST NOT rely on the Transparency Service to supply, correct, or
default any of the above.
4.2. Subject
The Subject is the Artifact that was recovered, not the Recovery
Event.
This is the single most consequential design choice in this document,
so the reasoning is given rather than asserted.
If the Subject were the event, each recovery would be an isolated
statement about a distinct thing, and the sequence of recoveries of
one asset could only be reconstructed by an entity that already knew
all the event identifiers. Making the Subject the asset means every
Nikolaichuk Expires 1 March 2027 [Page 11]
Internet-Draft Continuity Receipts August 2026
recovery of that asset lands under one identifier, in log order, and
a Relying Party who knows only the asset identifier can enumerate its
entire recovery history from the Transparency Service. That
enumeration is the property this document exists to provide.
Accordingly:
* sub MUST be stable across every recovery of the same Artifact. An
Issuer MUST NOT derive sub from anything that changes per event --
not the timestamp, not the Recovery Environment, not the storage
location.
* sub MUST NOT be reused for a different Artifact. An Issuer that
cannot guarantee this within its own namespace MUST qualify sub
with a namespace it controls.
* sub MUST NOT be the digest of the Artifact contents. Contents
change across the asset's life; a content digest as Subject
silently splits one continuity chain into many.
The stability that makes the chain work also makes sub a permanent
correlator in a log that cannot forget. Section 12.2 treats this at
length and specifies a pseudonymous construction for deployments that
need one.
4.3. Payload: continuity-claims
continuity-claims = {
version: 1,
event-id: bstr .size (8..64),
recovered-digest: digest,
sealed-material: sealed-material-ref,
policy-id: tstr,
recovery-environment: environment-identity,
attestation: attestation-ref,
freshness: freshness-proof,
outcome: outcome,
recovered-at: timestamp,
? producing-environment: environment-identity,
? prev-event: prev-event-link,
? equivalence: equivalence-claim,
? release-record: digest,
? custodian: tstr,
* tstr => any,
}
; A digest as an algorithm identifier from the COSE Algorithms
; registry together with the digest value, at its native length.
Nikolaichuk Expires 1 March 2027 [Page 12]
Internet-Draft Continuity Receipts August 2026
digest = [ alg: int, value: bstr ]
timestamp = ~time
sealed-material-ref = {
sealed-digest: digest,
? chunk-count: uint,
? provenance-ref: digest,
? locator: tstr,
}
environment-identity = {
tee-family: tstr,
measurement: digest,
debug-mode: bool,
? svn: uint,
? platform-id: bstr,
? region: tstr,
}
attestation-ref = {
mode: attestation-mode,
? ar-digest: digest,
? ar-format: tstr,
? ar-embedded: bstr,
? ar-statement: digest,
? verifier-id: tstr,
? ar-issued-at: timestamp,
}
attestation-mode = &(
referenced: 1
embedded: 2
registered: 3
)
freshness-proof = {
method: freshness-method,
? nonce-digest: digest,
? epoch-id: bstr,
? evidence-time: timestamp,
}
freshness-method = &(
nonce: 1
epoch-id: 2
timestamp: 3
none: 4
Nikolaichuk Expires 1 March 2027 [Page 13]
Internet-Draft Continuity Receipts August 2026
)
outcome = &(
recovered: 1
recovered-degraded: 2
failed: 3
)
prev-event-link = {
prev-statement: digest,
? prev-entry-id: tstr,
? prev-leaf-index: uint,
}
equivalence-claim = {
kind: equivalence-kind,
? evidence-ref: digest,
}
equivalence-kind = &(
byte-identical: 1
operational: 2
none: 3
)
4.4. Required Claims
The CDDL above marks nine fields as required. Each is required for a
reason, and the reasons are not interchangeable.
version: Fixed at 1 for this specification. Present so that a
Relying Party can reject rather than misparse.
event-id: An identifier unique within the Issuer's namespace. It
exists so that a Recovery Event can be discussed, correlated with
operational records, and linked by a subsequent prev-event without
dereferencing a log position. It MUST NOT be derived from sub.
recovered-digest: The digest of the recovered Artifact as it existed
at the end of the Recovery Event, computed over the plaintext.
This is the anchor of the whole statement. An Issuer MUST compute
it over the bytes actually produced, and MUST NOT copy it from the
Sealed Material's metadata. Copying an expected digest forward
and presenting it as an observed one converts the Statement from a
measurement into a wish.
sealed-material: What the Artifact was recovered from. sealed-digest
Nikolaichuk Expires 1 March 2027 [Page 14]
Internet-Draft Continuity Receipts August 2026
is computed over the ciphertext as stored, so a Relying Party
holding the Sealed Material can check it without holding any key.
provenance-ref, where present, is the digest of a provenance
record binding the Sealed Material to its Producing Environment;
when [TAP] is in use this is the digest of the TAP Provenance
Record.
policy-id: The identifier of the policy under which the recovery was
authorized. This document does not define a policy language and
takes no position on one; see Section 7.2.
recovery-environment: The attested identity of the environment in
which the recovery occurred.
attestation: How the RATS Attestation Results underlying the
recovery are carried or referenced (Section 4.6).
freshness: How the timeliness of the Evidence underlying those
Attestation Results was established (Section 4.7). The
enumeration includes none because an Issuer that cannot establish
freshness MUST say so rather than omit the field. A missing field
is indistinguishable from an oversight; an explicit none is a
disclosure.
outcome: recovered, recovered-degraded, or failed. An Issuer SHOULD
register failed recovery attempts. A continuity chain containing
only successes cannot distinguish an asset that has never been at
risk from one that was nearly lost three times, and the second is
the case a Relying Party most needs to see.
recovered-at: When the Recovery Event completed, per the Issuer's
clock. This is an Issuer assertion. The Receipt's position in
the Append-only Log, not this field, is what establishes ordering
that a Relying Party can check.
4.5. Environment Identity and Measurement Length
measurement carries the TEE's own measurement of the Target
Environment: PCR0 for AWS Nitro Enclaves [AWS-NITRO], MRENCLAVE for
Intel SGX, the launch MEASUREMENT for AMD SEV-SNP.
An Issuer MUST carry the measurement at its native length and under
its native algorithm identifier. An Issuer MUST NOT truncate, re-
hash, pad, or otherwise normalize it.
This requirement exists because the reference implementation gets it
wrong, and the failure is instructive. Both the AWS Nitro PCR0 and
the AMD SEV-SNP launch MEASUREMENT are 48 octets (SHA-384). The
Nikolaichuk Expires 1 March 2027 [Page 15]
Internet-Draft Continuity Receipts August 2026
reference implementation's adapters truncate both to a 32-octet
field. The consequence is not merely lost entropy: it breaks byte-
equality against AWS's own policy engine, which compares the full
48-octet value in the kms:RecipientAttestation:ImageSha384 condition
key [AWS-KMS-COND]. A measurement that cannot be compared against
the vendor's own reference is not an identity, and a digest structure
that carries an algorithm identifier alongside the value has no
excuse for discarding half of it. This is a known defect and is
recorded in Section 10.
debug-mode MUST be populated truthfully. A debug-mode environment
produces measurements that do not identify code -- an all-zero PCR0
is the absence of a measurement wearing the shape of one -- and a
Statement that conceals this is worse than no Statement, because it
is durable. A Recovery Statement asserting a debug-mode environment
is legitimate and SHOULD be registered; it is a permanent,
attributable record that a recovery happened under reduced assurance,
which is exactly the kind of thing an append-only log is for.
platform-id is OPTIONAL and SHOULD be omitted. See Section 12.4.
region is OPTIONAL and carries a deployment-scoped region label. See
Section 12.5 before populating it; in some regulatory settings a
public Receipt disclosing a cross-border recovery is itself the
disclosure that a deployment was trying to avoid making.
4.6. Carrying Attestation Results
Attestation Results are the reason a Recovery Statement is worth more
than a log line. They are also large, sometimes confidential, and
governed by a different architecture. This document defines three
carriage modes and requires the Issuer to declare which one it used.
Mode 1, referenced (RECOMMENDED default): ar-digest MUST be present
and carries the digest of the Attestation Results as they were
appraised. ar-format SHOULD be present and carries the media type;
for Entity Attestation Tokens the media types of [RFC9782] apply,
and a Conceptual Message Wrapper [RFC9999] MAY be used to carry a
family-agnostic wrapper. The Attestation Results themselves are
not in the log. A deployment using this mode MUST arrange for
them to be retrievable by digest for as long as the Receipt is
expected to be meaningful, and SHOULD state that retention period
somewhere a Relying Party can find it. A digest pointing at bytes
nobody kept is a reference to nothing.
Mode 2, embedded: ar-embedded MUST be present and carries the
Nikolaichuk Expires 1 March 2027 [Page 16]
Internet-Draft Continuity Receipts August 2026
Attestation Results verbatim. This makes the Recovery Statement
self-contained and offline-verifiable, at the cost of committing
the Attestation Results permanently to the log with everything
they disclose. An Issuer MUST NOT use this mode without having
assessed the Attestation Results for hardware identifiers, tenancy
information, and anything else enumerated in Section 12. ar-format
MUST be present in this mode.
Mode 3, registered: The Attestation Results were themselves
registered as a separate Signed Statement in a Transparency
Service, and ar-statement carries the digest of that Signed
Statement. This mode is the most useful of the three when it is
available, because the attestation acquires its own Receipt and
its own position in the log, and the Recovery Statement then
references a fact that is already witnessed rather than one it
asserts. It requires an ecosystem in which Verifiers register
their outputs, which does not yet broadly exist.
In all three modes:
* verifier-id SHOULD be present and identify the Verifier that
produced the Attestation Results. An Issuer that appraised
Evidence itself MUST still produce Attestation Results as a
distinct object and reference them; a self-appraisal that leaves
no referenceable artifact is not distinguishable from no
appraisal.
* An Issuer MUST NOT populate attestation with a reference to
Evidence. Evidence and Attestation Results are different
conceptual messages in [RFC9334] and conflating them in a
permanent record misstates who did the appraising.
* This document takes no position on the content of the Attestation
Results. [I-D.ietf-rats-ar4si] and [I-D.ietf-rats-ear] define
trustworthiness vocabularies that a future revision might profile;
see Appendix B.
4.7. Freshness
[RFC9334] Section 10 describes three ways to establish that Evidence
is timely: synchronized clocks, nonces, and epoch IDs. freshness-
proof records which was used.
Where method is nonce:
* the challenge MUST be at least 16 octets from a cryptographically
secure random source [RFC4086];
Nikolaichuk Expires 1 March 2027 [Page 17]
Internet-Draft Continuity Receipts August 2026
* the challenge MUST have been supplied by the Verifier or by the
party requesting the appraisal, and MUST NOT have been chosen by
the Recovery Environment;
* nonce-digest MUST carry the digest of the challenge rather than
the challenge itself, so that a challenge derived from a secret
does not enter the log.
Where method is none, the Issuer is asserting that the Evidence
underlying the recovery was not bound to any challenge and is
therefore replayable. This is a disclosure, not a failure of the
format, and Section 11.3 explains why the field exists at all: every
attestation artifact in the corpus underlying this document has this
property.
4.8. Equivalence: What Was Recovered
equivalence is OPTIONAL, and when absent MUST be interpreted as kind
= none.
byte-identical: The recovered plaintext is byte-for-byte identical
to the plaintext that was sealed. An Issuer MUST NOT assert this
unless recovered-digest equals the plaintext digest recorded at
sealing time and the Issuer has verified that equality itself.
This is a mechanical, checkable claim.
operational: The recovered Artifact passed a defined operational
check -- it loads, it starts, it answers a health probe. evidence-
ref MUST be present and reference the definition and result of
that check. This is a weak claim and SHOULD be labelled as such
wherever it is displayed.
none: No equivalence claim is made.
No value is defined for semantic or behavioral equivalence, and this
is deliberate. Those are the claims a reader most wants to make and
the ones this document is least entitled to enable. The reference
implementation documents semantic and behavioral validation
dimensions and implements neither; only the operational dimension is
implemented. Defining a code point for an unimplemented, undefined
notion of "means the same thing" would invite implementations to emit
it on the strength of a passing smoke test.
An implementation MUST NOT present a Continuity Receipt as evidence
of fidelity. The reference implementation makes the hazard concrete:
its reconstruction backend is a deterministic byte-level Markov chain
of order 3 behind a frozen interface. It performs no inference and
is not a neural network. It produces perfectly valid Recovery
Nikolaichuk Expires 1 March 2027 [Page 18]
Internet-Draft Continuity Receipts August 2026
Statements, and a Transparency Service will register them without
complaint, because the Transparency Service is not in the business of
checking whether the recovered thing is any good.
5. Continuity Chains
Successive Recovery Statements under one Subject form a Continuity
Chain when each carries prev-event referencing the digest of its
predecessor Signed Statement.
The chain and the Append-only Log carry different information and
neither replaces the other.
The Append-only Log establishes global order: this Statement was
registered before that one, and the Transparency Service cannot later
claim otherwise without producing an inconsistent tree. It does not
establish that the Issuer believed the two were related.
The chain establishes the Issuer's asserted lineage: at the time of
writing statement N, the Issuer's view of the asset's most recent
prior recovery was statement N-1. A gap in the chain -- a prev-event
that references a Statement which is not the log-immediate
predecessor under that Subject -- is meaningful. It means the Issuer
either did not know about an intervening recovery, or chose not to
acknowledge it. A verifier MUST report such a gap rather than
repairing it.
Accordingly:
* An Issuer SHOULD include prev-event on every Recovery Statement
after the first for a given Subject.
* An Issuer MUST NOT fabricate prev-event to close a gap it is aware
of.
* A verifier MUST check the chain and the log order independently
and MUST report disagreement between them (Section 8).
* prev-entry-id and prev-leaf-index, where present, are conveniences
for locating the predecessor and MUST NOT be treated as proof of
it. Only prev-statement is cryptographically meaningful.
A Continuity Chain spanning more than one Transparency Service is
possible and is not prohibited. Nothing binds prev-statement to a
particular service. A verifier encountering a chain whose links
resolve in different services MUST report that fact, because the
ordering guarantee is only as strong as the weakest service in the
set and the guarantee does not compose across them.
Nikolaichuk Expires 1 March 2027 [Page 19]
Internet-Draft Continuity Receipts August 2026
6. The Continuity Receipt
6.1. Binding
Upon Registration, the Transparency Service returns a Receipt per
[RFC9942]. A Receipt is a tagged COSE_Sign1 and MUST be tagged as
such. The Issuer attaches it to the Recovery Statement in the
unprotected header under the receipts parameter (label 394),
producing a Transparent Statement per [RFC9943].
Transparent_Recovery_Statement = #6.18(COSE_Sign1)
Recovery_Unprotected_Header = {
&(receipts: 394) => [ + bstr .cbor Receipt ],
? &(x5chain: 33) => COSE_X509,
* label => any,
}
More than one Receipt MAY be present. A deployment that registers
the same Recovery Statement in more than one Transparency Service
SHOULD attach all resulting Receipts, and a verifier SHOULD report
how many were checked and which services issued them.
6.2. Verifiable Data Structure
A Transparency Service registering Recovery Statements SHOULD use the
RFC9162_SHA256 verifiable data structure, registered in the COSE
Verifiable Data Structure Algorithms registry with value 1 by
[RFC9942].
The Receipt for an inclusion proof then has vds (label 395) with
value 1 in its protected header alongside alg, and vdp (label 396) in
its unprotected header carrying an inclusion proof under label -1.
The inclusion proof content is, per [RFC9942]:
inclusion-proof-content = [
tree-size: uint
leaf-index: uint
inclusion-path: [ + bstr ]
]
The payload of an inclusion Receipt is the Merkle Tree Head at tree-
size, and SHOULD be detached.
A Transparency Service SHOULD also be able to produce consistency
Receipts, which carry a consistency proof under label -2 in vdp and
whose payload is the newer Merkle Tree Head. Continuity Chains span
long periods -- that is their purpose -- and a Relying Party checking
Nikolaichuk Expires 1 March 2027 [Page 20]
Internet-Draft Continuity Receipts August 2026
a chain years after the fact needs consistency proofs to establish
that the tree it is checking against is an extension of the tree the
earlier Receipts were issued from, not a replacement for it. An
inclusion proof against a root nobody can connect to any earlier root
proves membership in a log that might have been rebuilt yesterday.
This document does NOT request a new verifiable data structure. A
recovery event is an ordinary Statement; nothing about it requires a
different tree. The bar for a new VDS is a genuinely different
structure with different proof semantics, which is what
[I-D.ietf-scitt-receipts-ccf-profile] clears and what this document
does not. Requesting one to accommodate an implementation detail
would fragment the registry for no verifier's benefit. Section 9
works through the implementation detail in question and concludes
that it should be dropped, not registered.
6.3. Registration Before Release
A Recovery Authority SHOULD obtain the Receipt before the recovered
Artifact is released to any consumer.
The ordering matters for the same reason it matters in [TAP]: a
system that releases first and registers afterward can lose the
record of precisely the events an attacker cares about, because the
attacker's leverage is the window between the two.
[I-D.ietf-scitt-scrapi] allows a Transparency Service to accept a
Signed Statement and return 202 with an entry identifier rather than
a Receipt, resolving it later via the entry resource. An Issuer
using an asynchronous service MUST choose explicitly between blocking
on the Receipt and proceeding without it, MUST NOT treat a 202 as
equivalent to a Receipt, and where it proceeds MUST record the
recovery as unwitnessed until the Receipt is resolved. A stored
entry identifier with no Receipt beside it is a promise, not a proof.
7. Registration Policy Considerations
[RFC9943] defines Registration Policy as the precondition a
Transparency Service enforces before Registration, based on
information in the non-opaque header and metadata in the COSE
Envelope. The policy language is out of scope for this document, as
it is for [RFC9943].
A Transparency Service accepting Recovery Statements SHOULD verify:
* that the Issuer is authorized to make statements about this
Subject, which is the check that gives the Subject namespace
meaning;
Nikolaichuk Expires 1 March 2027 [Page 21]
Internet-Draft Continuity Receipts August 2026
* that content_type is application/continuity-recovery+cbor where
the payload is attached;
* that version is a value the service understands.
A Transparency Service SHOULD NOT attempt to verify that the recovery
occurred, or that the referenced Attestation Results were favourable.
That would require the service to become a RATS Relying Party for
every tenant's hardware, which does not scale, is not what [RFC9943]
asks of it, and would quietly convert a witness into an auditor whose
failures are invisible.
7.1. The Detachment Trade-off
[RFC9943] allows a Statement to be made over the hash of a payload
rather than the payload bytes, and detached payloads are a natural
mitigation for the privacy exposures in Section 12.
There is a direct cost, and it is easy to miss. Registration Policy
operates on the header and envelope metadata. A Transparency Service
cannot apply a policy over a payload it does not have. A deployment
that detaches the continuity-claims payload for privacy reasons
therefore gives up any Registration Policy that depends on the claims
-- which is most of the checks a policy author would want to write.
The two configurations are both legitimate and they answer different
questions:
+====================+==================+==================+
| | Attached payload | Detached payload |
+====================+==================+==================+
| Registration | Possible | Not possible |
| Policy over claims | | |
+--------------------+------------------+------------------+
| Log discloses | Yes | No |
| recovery detail | | |
+--------------------+------------------+------------------+
| Relying Party | No | Yes, for the |
| needs side channel | | payload |
+--------------------+------------------+------------------+
| Suitable for | Rarely | Often |
| public log | | |
+--------------------+------------------+------------------+
Table 2: Consequences of detaching the continuity-claims
payload
Nikolaichuk Expires 1 March 2027 [Page 22]
Internet-Draft Continuity Receipts August 2026
An Issuer MUST decide this per deployment and SHOULD document the
choice, because a Relying Party that receives a detached Recovery
Statement and cannot obtain the payload has a Receipt for a Statement
whose contents it cannot read.
7.2. On policy-id
policy-id is a tstr and this document assigns it no structure. It
identifies the policy under which the recovery was authorized -- the
policy applied by the key release mechanism in step 3 of Section 3.1,
not the Registration Policy of the Transparency Service.
Naming a policy is not defining one. This document records which
policy an Issuer says it applied, so that a Relying Party who can
obtain that policy can check the Statement against it. Deployments
SHOULD use identifiers that are resolvable within their trust domain
and SHOULD version them, because "the policy" changes and a Receipt
is permanent.
8. Verification
A verifier presented with a Transparent Recovery Statement MUST be
able to operate offline, given the Transparency Service public key
and, where applicable, the Sealed Material.
A verifier MUST:
1. Verify the Signed Statement signature and resolve the Issuer
identified by iss.
2. Verify each attached Receipt: check the Transparency Service
signature, check vds, and recompute the inclusion path against
the payload root.
3. Where consistency Receipts are available, verify that the roots
involved form a consistent sequence.
4. Parse continuity-claims and check version.
5. Where the Sealed Material is available, verify sealed-digest
against it.
6. Where the recovered Artifact is available, verify recovered-
digest against it.
7. Where a Continuity Chain is present, resolve prev-event and check
chain order against log order, reporting any disagreement
(Section 5).
Nikolaichuk Expires 1 March 2027 [Page 23]
Internet-Draft Continuity Receipts August 2026
8. Report debug-mode prominently wherever it is true.
A verifier MUST report its findings in three separate categories and
MUST NOT merge them:
Asserted: What the Issuer claims. recovered-at, policy-id, outcome,
the environment identities, and every field the verifier could not
independently check.
Established: What the verifier checked cryptographically. Signature
validity, Receipt validity, log position, and any digest it
recomputed against bytes it holds.
Unverifiable: What could not be checked with the material at hand,
itemized. A referenced Attestation Results digest whose bytes are
unavailable belongs here, as does a prev-event whose predecessor
could not be resolved.
A verifier that returns a single boolean is not conformant with this
document. The distinction between "the Issuer said so" and "I
checked" is the entire content of Section 3.3, and a verifier that
collapses it has converted a transparency mechanism into an assurance
it was never entitled to give.
9. Divergence from the Reference Implementation
The reference implementation described in Section 10 does not
implement this document. It implements something adjacent, and the
differences are recorded here in full because the working group is
better served by knowing where a proposal is running ahead of its
code.
The implementation commits release records to an [RFC6962] Merkle
tree with a Signed Tree Head, plus two additions: a PrevLeafHash
field embedded in every leaf, forming a linear hash chain in
insertion order alongside the tree, and a TreeChainHead, a running
hash over successive Signed Tree Heads so that each head commits to
its predecessor. It emits no COSE Receipts at all.
The divergence is therefore total at the encoding layer and close to
zero at the hashing layer. The following works through each part.
Nikolaichuk Expires 1 March 2027 [Page 24]
Internet-Draft Continuity Receipts August 2026
9.1. What Maps Cleanly: The Hashing
[RFC9162] Section 2.1.1 defines the Merkle Tree Hash as MTH({d[0]}) =
HASH(0x00 || d[0]) for a single-entry list and MTH(D_n) =
HASH(0x01 || MTH(D[0:k]) || MTH(D[k:n])) for the general case, with
the prefix bytes providing domain separation for second-preimage
resistance. [RFC6962] defines it identically; [RFC9162] revises and
obsoletes [RFC6962] without changing this construction.
The consequence is concrete and favourable: an existing [RFC6962]
SHA-256 tree already _is_ an RFC9162_SHA256 verifiable data
structure. vds = 1 applies unchanged. Existing audit paths are
already valid inclusion-path values. Moving to [RFC9942] Receipts
requires re-encoding proofs and signing them as COSE_Sign1, not
recomputing any hash and not rebuilding any tree. No stored leaf
changes.
The Signed Tree Head is largely subsumed: [RFC9942] places the Merkle
Tree Head in the Receipt payload and the Transparency Service's
signature over the Receipt plays the role the STH signature played.
The one element of an [RFC6962] STH with no destination is its
timestamp, inclusion-proof-content being exactly [tree-size, leaf-
index, inclusion-path]. A deployment that needs it SHOULD carry it
as an iat claim in the Receipt's protected header rather than
inventing a place for it.
9.2. What Does Not Map: PrevLeafHash
inclusion-proof-content is a three-element array. It has no fourth
slot and adding one would break the CDDL and the registry entry.
PrevLeafHash cannot be carried in an RFC9162_SHA256 Receipt.
It also should not be. Examined rather than preserved, PrevLeafHash
turns out to be largely redundant. The Merkle tree already provides
tamper-evidence for every leaf, leaf-index already provides insertion
order, and consistency proofs (label -2) already establish that the
log has only ever been appended to. What a per-leaf back-pointer
adds over those three is a chain that must be walked leaf-by-leaf to
verify -- linear where the Merkle proof is logarithmic -- and whose
links join leaves that have nothing to do with each other, since
consecutive entries in a shared log belong to unrelated Subjects.
The useful part of the idea survives in a better place. A chain over
_related_ events is exactly what Section 5 defines: prev-event links
successive recoveries of one Artifact, at the application layer,
inside the signed payload where the Issuer's assertion belongs. The
recommendation is therefore to drop PrevLeafHash from the log and
adopt prev-event in the Statement.
Nikolaichuk Expires 1 March 2027 [Page 25]
Internet-Draft Continuity Receipts August 2026
9.3. What Does Not Map: TreeChainHead
[RFC9942] requires the payload of an inclusion Receipt to be the
Merkle Tree Head at tree-size. A TreeChainHead is a running hash
over successive heads; it is not a Merkle Tree Head and cannot be
substituted for one without violating the semantics of vds = 1.
There is no header parameter for it.
Its purpose is real: it detects an operator who rewinds the log and
re-signs a divergent history. But that is what consistency proofs
are for, and [RFC9942] defines them under label -2. A consistency
proof between two tree sizes is a logarithmic, third-party-checkable
statement that the later tree extends the earlier one; a chain over
heads is a linear one that requires possessing every intervening
head. The recommendation is to drop TreeChainHead and implement
consistency Receipts, which the implementation currently does not
emit.
9.4. Summary of the Migration
+========================+===================================+
| Implementation element | Disposition under this document |
+========================+===================================+
| RFC 6962 SHA-256 tree | Keep; it is already vds = 1 |
+------------------------+-----------------------------------+
| Leaf and node hashing | Keep unchanged |
+------------------------+-----------------------------------+
| Audit paths | Keep; re-encode as inclusion-path |
+------------------------+-----------------------------------+
| Signed Tree Head | Replace with Receipt; carry |
| | timestamp as iat |
+------------------------+-----------------------------------+
| PrevLeafHash | Drop; superseded by prev-event |
+------------------------+-----------------------------------+
| TreeChainHead | Drop; superseded by consistency |
| | Receipts (-2) |
+------------------------+-----------------------------------+
| (absent) COSE Receipts | Add |
+------------------------+-----------------------------------+
| (absent) consistency | Add |
| proofs | |
+------------------------+-----------------------------------+
Table 3: Reference implementation elements mapped onto RFC
9942
The author has not yet performed this migration and does not wish to
present a plan as a result. Section 10 states what exists today.
Nikolaichuk Expires 1 March 2027 [Page 26]
Internet-Draft Continuity Receipts August 2026
10. Implementation Status
This section records implementation status per [RFC7942] and is to be
removed by the RFC Editor before publication. It describes one
implementation by the author of this document. The absence of an
independent implementation is itself information the working group
should weigh.
10.1. Overview
Implementation: Vault Genome core, written in Go. A Python SDK, a
command-line client, and Terraform modules for AWS, Azure and GCP
exist.
Level of maturity: Prototype. There is no production deployment, no
design partner, and no end user. Zero.
Coverage of this document: None. The implementation logs release
records to an [RFC6962] tree as described in Section 9. It does
not produce Signed Statements, does not interact with any
Transparency Service, and does not produce or consume COSE
Receipts. The continuity-claims structure in Section 4.3 is
specified here first and implemented nowhere.
Licensing: Apache-2.0 relicensing is in progress. The repository is
not public at the time of writing.
Contact: The author.
10.2. Hardware Corpus
An artifact corpus was captured while running one seal-and-restore
workload across three TEE families [VG-CORPUS]. The counts below are
produced by a script from the artifact bytes and are reproduced
verbatim; they are also reported in [TAP], which the reader may
already have.
Nikolaichuk Expires 1 March 2027 [Page 27]
Internet-Draft Continuity Receipts August 2026
+===========+=======+======================+===================+
| Family | Files | Distinct file hashes | Distinct hardware |
| | | | identities |
+===========+=======+======================+===================+
| AWS Nitro | 12 | 8 | 8 |
| Enclaves | | | |
+-----------+-------+----------------------+-------------------+
| AMD SEV- | 10 | 8 | 4 |
| SNP | | | |
+-----------+-------+----------------------+-------------------+
| Azure SGX | 4 | 4 | 1 |
| / MAA | | | |
+-----------+-------+----------------------+-------------------+
| *Total* | *26* | *20* | *13* |
+-----------+-------+----------------------+-------------------+
Table 4: Attestation artifact corpus composition
Of the twelve AWS Nitro documents, eight are production-mode with a
non-zero PCR0 and four are debug-mode with all-zero PCRs. The AMD
SEV-SNP files resolve to seven distinct CHIP_IDs; the file count is
not the chip count. The four Azure artifacts share a single
MRENCLAVE.
Regions exercised: AWS us-east-2 and eu-west-1; GCP us-central1,
europe-west1 and europe-west4; Azure eastus2 and westeurope. A byte-
identical restore of a Llama 3.2 3B artifact was demonstrated between
Ohio and Ireland.
A cross-cloud run delivered three DEKs from AWS us-east-1 to GCP us-
central1 following an attestation handshake, producing an audit chain
of length three. The coordination result contains no timing field;
no cross-cloud latency figure exists for that run and none is stated
here.
10.3. What Has Not Been Demonstrated
Each item below is a real gap and is listed because omitting it would
misrepresent the implementation.
Attestation verification is not wired. The in-repository attestation
verifiers are fail-closed stubs of approximately 2,189 lines that
return "not yet wired". The hardware signed real attestation
documents and those documents are in the corpus; the daemon does
not verify them against vendor libraries. Closing this is
scheduled work targeting 2026-10-31. Until it is closed, an
attestation field emitted by this implementation would reference
material the implementation itself has never verified.
Nikolaichuk Expires 1 March 2027 [Page 28]
Internet-Draft Continuity Receipts August 2026
No Azure artifact is offline-verifiable. All four publish the
decoded claims payload rather than the compact signed JWT and
cannot be re-verified against Microsoft's keys. All four also
carry is-debuggable: true. They evidence plumbing, not proof.
Measurements are truncated. Both Nitro PCR0 and SEV-SNP MEASUREMENT
are 48 octets; the adapters truncate to a 32-octet field, breaking
byte-equality with the AWS ImageSha384 policy engine
[AWS-KMS-COND]. Section 4.5 forbids this. The implementation
does it.
No corpus artifact carries a verifier-supplied nonce. See
Section 11.3.
In-process TEE binding is simulated. One binding uses real AES-
256-GCM with a simulated hardware root. It is suitable for
testing only.
The reconstruction backend performs no inference. It is a
deterministic byte-level Markov chain of order 3 behind a frozen
interface. It is a placeholder and not a neural network. See
Section 4.8.
Only one validation dimension is implemented. Operational validation
is implemented. Semantic and behavioral validation are documented
and unimplemented.
A prior novelty claim was retracted. An earlier version of the
project's documentation asserted that no comparable work existed.
That claim was withdrawn. It is noted here because a reader
evaluating this document is entitled to know that the author has
previously overstated and corrected, and because Section 10.4
exists as a consequence.
10.4. Prior Art the Author Concedes
Attestation-gated release of key material is deployed technology and
this document neither claims it nor depends on being first to it. At
least the following predate this work and should be understood as the
baseline against which any contribution here is measured:
* AWS Key Management Service condition keys for Nitro Enclaves,
notably kms:RecipientAttestation:ImageSha384, which gate
decryption on an enclave measurement [AWS-KMS-COND].
* Azure Key Vault Secure Key Release, which gates key export on an
Azure Attestation token [AZURE-SKR].
Nikolaichuk Expires 1 March 2027 [Page 29]
Internet-Draft Continuity Receipts August 2026
* The Confidential Containers Trustee Key Broker Service, which
gates secret delivery on attestation [COCO-KBS].
What this document adds to that baseline is narrow: the recovery
event as a registered Signed Statement with a defined payload, the
continuity chain over one Subject, and the requirement that a
verifier separate assertion from established fact. None of the three
requires a new key-release mechanism, and a deployment using any of
the above can adopt this document without changing it.
11. Security Considerations
11.1. What the Receipt Is and Is Not
Section 3.3 is normative and is the security model. A Continuity
Receipt is a witness to an assertion. The Transparency Service does
not verify the recovery, the attestation, or the bytes. Every
security property below is conditioned on that.
11.2. Compromise of the Recovery Authority
A compromised Recovery Authority key can register well-formed
Recovery Statements for recoveries that never happened, or omit ones
that did. The Transparency Service will accept them if its
Registration Policy admits the Issuer, and the Receipts will be
permanent.
Revoking the key afterward does not un-register anything. An append-
only log has no mechanism for retraction, and this is a property, not
a defect: it means the compromise is discoverable. Deployments
SHOULD register key rotation and revocation events as Signed
Statements in the same Transparency Service so that a Relying Party
checking an old Receipt can determine whether the key was still valid
at registration time. This document does not define such statements.
The Recovery Authority's signing key SHOULD be confined to an
environment at least as protected as the environments whose
recoveries it attests. A key that is less protected than the asset
makes the record weaker than the thing it records.
11.3. Replay and the Missing Nonce
Evidence not bound to a verifier-supplied challenge can be replayed.
An attacker who captures Evidence from a legitimately attested
environment and later presents it from an environment it controls
obtains whatever the Evidence unlocks. Measurement equality does not
prevent this: the measurement is a property of the code, and the
attacker is replaying somebody else's proof that the code ran, not
Nikolaichuk Expires 1 March 2027 [Page 30]
Internet-Draft Continuity Receipts August 2026
proving it is running now, for them.
This is stated plainly because the corpus supporting this document
has the flaw:
*No artifact in the corpus described in Section 10 carries a
verifier-supplied challenge nonce.* All twelve AWS Nitro attestation
documents have an empty nonce field; they are bound to their workload
but they are replayable. The AMD SEV-SNP reports carry non-zero
REPORT_DATA, but in those runs REPORT_DATA was chosen by the
producing side and is therefore a producer assertion rather than a
challenge. The Azure artifacts are decoded claim payloads with no
recoverable challenge binding.
The consequence for this document is specific. A Recovery Statement
whose freshness.method is none, or whose nonce-digest is absent,
records a recovery whose underlying attestation could have been
replayed. The Receipt makes that recovery permanent and
attributable; it does not make it fresh. A verifier MUST surface
freshness.method = none in the Asserted category and MUST NOT treat
the Receipt as compensating for it.
The none code point exists so that this disclosure is expressible.
An implementation MUST NOT omit freshness in order to avoid making
it.
11.4. Truncated Measurements
Section 4.5 forbids truncation. The security consequence of
violating it is worse than lost entropy. A verifier comparing a
truncated 32-octet value against a vendor's 48-octet reference will
fail every comparison and may be "fixed" by truncating the reference
too -- at which point the comparison passes while checking half a
measurement, and any second preimage over the retained prefix is
accepted. The failure mode is a verifier that appears to work.
An implementation MUST treat a measurement whose length does not
match the length its algorithm identifier implies as a distinct
rejection condition with its own error, not as a mismatch.
11.5. Debug-Mode Environments
An all-zero PCR0 is not a measurement. A verifier that parses an
attestation document, finds a well-formed PCR0 field, and compares it
against a value that was also configured as all zeros during
development will accept it.
Nikolaichuk Expires 1 March 2027 [Page 31]
Internet-Draft Continuity Receipts August 2026
An implementation MUST treat an all-zero measurement as a distinct
rejection condition, MUST report debug-mode as true wherever the
record indicates it, and MUST NOT report such a record as
establishing environment identity. Four of the twenty-six corpus
artifacts are debug-mode; they are retained and labelled rather than
removed, because a corpus that quietly drops its own negative cases
is less useful than one that keeps them.
11.6. Split View and Unwitnessed Logs
A Transparency Service operated by a single party is append-only by
that party's word. Two Relying Parties can be shown different trees
and neither will detect the divergence from inclusion proofs alone.
Deployments SHOULD obtain consistency Receipts over time and SHOULD
have them checked by independent parties. A verifier SHOULD report
whether the roots it checked against were corroborated by any party
other than the service that issued them. Where a Continuity Chain
spans multiple services, Section 5 applies: ordering guarantees do
not compose across them.
11.7. Availability
A Recovery Authority that blocks on Registration before releasing a
recovered Artifact can be denied by denying it the Transparency
Service. This is the correct trade in most settings -- an
unwitnessed recovery is the situation this document exists to
eliminate -- but it means the Transparency Service is on the critical
path of disaster recovery, which is the worst possible time for it to
be unavailable.
Deployments SHOULD register in more than one Transparency Service,
SHOULD decide in advance whether an unwitnessed recovery is permitted
under emergency conditions, and MUST NOT implement that decision as a
silent fallback. Where an emergency recovery proceeds unwitnessed,
the Recovery Statement MUST be registered retroactively with
recovered-at reflecting the actual event, and the gap between
recovered-at and the log position will be visible to every Relying
Party. That visibility is the point.
11.8. Error Handling
Errors returned to a party requesting a recovery MUST NOT distinguish
failure causes in a way that permits probing the release policy.
Detailed causes belong in the Recovery Statement and in operator-
facing logs.
Nikolaichuk Expires 1 March 2027 [Page 32]
Internet-Draft Continuity Receipts August 2026
Implementations SHOULD distinguish internally between structural
failures and integrity failures, and SHOULD treat integrity failures
as potential attacks rather than routine errors.
12. Privacy Considerations
Recovery is a disclosure. Everything in this section follows from
that.
A Signed Statement about a build says something happened that the
builder intended to happen. A Signed Statement about a recovery says
something happened that the custodian did not want to happen: an
asset was lost, moved under duress, or migrated away from an
environment that no longer worked. Registering it in an append-only
log makes that permanent and, in a public log, makes it public.
12.1. The Fact of Recovery
The most sensitive thing in a Continuity Receipt is often not any
field. It is the Receipt's existence.
A sequence of Continuity Receipts under one Subject is an incident
timeline. Their cadence is readable: a cluster of recoveries in one
week is an outage, a migration, or a breach response, and which of
the three it is can frequently be inferred from the outcome values
and the environment identities. Read across an Issuer's whole set of
Subjects, the log becomes an operational reliability record that the
Issuer never agreed to publish. Competitors, counterparties,
insurers and adversaries can all read it, and unlike an outage the
record does not fade.
outcome = failed is the sharpest case. A public record of failed
recovery attempts against a named asset tells an adversary which
asset to attack and that the custodian is currently having trouble
with it. Section 4.3 nonetheless says an Issuer SHOULD register
failures, because a chain of successes only is a chain that lies by
omission. The resolution is not to suppress failures but to choose
the audience: deployments whose failure record is sensitive SHOULD
use a private or consortium Transparency Service rather than a public
one, and SHOULD NOT resolve the tension by filtering what they
register.
12.2. The Subject as a Permanent Correlator
Section 4.2 requires sub to be stable across the asset's life.
Stability is what makes the chain enumerable, and it is also what
makes sub a permanent correlator in a structure with no delete
operation.
Nikolaichuk Expires 1 March 2027 [Page 33]
Internet-Draft Continuity Receipts August 2026
Where the plain asset identifier is sensitive, an Issuer SHOULD
derive a pseudonymous Subject:
sub = base64url( HMAC-SHA-256( K_iss, asset-identifier ) )
where K_iss is a secret held by the Issuer and never registered.
This preserves chain enumerability for anyone holding K_iss and the
identifier, and destroys it for everyone else.
The costs are real and MUST be weighed rather than assumed away:
* Cross-organization verification breaks. Two custodians of the
same asset produce different Subjects and their chains cannot be
joined. If joining them was the purpose, pseudonymity defeats it.
* K_iss becomes a long-lived secret whose compromise retroactively
deanonymizes every Receipt ever issued under it, and whose loss
makes the Issuer's own chains unenumerable.
* Rotating K_iss splits the chain. An Issuer that rotates MUST
publish or privately convey the linkage, or accept the split.
An Issuer MUST NOT use a low-entropy or guessable input to the HMAC.
Asset names are frequently guessable, and an HMAC over a guessable
input under a compromised or brute-forceable key is not a pseudonym.
12.3. The Issuer Is Identified by Design
iss names the custodian and cannot be pseudonymized without
destroying the point: a Receipt whose Issuer is unknown witnesses an
assertion by nobody.
Where the Recovery Authority is a service provider acting for a
client, iss discloses that the client relationship exists, and a
chain under a given Subject discloses its duration. Providers SHOULD
consider whether a per-client Issuer identity, or client-operated
signing, is more appropriate than a single provider identity across
all clients.
12.4. Hardware Linkability
TEE attestation exposes stable hardware identifiers. The corpus in
Section 10 shows the scale: 26 artifacts resolve to 13 distinct
hardware identities, via AMD-SP CHIP_ID for SEV-SNP and Nitro
Security Module identifiers for AWS Nitro Enclaves. These are stable
across workloads and across tenants of the same physical part.
Nikolaichuk Expires 1 March 2027 [Page 34]
Internet-Draft Continuity Receipts August 2026
Committed to an append-only log, they reveal which physical machines
an asset has been recovered on and when, and correlating them across
Issuers reveals co-tenancy between organizations that have no
relationship with each other.
Accordingly:
* platform-id is OPTIONAL and SHOULD be omitted.
* Where machine-level accountability is genuinely required,
platform-id SHOULD carry a salted per-deployment pseudonym rather
than the raw identifier, with the mapping retained by the Issuer.
* An Issuer using attestation mode embedded MUST inspect the
embedded Attestation Results for these identifiers before
registering, because embedding publishes whatever the Verifier
chose to include and the Issuer does not control that choice.
12.5. Region and Jurisdiction
region, and often measurement and verifier-id indirectly, disclose
where a recovery took place.
Under data-localization regimes, a public Receipt showing an asset
recovered in a different jurisdiction from where it was sealed is a
public admission of cross-border transfer. The implementation in
Section 10 demonstrated exactly this shape: a byte-identical restore
from Ohio to Ireland. That transfer may be entirely lawful and it
may also be something the custodian is obliged to declare through a
different channel first.
Deployments SHOULD omit region where it is not needed, and SHOULD
treat the decision to register a cross-jurisdiction recovery in a
public log as a disclosure decision rather than a logging decision.
12.6. Structural Leakage
chunk-count is a proxy for asset size and SHOULD be omitted unless a
Relying Party needs it. locator frequently reveals a storage
provider, a bucket naming convention, and an internal organizational
structure; it SHOULD be omitted from any Statement destined for a log
the Issuer does not control.
event-id MUST NOT encode anything the Issuer would not publish.
Sequential event identifiers disclose recovery volume; identifiers
derived from ticket numbers disclose more.
Nikolaichuk Expires 1 March 2027 [Page 35]
Internet-Draft Continuity Receipts August 2026
12.7. Erasure and the Append-only Log
An append-only log cannot forget, and this conflicts directly with
erasure obligations where any registered field constitutes personal
data.
Deployments SHOULD assume that anything registered is registered
permanently. The available mitigations are to detach the payload
(Section 7.1), to register only digests of sensitive fields, or to
use a Transparency Service whose access is controlled. Where salted
digests are used, destroying the salt is the only available
approximation of erasure, and it destroys the verifiability of every
Receipt derived under that salt. That is a real trade and MUST be
made deliberately, before the first Registration rather than after
the first request.
13. IANA Considerations
13.1. Media Type Registration
IANA is requested to register the following media type in the "Media
Types" registry, per the procedures of RFC 6838.
Type name: application
Subtype name: continuity-recovery+cbor
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary (CBOR [RFC8949])
Security considerations: See the Security Considerations section of
this document.
Interoperability considerations: N/A
Published specification: This document.
Applications that use this media type: Transparency Services and
Relying Parties processing Signed Statements about recovery
events.
Fragment identifier considerations: N/A
Person and email address to contact for further information: See the
Author's Address section.
Nikolaichuk Expires 1 March 2027 [Page 36]
Internet-Draft Continuity Receipts August 2026
Intended usage: COMMON
Restrictions on usage: none
Author: See the Author's Address section.
Change controller: IETF
13.2. Registrations Deliberately Not Requested
The following are recorded so that a reviewer does not have to infer
intent from silence.
No COSE Verifiable Data Structure Algorithm is requested. A recovery
event is an ordinary Statement registered in an ordinary log.
RFC9162_SHA256 (value 1, [RFC9942]) is sufficient and appropriate.
See Section 6.2 and Section 9.
No COSE Verifiable Data Structure Proof type is requested. Inclusion
(-1) and consistency (-2) cover what this document needs.
No COSE header parameter is requested. Everything this document adds
lives in the Statement payload, where an Issuer's assertions
belong.
No CBOR tag is requested at this revision. The continuity-claims
structure is not stable enough to warrant one. A future revision
may request one if the working group finds the structure worth
registering, and may equally conclude that it should be expressed
as a profile of an existing format such as [RFC9711] rather than
as a new type. See Appendix B.
No CoAP Content-Format is requested at this revision. There is no
constrained-node use case for this document yet. One may emerge;
it has not.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Nikolaichuk Expires 1 March 2027 [Page 37]
Internet-Draft Continuity Receipts August 2026
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9597] Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in
COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024,
<https://www.rfc-editor.org/rfc/rfc9597>.
Nikolaichuk Expires 1 March 2027 [Page 38]
Internet-Draft Continuity Receipts August 2026
[RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C.
Fournet, "CBOR Object Signing and Encryption (COSE)
Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026,
<https://www.rfc-editor.org/rfc/rfc9942>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
14.2. Informative References
[AWS-KMS-COND]
Amazon Web Services, "AWS Key Management Service condition
keys for AWS Nitro Enclaves
(kms:RecipientAttestation:ImageSha384)", 2026,
<https://docs.aws.amazon.com/enclaves/latest/user/
kms.html>.
[AWS-NITRO]
Amazon Web Services, "AWS Nitro Enclaves attestation
document specification", 2026,
<https://docs.aws.amazon.com/enclaves/latest/user/verify-
root.html>.
[AZURE-SKR]
Microsoft Corporation, "Azure Key Vault Secure Key
Release", 2026, <https://learn.microsoft.com/en-us/azure/
confidential-computing/concept-skr-attestation>.
[COCO-KBS] Confidential Containers project, "Confidential Containers
Trustee: Key Broker Service", 2026,
<https://github.com/confidential-containers/trustee>.
[I-D.ietf-rats-ar4si]
Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
Scarlata, "Attestation Results for Secure Interactions",
Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
10, 18 May 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-ar4si-10>.
[I-D.ietf-rats-corim]
Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
W. Pan, "Concise Reference Integrity Manifest", Work in
Progress, Internet-Draft, draft-ietf-rats-corim-11, 6 July
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
rats-corim-11>.
Nikolaichuk Expires 1 March 2027 [Page 39]
Internet-Draft Continuity Receipts August 2026
[I-D.ietf-rats-ear]
Fossati, T., Voit, E., Trofimov, S., and H. Birkholz, "EAT
Attestation Results", Work in Progress, Internet-Draft,
draft-ietf-rats-ear-04, 26 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
ear-04>.
[I-D.ietf-scitt-receipts-ccf-profile]
Birkholz, H., Delignat-Lavaud, A., Fournet, C., and A.
Chamayou, "CCF Profile for COSE Receipts", Work in
Progress, Internet-Draft, draft-ietf-scitt-receipts-ccf-
profile-04, 24 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-scitt-
receipts-ccf-profile-04>.
[I-D.ietf-scitt-scrapi]
Birkholz, H., Geater, J., and A. Delignat-Lavaud, "Supply
Chain Integrity, Transparency, and Trust (SCITT) Reference
APIs", Work in Progress, Internet-Draft, draft-ietf-scitt-
scrapi-11, 26 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-scitt-
scrapi-11>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/rfc/rfc6962>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/rfc/rfc9711>.
[RFC9782] Lundblade, L., Birkholz, H., and T. Fossati, "Entity
Attestation Token (EAT) Media Types", RFC 9782,
DOI 10.17487/RFC9782, May 2025,
<https://www.rfc-editor.org/rfc/rfc9782>.
[RFC9999] Birkholz, H., Smith, N., Fossati, T., and H. Tschofenig,
"Remote ATtestation procedureS (RATS) Conceptual Message
Wrapper (CMW)", RFC 9999, DOI 10.17487/RFC9999, July 2026,
<https://www.rfc-editor.org/rfc/rfc9999>.
Nikolaichuk Expires 1 March 2027 [Page 40]
Internet-Draft Continuity Receipts August 2026
[TAP] Nikolaichuk, S., "Trusted Artifact Provenance (TAP): A
Producer, Verifier, and Sealer Contract for Attestation-
Gated Reconstruction of Stateful Assets", Work in
Progress, Internet-Draft, draft-nikolaichuk-rats-tap-00,
2026, <https://datatracker.ietf.org/doc/draft-nikolaichuk-
rats-tap/>.
[VG-CORPUS]
Nikolaichuk, S., "Cross-TEE Attestation Corpus (docs/
CORPUS.md and evidence/MANIFEST.json)", Machine-generated
manifest of hardware-signed attestation artifacts. Not yet
publicly available; see Section 9., 2026.
Appendix A. Worked Example (Informative)
A model is sealed in AWS us-east-2 and, eleven months later,
recovered in GCP us-central1 after the original account is closed.
The Recovery Authority constructs a Signed Statement with:
* iss naming the Recovery Authority;
* sub set to the stable asset identifier, or to its HMAC pseudonym
per Section 12.2;
* content_type = application/continuity-recovery+cbor.
The payload carries, in outline:
Nikolaichuk Expires 1 March 2027 [Page 41]
Internet-Draft Continuity Receipts August 2026
version 1
event-id (16 random octets)
recovered-digest [ -44, <48 octets, SHA-384 over the plaintext> ]
sealed-material sealed-digest [ -44, <48 octets> ]
chunk-count omitted (see Privacy)
provenance-ref [ -44, <48 octets> ]
policy-id "recovery/model-tier2/v3"
recovery-environment tee-family "amd-sev-snp"
measurement [ -44, <48 octets, native length> ]
debug-mode false
platform-id omitted (see Privacy)
producing-environment tee-family "aws-nitro"
measurement [ -44, <48 octets, PCR0> ]
debug-mode false
attestation mode 1 (referenced)
ar-digest [ -44, <48 octets> ]
ar-format "application/eat+cwt"
verifier-id "verifier.example"
freshness method 1 (nonce)
nonce-digest [ -44, <48 octets> ]
outcome 1 (recovered)
recovered-at 1793750400
prev-event prev-statement [ -44, <48 octets> ]
equivalence kind 1 (byte-identical)
The Transparency Service registers it and returns a Receipt with vds
= 1 in the protected header and an inclusion proof under vdp label
-1. The Recovery Authority attaches the Receipt under label 394,
yielding a Transparent Statement.
A Relying Party eleven months later, holding only the Transparent
Statement and the Transparency Service public key, can establish: the
Issuer's signature is valid; the Statement occupies a specific
position in the log; the claimed lineage links to a prior Statement.
It cannot establish that the recovery occurred or that the
Attestation Results were favourable, because ar-digest references
bytes it does not have. A conformant verifier reports all three
categories separately (Section 8).
Note that equivalence = byte-identical is checkable only by a party
holding both digests. In the corpus of Section 10, one such restore
was demonstrated -- Ohio to Ireland -- and that is a claim about one
artifact, not a property of the mechanism.
Appendix B. Open Issues
These are stated for working group input and are expected to change.
Nikolaichuk Expires 1 March 2027 [Page 42]
Internet-Draft Continuity Receipts August 2026
1. *Subject choice.* Section 4.2 makes the Subject the Artifact.
The alternative -- Subject as the event, with the asset carried
in the payload -- trades chain enumerability for reduced
correlation. The author prefers enumerability and would like to
be argued with.
2. *Encoding of the payload.* Whether continuity-claims should be a
bespoke CBOR map, an EAT profile [RFC9711], or a CMW payload
[RFC9999]. The author has no strong view.
3. *Relationship to AR4SI.* The debug-mode and freshness rules here
are bespoke and ought to be expressible as constraints over
[I-D.ietf-rats-ar4si] or [I-D.ietf-rats-ear] claims. A future
revision probably should do that rather than restate hardware
specifics.
4. *Reference Values.* [I-D.ietf-rats-corim] is the right vehicle
for the expected measurement values a Relying Party would compare
against. This document does not reference them and probably
should.
5. *Charter fit.* The SCITT charter is about supply chain integrity
and transparency, and excludes payload content data formats.
This document defines a payload content data format. The
author's reading is that the exclusion targets Bill-of-Materials-
class formats rather than the claim structure of a Statement, but
the working group may read it differently, and the author would
rather be told early than late. If the answer is that this
belongs elsewhere or nowhere, that is a useful answer.
6. *Splitting with TAP.* [TAP] and this document were written as a
pair. A reviewer may reasonably conclude they should be one
document, or that the key-release half does not belong in the
IETF at all.
7. *Intended status.* This revision is Informational. A payload
intended for interoperation would normally be Standards Track.
The author will follow the working group.
8. *Nothing here is implemented.* Section 10 says so plainly. A
working group may reasonably decline to spend time on a
specification with no implementation, and the author's intention
is to close that gap rather than argue about it.
Nikolaichuk Expires 1 March 2027 [Page 43]
Internet-Draft Continuity Receipts August 2026
Acknowledgments
This document is an individual submission from an author with no
prior IETF publications. Errors in SCITT vocabulary, process, or
convention are the author's own, and corrections are welcome on the
SCITT mailing list.
Author's Address
Serhii Nikolaichuk
Independent
Austin, TX
United States of America
Email: nikolaichuk.s.f@gmail.com
Nikolaichuk Expires 1 March 2027 [Page 44]