]> Independent

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

Security Remote ATtestation ProcedureS (RATS) remote attestation confidential computing trusted execution environment attestation-gated key release provenance transparency log The Remote ATtestation procedureS (RATS) architecture (RFC 9334) defines how Evidence is conveyed from an Attester to a Verifier and how the resulting Attestation Results are conveyed to a Relying Party. It deliberately stops at the point where a Relying Party has appraised Attestation Results. This document specifies Trusted Artifact Provenance (TAP), a consumer of Attestation Results that defines what happens next in one specific and recurring case: releasing sealed key material to a process that reconstructs a stateful asset inside an attested environment, and recording the release decision as an auditable object. TAP defines three contracts. The Producer contract governs how an artifact is sealed and bound to the attested identity of the environment that produced it. The Sealer contract governs the attestation-gated release of key material to a reconstruction environment. The TAP Verifier contract governs after-the-fact appraisal of provenance and release records. TAP does not define an appraisal policy language, does not define a new Evidence format, and does not replace any part of RFC 9334. Status information for this document may be found at . Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (), which is archived at . Subscribe at .

Introduction Confidential computing deployments increasingly move data at rest between Trusted Execution Environments (TEEs), across regions, and across cloud providers. A common pattern is: seal an artifact inside an attested environment, persist the sealed bytes on untrusted storage, and later reconstruct the asset inside a different attested environment, releasing the key material only if that environment's attested identity satisfies a policy. The attestation half of that pattern is well covered. defines the roles, the conceptual messages, and the topological patterns; defines an Evidence and Attestation Results token format; and define how Attestation Results express trustworthiness; and cover Reference Values and Endorsements. The RATS charter is explicit that appraisal policy formats are out of scope for the working group. The other half is not covered, and in practice each deployment reinvents it: What is the object that gets released, and what is it bound to? What inputs MUST a release decision consider, beyond the Attestation Results themselves? What durable, third-party-checkable record does the release decision leave behind? Deployments answer these questions with bespoke, undocumented glue. The consequence is that an auditor who is handed a reconstructed asset has no standard way to ask "which attested environment produced the sealed bytes, which attested environment was permitted to reconstruct them, under which policy, and who can check that claim independently." This document specifies TAP: a small, deliberately narrow contract that answers those three questions in RATS vocabulary, and nothing else.

Relationship to the RATS Architecture TAP is downstream of . It is a consumer of Attestation Results, not a producer of Evidence and not a substitute for a Verifier. Concretely: TAP does NOT define an Evidence format. Evidence remains whatever the TEE family emits, conveyed by whatever means the deployment chooses (see and ). TAP does NOT define an Attestation Results format. It consumes one, and it requires that the consumed Attestation Results be referenced by digest in the record it emits. TAP does NOT define an Appraisal Policy for Evidence or an Appraisal Policy for Attestation Results, nor a language for expressing either. This is consistent with the RATS working group charter, which places both out of scope. TAP constrains only the inputs a release decision MUST consider and the format of the record documenting the decision that was made. A record of a decision is not a policy. TAP DOES define what a Relying Party emits when it authorizes the release of sealed material, so that the authorization is verifiable after the fact by an entity that was not present when it happened.

Scope In scope: The Sealed Artifact and its binding to a producing environment's attested identity (the Provenance Record). The normative procedure a Sealer follows before releasing key material. The Release Record: a signed, log-committed statement of a release decision. Freshness requirements on the Evidence underlying a release decision. Rejection rules for environments whose measurements do not identify code (notably debug-mode enclaves). Out of scope: Evidence formats, Evidence conveyance, and Verifier internals. Appraisal policy languages, for either appraisal stage. Trust anchor distribution and rotation. Key hierarchy design, key escrow, and key lifecycle beyond the release event. Whether a reconstructed asset is semantically or behaviorally equivalent to the original. TAP is a provenance and authorization contract. It makes no fidelity claim of any kind. See .

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 pending United States provisional patent applications 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 9334 This document uses the following terms exactly as defined in , and does not redefine, narrow, or extend any of them: Attester, Verifier, Relying Party, Endorser, Reference Value Provider, Verifier Owner, Relying Party Owner, Evidence, Endorsements, Reference Values, Attestation Results, Appraisal Policy for Evidence, Appraisal Policy for Attestation Results, Attesting Environment, Target Environment, Passport Model, Background-Check Model. Where this document writes "Verifier" without qualification, the meaning is intended.

Terms Defined by This Document

Artifact:

The stateful asset being sealed and later reconstructed. TAP treats an Artifact as an opaque, ordered sequence of octets. Examples include model weights, a database snapshot, and an index.

Sealed Artifact:

The ciphertext form of an Artifact, together with the metadata required to locate its chunks and its Provenance Record. The Sealed Artifact is assumed to reside on untrusted storage.

Data Encryption Key (DEK):

Symmetric key material that decrypts one or more chunks of a Sealed Artifact.

Producing Environment:

The environment in which an Artifact is sealed. It contains an Attesting Environment and is an Attester in the sense of .

Reconstruction Environment:

The environment in which a Sealed Artifact is decrypted and the Artifact is reassembled. It is an Attester in the sense of .

Reconstruction Process:

The code executing inside the Reconstruction Environment that consumes released DEKs and produces the reconstructed Artifact. It is the Target Environment whose measurement appears in the Evidence.

Provenance Record:

A signed statement binding an Artifact digest to the attested identity of the Producing Environment, produced under the Producer contract ().

Sealer:

The entity that holds, or can derive, DEKs and decides whether to release them to a Reconstruction Environment. A Sealer is a Relying Party in the sense of .

TAP Verifier:

The entity that appraises Provenance Records and Release Records after the fact. A TAP Verifier is a Relying Party in the sense of , operating in an audit posture rather than an authorization posture.

Release Decision:

The permit-or-deny outcome the Sealer reaches for one request to reconstruct one Artifact in one Reconstruction Environment.

Release Record:

The signed, log-committed object documenting a Release Decision ().

Release Log:

An append-only log to which Release Records are committed ().

A Note on the Name "Verifier" The three contract names in this document -- Producer, Verifier, and Sealer -- are inherited from the implementation that motivated it. "Verifier" collides with the role of the same name, which is a different entity doing a different job. To avoid ambiguity, this document: always writes the TAP role as "TAP Verifier", never as bare "Verifier"; reserves unqualified "Verifier" for the meaning; and states the mapping of every TAP entity onto an role in . The author considers this collision a defect in the naming rather than in the architecture, and solicits working group guidance on renaming the TAP role (candidates considered: "Auditor", "Provenance Verifier", "Attestor of Record"). See .

Architecture

Overview

The left half of is the Producer contract. The right half is the Sealer contract. The bottom is the TAP Verifier contract. The box labelled "Verifier (RFC 9334)" is not defined by this document; TAP consumes its output.

Mapping to RFC 9334 Roles TAP entity RFC 9334 role Conceptual message it handles Producing Environment Attester produces Evidence Reconstruction Environment Attester produces Evidence Sealer Relying Party consumes Attestation Results TAP Verifier Relying Party consumes Attestation Results (historical) (not defined here) Verifier Evidence to Attestation Results (not defined here) Endorser, Reference Value Provider Endorsements, Reference Values A single deployment MAY collocate the Sealer and the Verifier in one process. Collocation does not merge the roles: the appraisal of Evidence and the decision to release key material remain distinct steps with distinct policies, and a conformant implementation MUST be able to emit the Attestation Results digest that the Release Record references ().

Topological Patterns TAP is compatible with both patterns of Section 5.

Background-Check Model:

The Reconstruction Environment presents Evidence to the Sealer, which forwards it to a Verifier and receives Attestation Results. This is the model exercised by the implementation described in .

Passport Model:

The Reconstruction Environment obtains Attestation Results from a Verifier and presents them to the Sealer. In this model the freshness requirements of apply to the Evidence underlying the Attestation Results, not to the presentation of the Attestation Results, and the Sealer MUST be able to establish that the Attestation Results describe the environment that is presenting them.

What TAP Adds Relative to , TAP adds exactly two things: A defined consequence of a successful appraisal. Appraisal succeeding is not, by itself, an action. TAP names the action -- release of DEKs to a Reconstruction Process -- and constrains it. The decision as an object. The Release Record makes the authorization itself durable and third-party-checkable, rather than an ephemeral branch in a Relying Party's code. This is structurally similar to the receipt concept in , and a deployment MAY use a SCITT transparency service as its Release Log; see .

Objects All objects defined in this section are encoded as CBOR and described in CDDL . All signed objects are COSE_Sign1 structures using algorithms from . The following common productions are used throughout.

Provenance Record A Provenance Record binds an Artifact to the attested identity of the environment that sealed it.

A Producer MUST populate measurement with the TEE's own measurement of the Target Environment (for example PCR0 for AWS Nitro Enclaves, MRENCLAVE for Intel SGX, the launch MEASUREMENT for AMD SEV-SNP). A Producer MUST populate debug-mode truthfully. A Producer MUST NOT synthesize, truncate, or re-hash the measurement into a different length or algorithm; if a TAP profile requires a normalized length, the normalization MUST be specified in the corresponding binding in and the original value MUST remain recoverable from evidence-ref. evidence-ref and ar-ref are OPTIONAL because a Producing Environment does not always have a Verifier available at sealing time. A Provenance Record carrying neither is a self-asserted claim about the producing environment and MUST be treated as such by a TAP Verifier ().

Attestation Results Reference

ar-format, where present, carries the media type of the referenced Attestation Results; for Entity Attestation Tokens the registered media types of apply. TAP references Attestation Results by digest rather than embedding them. This keeps the Release Record small and avoids duplicating whatever confidentiality or privacy handling the Attestation Results are already subject to. A deployment that needs the Attestation Results themselves to be auditable MUST arrange for them to be retrievable by digest; TAP does not specify how.

Release Record

A Sealer MUST emit a Release Record for every Release Decision, including denials and errors. Emitting records only for permits produces a log that cannot distinguish "no one asked" from "someone asked and was refused", which destroys most of the audit value. A Sealer MUST sign the Release Record as a COSE_Sign1 with a key whose certificate chain or trust anchor is available to TAP Verifiers. released-dek-count MUST be zero when decision is deny or error.

Release Log Release Records MUST be committed to an append-only log before the corresponding DEKs are transmitted. The log MUST provide inclusion proofs. The Merkle tree construction of is RECOMMENDED; is a suitable successor construction. A deployment MAY use a transparency service conforming to and as its Release Log, in which case the transparency service's receipt SHOULD be carried in log-inclusion. Committing before transmitting, rather than after, is the point of the requirement. A Sealer that transmits first and logs afterwards can lose the record of exactly the releases an attacker cares about.

The Producer Contract A Producer MUST: Seal each chunk of the Artifact with an AEAD construction . The Additional Authenticated Data MUST include the artifact-id, the chunk index, and the total chunk count. Use a distinct AEAD nonce for every invocation under a given key. Two invocations with the same key, plaintext, and AAD MUST NOT produce identical ciphertext. Compute artifact-digest over the plaintext Artifact and chunk-digests over the ciphertext chunks, so that a TAP Verifier can check chunk integrity without holding any DEK. Emit a Provenance Record () signed by a key held inside the Producing Environment, and bind that key to the Producing Environment's Evidence where the TEE family permits it (for example via the public key field of an AWS Nitro attestation document, or REPORT_DATA for AMD SEV-SNP). A Producer SHOULD obtain Attestation Results for the Producing Environment at sealing time and populate ar-ref. A Producer that cannot do so MUST leave ar-ref absent rather than populating it with a self-assertion. A Producer MUST NOT emit a Provenance Record with debug-mode set to false when the underlying Evidence indicates a debug or unmeasured configuration. See .

The Sealer Contract

Release Procedure On receiving a request to release DEKs for an Artifact to a Reconstruction Environment, a Sealer MUST perform the following steps, in order, and MUST abort with a deny Release Record on the first failure: Establish freshness. Obtain Evidence that is fresh under . In the Background-Check Model, the Sealer MUST supply the challenge itself, or obtain it from an entity it trusts for that purpose. Obtain Attestation Results. Convey the Evidence to a Verifier and obtain Attestation Results. The Sealer MUST NOT appraise raw Evidence itself unless it is also acting as a Verifier, in which case it MUST still produce Attestation Results as a distinct, digestible object. Check the Attestation Results are acceptable. Apply the deployment's Appraisal Policy for Attestation Results. The policy language is out of scope; the policy identifier MUST be recorded in policy-id. Reject unmeasured environments. If the Attestation Results indicate that the Reconstruction Environment is in a debug mode, or that its measurements do not identify code, the Sealer MUST deny unless the deployment has explicitly enabled debug acceptance for a non-production Artifact. See . Compare identities byte-wise. Any measurement comparison MUST be byte-wise over the full value. Prefix matches, truncated comparisons, and case-insensitive hex comparisons MUST NOT satisfy an identity constraint. Bind the decision to the Artifact. The Sealer MUST confirm that the artifact-digest in the request matches the artifact-digest in the Artifact's Provenance Record. A Sealer MUST NOT release DEKs for an Artifact whose Provenance Record it cannot locate or whose signature does not verify. Emit and commit the Release Record. Construct the Release Record, sign it, and commit it to the Release Log (). The Sealer MUST NOT transmit any DEK before the log commitment has succeeded. Release. Transmit the DEKs to the Reconstruction Environment over a channel whose peer is cryptographically bound to the attested identity that was appraised in step 3. Releasing to a channel that is merely network-adjacent to the attested environment defeats the entire procedure; see . A Sealer MUST fail closed. Any error condition that leaves the Sealer unable to complete a step -- including inability to reach the Verifier, inability to commit to the Release Log, or an unparseable Provenance Record -- MUST result in deny or error, never in release.

Scope of a Release A Release Decision authorizes one Reconstruction Environment to reconstruct one Artifact. A Sealer MUST NOT treat a permit as authorization for: a different Artifact, a subsequent reconstruction after the Reconstruction Environment has been restarted or re-measured, or a different environment with the same measurement but different Evidence. The third exclusion is deliberate. Identical measurements across two environments mean identical code, not identical instances; without it, an attacker who obtains one permit can replay it from an environment the Sealer never appraised.

The TAP Verifier Contract A TAP Verifier appraises the record trail after the fact. It MUST be able to operate offline, with no access to the Sealer, the Verifier, or the Reconstruction Environment. Given a Sealed Artifact, its Provenance Record, and a set of Release Records, a TAP Verifier MUST: Verify the Provenance Record signature and, where evidence-ref is present and the Evidence is available, verify that the Evidence supports the claimed producer-identity. Verify the chunk digests in the Provenance Record against the Sealed Artifact bytes. Verify each Release Record signature. Verify each Release Record's log-inclusion proof against the Release Log's published root. Report, separately and without conflating them: a. what the records assert, b. which assertions are backed by verified signatures over hardware-rooted Evidence, and c. which assertions are self-asserted or unverifiable with the material at hand. Requirement 5 is normative and is the substance of this contract. A TAP Verifier that returns a single boolean is not conformant. The distinction between "asserted" and "cryptographically established" is precisely the distinction an auditor is asking about, and collapsing it is how provenance systems come to overstate what they know. A TAP Verifier MUST report a Provenance Record with no evidence-ref and no ar-ref as self-asserted, regardless of how well-formed it is.

Freshness and Replay Section 10 describes three approaches to establishing the timeliness of Evidence: synchronized clocks, nonces, and epoch IDs. TAP requires that one of them be used and recorded. A Sealer MUST NOT reach a permit decision on the basis of Evidence whose freshness it cannot establish by one of the three methods, and MUST record the method used in freshness-proof. Where the nonce method is used: The challenge MUST be at least 16 octets and MUST be generated from a cryptographically secure random source . The challenge MUST be supplied by the Sealer, or by an entity the Sealer trusts for that purpose, and MUST NOT be chosen by the Reconstruction Environment. The Evidence MUST bind the challenge such that any single-bit change in the challenge causes appraisal to fail. The Sealer MUST NOT accept the same challenge value twice. does not itself specify a minimum nonce length; the 16-octet floor above is a requirement of this document, chosen to match the 128-bit security level of the AEAD and signature primitives in common use across the TEE families in . Where the epoch ID method is used, see for the distribution mechanism and for the race conditions inherent in epoch windowing. A known gap in the artifact corpus underlying this document is described in . It is stated there rather than here because it is a property of the evidence collected to date, not of the contract.

Implementation Status This section records the implementation status of TAP as required by , and is to be removed by the RFC Editor before publication. It describes one implementation. Inclusion here is not an endorsement, and the absence of independent implementations is itself information the working group should weigh.

Overview

Implementation:

Vault Genome core. Written in Go. 354 Go source files of which 129 are tests; 1,304 Go test functions; 352 adversarial test scenarios; 14 continuous integration checks enforcing architectural invariants; 17 frozen interface contracts; an abstract-syntax-tree-level import-graph test enforcing separation between the authority component and worker components. A Python SDK and a command-line client exist, as do Terraform modules for AWS, Azure, and GCP.

Level of maturity:

Prototype. There is no production deployment, no design partner, and no end user.

Coverage:

The object formats, the Sealer release procedure ordering, the log-before- release requirement, the fail-closed requirement, and the RFC 6962 log commitment are implemented. The freshness requirements of are implemented in the contract but are not exercised by the captured corpus; see .

Licensing:

Apache-2.0 relicensing is in progress. The repository is not public at the time of writing.

Contact:

The author.

What Has Been Demonstrated on Hardware 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 here verbatim. Family Files Distinct file hashes Distinct hardware identities Identity field AWS Nitro Enclaves 12 8 8 Nitro Security Module id AMD SEV-SNP 10 8 4 AMD-SP CHIP_ID Azure SGX / MAA 4 4 1 SGX MRENCLAVE Total 26 20 13   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 over the public Internet following an attestation handshake, producing an audit chain of length three.

What Has NOT Been Demonstrated The following are stated because omitting them would misrepresent the implementation status. Each is a real gap.

Attestation verification is not wired to vendor cryptography.

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 yet verify them against vendor libraries. Closing this is scheduled work targeting 2026-10-31, using veraison/go-nitro-enclave-attestation-document for AWS Nitro, google/go-sev-guest for AMD SEV-SNP, and Intel SGX DCAP. Until it is closed, the implementation demonstrates the plumbing of , not its security properties.

Four of the twelve AWS Nitro documents are debug-mode.

They carry all-zero PCRs and therefore prove nothing about enclave identity. Eight are production-mode with non-zero PCR0. See .

None of the four Azure artifacts is offline-verifiable.

All four publish the decoded claims payload but not the compact signed JWT. A reader cannot re-verify them against Microsoft's keys. They evidence plumbing, not proof.

The reconstruction backend performs no inference.

The current backend is a deterministic byte-level Markov chain of order 3 behind a frozen interface. It is a placeholder. It is not a neural network. Any claim about reconstruction quality would be unsupported. 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 and MUST NOT be used in production, per .

Only one validation dimension is implemented.

Operational validation is implemented. Semantic and behavioral validation are documented but not implemented.

No cross-cloud latency was measured.

The cross-cloud coordination result contains no timing field. No wire-to-acceptance latency figure exists for that run, and this document states none.

A prior novelty claim was retracted.

An earlier version of the project's documentation asserted that no comparable work existed. That claim was withdrawn and replaced with a narrower claim limited to the governance and release-record aspects described in . The retraction is recorded in the project's revision history and is noted here because a reader evaluating this document is entitled to know that the author has previously overstated and corrected.

Security Considerations

Trust Model TAP assumes the network, the host operating system, the hypervisor where one is present, and all storage are untrusted. TAP assumes that: the TEE silicon vendor's attestation signing infrastructure is intact; the Verifier correctly implements its appraisal and is itself trustworthy to the Sealer; the Sealer's signing key is confined to an environment at least as protected as the environments it authorizes; and the Release Log is append-only in fact, not merely by assertion. Failure of any of these assumptions invalidates the guarantees of this document. TAP provides no recovery from silicon vendor key compromise. A deployment whose threat model includes that event MUST obtain attestation from independently rooted TEE families and require a quorum; expressing such a quorum requirement is out of scope for this revision.

Replay and Freshness The freshness requirements of exist because Evidence that is not bound to a challenge can be replayed. An attacker who captures Evidence from a legitimately attested environment, and who can present it later from an environment it controls, obtains DEKs for an Artifact it was never authorized to reconstruct. 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 that it is running now, for them. This is a genuine and currently open gap in the evidence supporting this document, and it is stated plainly: No artifact in the corpus described in carries a verifier-supplied nonce. All twelve AWS Nitro attestation documents have an empty nonce field. The AMD SEV-SNP reports carry non-zero REPORT_DATA, but REPORT_DATA in those runs was chosen by the producing side and is therefore a producer assertion, not a challenge. The Azure artifacts are decoded claim payloads with no challenge binding recoverable from them. The consequence is that the corpus demonstrates that these environments can produce hardware-signed attestations, and does not demonstrate that any of those attestations was produced in response to a live challenge. The contract in is therefore normatively required and not yet evidenced. A reader should treat the corpus as evidence of reach across hardware, not as evidence of replay resistance. An implementation MUST NOT be described as conforming to this document on the basis of a corpus with this property.

Debug-Mode and Unmeasured Environments Every TEE family supports a debug or development configuration in which the protections that make attestation meaningful are relaxed. In AWS Nitro Enclaves, debug-mode attestation documents carry all-zero Platform Configuration Registers. An all-zero PCR0 is not a measurement of anything; it is the absence of a measurement, wearing the shape of one. Analogous configurations exist for Intel SGX (the DEBUG attribute) and AMD SEV-SNP (the DEBUG policy bit). The failure mode is specific and common: a verifier that parses an attestation document, finds a well-formed PCR0 field, and compares it against an expected value will happily accept an all-zero PCR0 if the expected value has also been configured as all zeros during development, or will accept the document as "structurally valid" if it never compares at all. Accordingly: A Sealer MUST reject Evidence indicating a debug or unmeasured configuration, unless debug acceptance has been explicitly enabled for a specific, non-production Artifact. An implementation MUST treat an all-zero measurement as a distinct rejection condition with its own error, not as a measurement mismatch. The two mean different things operationally: a mismatch suggests wrong code, an all-zero value suggests wrong platform configuration. A TAP Verifier MUST report debug-mode as true in its output whenever the underlying record or Evidence indicates it, and MUST NOT report such a record as establishing environment identity. Four of the twenty-six artifacts in the corpus of are debug-mode. They are retained in the corpus and labelled, rather than removed, because a corpus that quietly drops its own negative cases is less useful than one that keeps them.

Channel Binding Step 8 of requires that DEKs be released over a channel bound to the appraised identity. Without this, TAP degrades into an authorization decision about one entity followed by a key transfer to a possibly different one. The binding SHOULD be established by including a public key generated inside the Reconstruction Environment in the Evidence itself (the mechanism differs by family; see ) and using that key to establish the transport. A Sealer that cannot establish such a binding MUST deny.

Compromise of the Release Log An append-only log that a single operator controls is append-only by that operator's word. A Sealer and a TAP Verifier that both trust the same unwitnessed log can be shown different views of it, and neither will detect the divergence. Deployments SHOULD obtain signed tree heads from independent witnesses, or use a transparency service that provides them . A TAP Verifier SHOULD report whether the inclusion proofs it checked were validated against a witnessed root or an operator-asserted one.

Sealed Material and Key Lifetime TAP does not provide forward secrecy for sealed Artifacts. An adversary who obtains a DEK obtains the corresponding plaintext chunks for as long as those chunks exist. Release Records make such an event auditable after the fact; they do not prevent it. Deployments handling long-lived Artifacts SHOULD re-seal under fresh keys on a schedule and SHOULD treat DEK release as an event with a retention consequence, not merely an access-control outcome.

Reconstruction Fidelity Is Not a Security Property TAP establishes who produced a Sealed Artifact and who was authorized to reconstruct it. It establishes nothing about whether the reconstructed asset behaves like the original, means the same thing, or is fit for any purpose. A Release Record is not a statement of correctness. This distinction matters because the two are easily conflated in deployment: an audit trail showing an authorized reconstruction inside an attested environment reads, to a non-specialist, like an assurance that the result is good. It is not. Implementations SHOULD NOT present Release Records in interfaces that imply a fidelity claim, and any fidelity claim MUST rest on separate evidence. The implementation described in makes this concrete: its reconstruction backend is a deterministic placeholder that performs no inference, and it produces valid Release Records regardless.

Error Handling and Side Channels Errors returned by a Sealer to a requesting environment MUST NOT distinguish between failure causes in a way that lets a requester probe the appraisal policy. A requester learns permit or deny. Detailed causes belong in the Release Record and in operator-facing logs, not in the response. Implementations SHOULD distinguish internally between structural failures (a malformed request; the requester should fix and retry) and integrity failures (a signature that does not verify; a nonce that does not match), and SHOULD treat integrity failures as potential attacks warranting escalation rather than as routine errors.

Denial of Service A Sealer that fails closed can be denied by denying it access to its Verifier or its Release Log. This is the correct trade: availability of the reconstruction path is sacrificed to prevent unauthorized release. Deployments that cannot accept this SHOULD add redundancy at the Verifier and Log, and MUST NOT add a bypass.

Privacy Considerations TEE attestation frequently exposes stable hardware identifiers. The corpus in illustrates 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 identifiers are stable across workloads and across tenants of the same physical part, and correlating them across Release Records reveals which physical machines a given workload has run on and when. Accordingly: The platform-id field of environment-identity is OPTIONAL and SHOULD be omitted unless a deployment has a specific need for it that outweighs the linkability it creates. Where a deployment needs machine-level accountability without machine-level linkability, platform-id SHOULD carry a salted, per-deployment pseudonym rather than the raw hardware identifier, with the mapping held by the deployment operator. Release Records committed to a publicly readable log expose their contents to everyone. Deployments SHOULD assess whether artifact-id, policy-id, and target-identity are safe to publish in their setting, and MAY commit a digest of the Release Record to a public log while retaining the record itself. Direct Anonymous Attestation addresses the underlying linkability problem for Evidence and is complementary to the mitigations above. This document does not profile it.

IANA Considerations This document has no IANA actions. A future revision may request registrations if the working group finds the objects in worth registering. The candidates are a CBOR tag and a media type for release-record, and a media type for provenance-record. No registration is requested at this revision, because the object definitions are not stable enough to warrant one and because the working group may prefer that these objects be expressed as a profile of an existing format such as or the Conceptual Message Wrapper rather than as new types. See .

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. 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. This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] 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 elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. 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. 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. 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. 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. 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. 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). 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. 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. 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. 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. Fraunhofer SIT University of Surrey University of Surrey Ubitech Microsoft This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The protocol entity DAA Issuer is introduced and its mapping with existing RATS roles in DAA protocol steps is specified. 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. Armidale Consulting Fraunhofer SIT Linaro In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and uses Appraisal Policy for Evidence, typically with additional input from Endorsements and Reference Values, to generate Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it extends RFC9334 to provide further details on Reference Values and Endorsements, as these topics were outside the scope of the RATS charter when RFC9334 was developed. Fraunhofer SIT Linaro Huawei Technologies Arm Universität Bremen TZI This document defines Epoch Markers as a means to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system known as the Epoch Bell. Systems receiving Epoch Markers do not need to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a specific Epoch Marker establishes a new epoch that is shared among all recipients. This document defines Epoch Marker types, including CBOR time tags, RFC 3161 TimeStampToken, and nonce-like structures. It also defines a CWT Claim to embed Epoch Markers in RFC 8392 CBOR Web Tokens, which serve as vehicles for signed protocol messages. Fraunhofer SIT Fraunhofer SIT Huawei Technologies Cisco Systems This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. 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. Amazon Web Services Advanced Micro Devices, Inc. Intel Corporation Microsoft Corporation Machine-generated manifest of hardware-signed attestation artifacts. Not yet publicly available; see Section 9.

Concrete TEE Binding Considerations This appendix records, for each TEE family exercised by the implementation in , which field carries the measurement, which field can carry a channel-binding key, and how debug configuration is detected. It is informative at this revision; the author expects that per-family bindings need to be normative before the document is useful for interoperability, and that they should reference for Reference Values rather than restating vendor formats.

AWS Nitro Enclaves Evidence: CBOR-encoded COSE_Sign1 attestation document from the Nitro Security Module . Measurement: PCR0, the enclave image measurement. Channel binding: the public_key field of the attestation document. Challenge: the nonce field. Debug detection: all PCRs zero. Note: sixteen PCRs are present in the corpus documents; only PCR0, PCR1, PCR2, PCR3, PCR4 and PCR8 are meaningful for enclave identity, and a binding MUST state which it constrains.

AMD SEV-SNP Evidence: SEV-SNP attestation report . Measurement: the launch MEASUREMENT field. Channel binding and challenge: REPORT_DATA. Because a single field serves both purposes, a binding MUST specify the construction that combines them, and MUST NOT allow the producing side to choose REPORT_DATA freely when the field is being relied on for freshness. This is the origin of the gap in . Platform identity: CHIP_ID. See the privacy considerations above before recording it. Debug detection: the DEBUG bit of the guest POLICY field.

Intel SGX (DCAP and Azure Attestation) Evidence: an ECDSA quote per , or a signed token from Microsoft Azure Attestation carrying the appraised quote. Measurement: MRENCLAVE. MRSIGNER identifies the signer, not the code, and MUST NOT be used alone where code identity is required. Challenge and channel binding: REPORTDATA. Debug detection: the DEBUG attribute in the enclave attributes field. Note: a deployment relying on a Verifier-issued token MUST retain the compact signed form. Retaining only the decoded claims payload makes the artifact unverifiable by anyone else, which is the defect present in all four Azure artifacts in the corpus of .

Software Simulator A simulator binding exists in the implementation for testing. It uses real AES-256-GCM with a simulated hardware root and Ed25519 signatures over a measurement-and-challenge envelope. It MUST NOT be used in production, and an implementation MUST make a simulated root visibly distinct from a hardware root in every interface where a measurement is displayed.

Open Issues These are stated for working group input and are expected to change. Naming. The TAP role called "TAP Verifier" collides with the Verifier and should probably be renamed. See . Intended status. This revision is Informational. A contract intended for interoperation would normally be Standards Track. The author has no view worth defending on which is right and will follow the working group. Encoding. Whether release-record should be a new object, an EAT profile , a Conceptual Message Wrapper payload , or a SCITT statement . The author's weak preference is the last, on the grounds that a Release Record is a signed statement about an artifact and that is what SCITT is for. Relationship to AR4SI. defines trustworthiness tiers for Attestation Results. TAP's deny on debug-mode ought to be expressible as a constraint over AR4SI claims rather than as a bespoke rule, and probably should be in a future revision. Charter fit. The RATS charter excludes appraisal policy formats. This document deliberately avoids defining one, but a working group may nonetheless judge the release-decision object to fall outside the charter. If so, the SCITT working group may be the better home, and the author would rather be told that early than late. Scope of the Sealer. Whether key release belongs in a RATS document at all, or whether TAP should be split into a provenance document and a key-release document.

Acknowledgments This document is a first individual submission from an author with no prior IETF publications. Errors in RATS vocabulary, process, or convention are the author's own, and corrections are welcome on the RATS mailing list.