Continuity Receipts: Registering the Recovery of a Stateful Asset as a Signed Statement in a Transparency Service

1.1. What This Document Defines

1. A recovery event payload, in CDDL [RFC8610], carried as the payload of a Signed Statement.¶

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.¶

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.¶

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.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 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.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.¶

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.¶

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.1. Envelope

A Recovery Statement is a Signed Statement per [RFC9943]: a tagged COSE_Sign1 [RFC9052], signed with an algorithm from [RFC9053].¶

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 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.
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
)

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 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 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 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];¶

• 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 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.¶

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 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.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:¶

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.¶

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.¶

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

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.¶

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.¶

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.¶

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].¶

• 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.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 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.¶

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.¶

Implementations SHOULD distinguish internally between structural failures and integrity failures, and SHOULD treat integrity failures as potential attacks rather than routine errors.¶

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.¶

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.¶

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.¶

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.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.¶

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.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>.

[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>.

[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>.

[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>.

[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.