]> Independent

Austin TX United States of America nikolaichuk.s.f@gmail.com

Security Supply Chain Integrity, Transparency, and Trust (SCITT) transparency service COSE receipts append-only log remote attestation confidential computing disaster recovery provenance 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. Status information for this document may be found at . Discussion of this document takes place on the Supply Chain Integrity, Transparency, and Trust Working Group mailing list (), which is archived at . Subscribe at .

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. 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 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 defines. This document specifies what such a Statement contains.

What This Document Defines A recovery event payload, in CDDL , carried as the payload of a Signed Statement. The choice of Subject, and the consequences of that choice for continuity chaining and for privacy. Three carriage modes for RATS Attestation Results in a recovery Statement, and the rules governing each. The binding of the resulting Receipt as a COSE Receipt with vds = 1 (RFC9162_SHA256). Registration Policy considerations for a Transparency Service that accepts recovery Statements. An honest account of where the reference implementation diverges from all of the above (, ).

What This Document Does Not Define A Transparency Service. Any service conforming to and reachable via is in scope as a registrar. A new verifiable data structure. 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 and its working group. The key-release decision that precedes a recovery. That is the subject of and is deliberately not restated here; see . Any claim about whether a recovered asset is semantically or behaviorally equivalent to the original. See , which treats the temptation to make such a claim as the principal hazard of this document.

Relationship to draft-nikolaichuk-rats-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. Concern draft-nikolaichuk-rats-tap This document Before or after the fact Authorization, at the time Record, after the fact Governing architecture RATS SCITT Central object Release Record Signed Statement + Receipt Who signs The Sealer The Recovery Authority Who witnesses An append-only log, unspecified A Transparency Service Attestation Consumed to decide Referenced as evidence for the record A deployment MAY use both. Where it does, the TAP Release Record is one of the inputs referenced by the recovery Statement defined here (), 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 (). This document does not depend on normatively. 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.

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 when, and only when, they appear in all capitals, as shown here.

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.

Terminology

Terms Imported from RFC 9943 This document uses the following terms exactly as defined in 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 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.

Terms Imported from RFC 9334 This document uses Attester, Verifier, Relying Party, Evidence, Attestation Results, Attesting Environment and Target Environment exactly as defined in . Note that "Relying Party" is defined in both and with compatible but not identical scope. Where the distinction matters this document writes "SCITT Relying Party" or "RATS Relying Party".

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 and is identified by the iss claim of the CWT_Claims protected header parameter .

Recovery Statement:

A Signed Statement whose payload is a continuity-claims structure () and whose Subject is the Artifact that was recovered.

Continuity Receipt:

The Receipt 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 . A Continuity Chain is an application-level construct and is not the same thing as the Transparency Service's Append-only Log; see .

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 .

Producing Environment:

The environment inside which the Artifact was originally sealed. It is an Attester in the sense of . It is frequently no longer reachable at recovery time, which is why its identity must be carried rather than queried.

Architecture

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.

Steps 5 through 8 are what this document specifies.

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.

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

The Recovery Statement

Envelope A Recovery Statement is a Signed Statement per : a tagged COSE_Sign1 , signed with an algorithm from .

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 ; the claims inside it are CWT claims . An Issuer: MUST include CWT_Claims with both iss and sub, as required by ; MUST set content_type to application/continuity-recovery+cbor () 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.

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. treats this at length and specifies a pseudonymous construction for deployments that need one.

Payload: continuity-claims

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

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

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

freshness:

How the timeliness of the Evidence underlying those Attestation Results was established (). 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.

Environment Identity and Measurement Length measurement carries the TEE's own measurement of the Target Environment: PCR0 for AWS Nitro Enclaves , 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 . 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 . 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 . region is OPTIONAL and carries a deployment-scoped region label. See 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.

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 apply, and a Conceptual Message Wrapper 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 . 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 and conflating them in a permanent record misstates who did the appraising. This document takes no position on the content of the Attestation Results. and define trustworthiness vocabularies that a future revision might profile; see .

Freshness 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 ; 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 explains why the field exists at all: every attestation artifact in the corpus underlying this document has this property.

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.

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

The Continuity Receipt

Binding Upon Registration, the Transparency Service returns a Receipt per . 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 .

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

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

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 clears and what this document does not. Requesting one to accommodate an implementation detail would fragment the registry for no verifier's benefit. works through the implementation detail in question and concludes that it should be dropped, not registered.

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

Registration Policy Considerations 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 . 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; 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 asks of it, and would quietly convert a witness into an auditor whose failures are invisible.

The Detachment Trade-off 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 . 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 Policy over claims Possible Not possible Log discloses recovery detail Yes No Relying Party needs side channel No Yes, for the payload Suitable for public log Rarely Often 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.

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

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: Verify the Signed Statement signature and resolve the Issuer identified by iss. Verify each attached Receipt: check the Transparency Service signature, check vds, and recompute the inclusion path against the payload root. Where consistency Receipts are available, verify that the roots involved form a consistent sequence. Parse continuity-claims and check version. Where the Sealed Material is available, verify sealed-digest against it. Where the recovered Artifact is available, verify recovered-digest against it. Where a Continuity Chain is present, resolve prev-event and check chain order against log order, reporting any disagreement (). 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 , and a verifier that collapses it has converted a transparency mechanism into an assurance it was never entitled to give.

Divergence from the Reference Implementation The reference implementation described in 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 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.

What Maps Cleanly: The Hashing 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. defines it identically; revises and obsoletes without changing this construction. The consequence is concrete and favourable: an existing 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 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: 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 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.

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

What Does Not Map: TreeChainHead 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 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.

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 proofs Add The author has not yet performed this migration and does not wish to present a plan as a result. states what exists today.

Implementation Status This section records implementation status per 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.

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 tree as described in . 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 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.

Hardware Corpus An artifact corpus was captured while running one seal-and-restore workload across three TEE families . The counts below are produced by a script from the artifact bytes and are reproduced verbatim; they are also reported in , which the reader may already have. Family Files Distinct file hashes Distinct hardware identities AWS Nitro Enclaves 12 8 8 AMD SEV-SNP 10 8 4 Azure SGX / MAA 4 4 1 Total 26 20 13 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.

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 . forbids this. The implementation does it.

No corpus artifact carries a verifier-supplied nonce.

See .

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 .

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 exists as a consequence.

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 . Azure Key Vault Secure Key Release, which gates key export on an Azure Attestation token . The Confidential Containers Trustee Key Broker Service, which gates secret delivery on attestation . 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.

Security Considerations

What the Receipt Is and Is Not 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.

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.

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

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

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.

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, applies: ordering guarantees do not compose across them.

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.

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.

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.

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

The Subject as a Permanent Correlator 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:

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.

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.

Hardware Linkability TEE attestation exposes stable hardware identifiers. The corpus in 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.

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

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.

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

IANA Considerations

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 )

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

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, ) is sufficient and appropriate. See and .

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 rather than as a new type. See .

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.

Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. The payloads used in Remote ATtestation procedureS (RATS) may require an associated media type for their conveyance, for example, when the payloads are used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EATs). The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. Together, these mechanisms allow CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts such as X.509 certificates. Additionally, this document defines media types and CoAP Content-Formats that may be used to identify CMWs when transported over protocols such as HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, enables the evolution of message serialization formats without breaking compatibility, and avoids the need to redefine how messages are handled within each protocol. Fraunhofer SIT Bowball Technologies Ltd Microsoft Research This document specifies a REST API with the HTTP resources, request and response messages, and error handling needed for an interoperable implementation of a SCITT Transparency Service, as defined by the Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture. Fraunhofer SIT Microsoft Research Microsoft Research Microsoft Research This document defines a new verifiable data structure (VDS) type for COSE Receipts and inclusion proofs specifically designed for append- only logs produced by the Confidential Consortium Framework (CCF) to provide stronger tamper-evidence guarantees. Cisco Systems Fraunhofer SIT MIT Linaro Intel This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. Linaro Cisco Arm Limited Fraunhofer SIT This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. Fraunhofer SIT Linaro arm Independent Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. Amazon Web Services Amazon Web Services Microsoft Corporation Confidential Containers project Machine-generated manifest of hardware-signed attestation artifacts. Not yet publicly available; see Section 9.

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 ; content_type = application/continuity-recovery+cbor. The payload carries, in outline:

] 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 (). Note that equivalence = byte-identical is checkable only by a party holding both digests. In the corpus of , one such restore was demonstrated -- Ohio to Ireland -- and that is a claim about one artifact, not a property of the mechanism.

Open Issues These are stated for working group input and are expected to change. Subject choice. 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. Encoding of the payload. Whether continuity-claims should be a bespoke CBOR map, an EAT profile , or a CMW payload . The author has no strong view. Relationship to AR4SI. The debug-mode and freshness rules here are bespoke and ought to be expressible as constraints over or claims. A future revision probably should do that rather than restate hardware specifics. Reference Values. is the right vehicle for the expected measurement values a Relying Party would compare against. This document does not reference them and probably should. 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. Splitting with 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. Intended status. This revision is Informational. A payload intended for interoperation would normally be Standards Track. The author will follow the working group. Nothing here is implemented. 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.

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.