| Internet-Draft | Trusted Artifact Provenance (TAP) | August 2026 |
| Nikolaichuk | Expires 1 March 2027 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-nikolaichuk-rats-tap/.¶
Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (mailto:rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Subscribe at https://www.ietf.org/mailman/listinfo/rats/.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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. [RFC9334] defines the roles, the conceptual messages, and the topological patterns; [RFC9711] defines an Evidence and Attestation Results token format; [I-D.ietf-rats-ar4si] and [I-D.ietf-rats-ear] define how Attestation Results express trustworthiness; [I-D.ietf-rats-corim] and [I-D.ietf-rats-endorsements] 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.¶
TAP is downstream of [RFC9334]. 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 [I-D.ietf-rats-reference-interaction-models] and [RFC9999]).¶
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.¶
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 Section 10.7.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
This document uses the following terms exactly as defined in [RFC9334], 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 [RFC9334] meaning is intended.¶
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.¶
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.¶
Symmetric key material that decrypts one or more chunks of a Sealed Artifact.¶
The environment in which an Artifact is sealed. It contains an Attesting Environment and is an Attester in the sense of [RFC9334].¶
The environment in which a Sealed Artifact is decrypted and the Artifact is reassembled. It is an Attester in the sense of [RFC9334].¶
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.¶
A signed statement binding an Artifact digest to the attested identity of the Producing Environment, produced under the Producer contract (Section 5).¶
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 [RFC9334].¶
The entity that appraises Provenance Records and Release Records after the fact. A TAP Verifier is a Relying Party in the sense of [RFC9334], operating in an audit posture rather than an authorization posture.¶
The permit-or-deny outcome the Sealer reaches for one request to reconstruct one Artifact in one Reconstruction Environment.¶
The signed, log-committed object documenting a Release Decision (Section 4.3).¶
An append-only log to which Release Records are committed (Section 4.4).¶
The three contract names in this document -- Producer, Verifier, and Sealer -- are inherited from the implementation that motivated it. "Verifier" collides with the [RFC9334] 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 [RFC9334] meaning; and¶
states the mapping of every TAP entity onto an [RFC9334] role in Section 3.2.¶
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 Appendix B.¶
The left half of Figure 1 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.¶
| 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 (Section 4.3).¶
TAP is compatible with both patterns of [RFC9334] Section 5.¶
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 Section 9.¶
The Reconstruction Environment obtains Attestation Results from a Verifier and presents them to the Sealer. In this model the freshness requirements of Section 8 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.¶
Relative to [RFC9334], 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 [RFC9943], and a deployment MAY use a SCITT transparency service as its Release Log; see Section 4.4.¶
All objects defined in this section are encoded as CBOR [RFC8949] and described in CDDL [RFC8610]. All signed objects are COSE_Sign1 structures [RFC9052] using algorithms from [RFC9053].¶
The following common productions are used throughout.¶
; digest; alg id from the COSE Algorithms registry ; together with the digest value. digest = [ alg: int, value: bstr ] ; An opaque, deployment-scoped identifier. opaque-id = bstr .size (8..64) ; An untagged epoch-based date/time as defined by the CBOR prelude. timestamp = ~time¶
A Provenance Record binds an Artifact to the attested identity of the environment that sealed it.¶
provenance-record = {
version: 1,
artifact-id: opaque-id,
artifact-digest: digest,
chunk-digests: [ + digest ],
producer-identity: environment-identity,
? evidence-ref: digest,
? ar-ref: ar-reference,
sealed-at: timestamp,
? aad-profile: tstr,
}
environment-identity = {
tee-family: tstr, ; "aws-nitro", "amd-sev-snp", ...
measurement: digest, ; measurement of the Target Env
? svn: uint, ; security version, if defined
? platform-id: bstr, ; see Section 11 on linkability
debug-mode: bool,
}
¶
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 Appendix A 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 (Section 7).¶
ar-reference = {
ar-digest: digest,
? ar-format: tstr, ; media type, e.g. EAT [RFC9782]
? verifier-id: opaque-id,
? ar-issued-at: timestamp,
}
¶
ar-format, where present, carries the media type of the referenced
Attestation Results; for Entity Attestation Tokens the registered media types of
[RFC9782] 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 = {
version: 1,
request-id: opaque-id,
artifact-id: opaque-id,
artifact-digest: digest,
policy-id: tstr,
target-identity: environment-identity, ; Reconstruction Env
ar: ar-reference,
freshness: freshness-proof,
decision: decision,
decided-at: timestamp,
released-dek-count: uint,
? deny-reason: tstr,
? log-inclusion: log-inclusion-proof,
}
decision = &(
permit: 1
deny: 2
error: 3
)
freshness-proof = {
method: freshness-method,
? nonce-digest: digest, ; digest of Sealer challenge
? epoch-id: bstr,
? evidence-time: timestamp,
}
freshness-method = &(
nonce: 1
epoch-id: 2
timestamp: 3
)
log-inclusion-proof = {
log-id: opaque-id,
tree-size: uint,
leaf-index: uint,
path: [ * bstr ],
}
¶
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 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 [RFC6962] is RECOMMENDED; [RFC9162] is a suitable successor
construction. A deployment MAY use a transparency service conforming to
[RFC9943] and [I-D.ietf-scitt-scrapi] 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.¶
A Producer MUST:¶
Seal each chunk of the Artifact with an AEAD construction [RFC5116]. 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 (Section 4.1) 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
Section 10.3.¶
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 Section 8. 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 Section 10.3.¶
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 (Section 4.4). 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 Section 10.4.¶
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.¶
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.¶
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.¶
[RFC9334] 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 [RFC4086].¶
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.¶
[RFC9334] 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 Appendix A.¶
Where the epoch ID method is used, see [I-D.ietf-rats-epoch-markers] 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 Section 10.2. It is stated there rather than here because it is a property of the evidence collected to date, not of the contract.¶
This section records the implementation status of TAP as required by [RFC7942], 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.¶
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.¶
Prototype. There is no production deployment, no design partner, and no end user.¶
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 Section 8 are implemented in the contract but are not exercised by the captured corpus; see Section 10.2.¶
Apache-2.0 relicensing is in progress. The repository is not public at the time of writing.¶
The author.¶
An artifact corpus was captured while running one seal-and-restore workload across three TEE families [TAP-CORPUS]. 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.¶
The following are stated because omitting them would misrepresent the implementation status. Each is a real gap.¶
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
Section 6, not its security properties.¶
They carry all-zero PCRs and therefore prove nothing about enclave identity. Eight are production-mode with non-zero PCR0. See Section 10.3.¶
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 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 Section 10.7.¶
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 Appendix A.¶
Operational validation is implemented. Semantic and behavioral validation are documented but not implemented.¶
The cross-cloud coordination result contains no timing field. No wire-to-acceptance latency figure exists for that run, and this document states none.¶
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 Section 4.3. 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.¶
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.¶
The freshness requirements of Section 8 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 Section 9 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 Section 8 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.¶
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 Section 9 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.¶
Step 8 of Section 6 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 Appendix A) and using that key to establish the transport. A Sealer that cannot establish such a binding MUST deny.¶
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 [RFC9943]. A TAP Verifier SHOULD report whether the inclusion proofs it checked were validated against a witnessed root or an operator-asserted one.¶
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.¶
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 Section 9 makes this concrete: its reconstruction backend is a deterministic placeholder that performs no inference, and it produces valid Release Records regardless.¶
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.¶
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.¶
TEE attestation frequently exposes stable hardware identifiers. The corpus in Section 9 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 [I-D.ietf-rats-daa] addresses the underlying linkability problem for Evidence and is complementary to the mitigations above. This document does not profile it.¶
This document has no IANA actions.¶
A future revision may request registrations if the working group finds the
objects in Section 4.3 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 [RFC9711] or the Conceptual Message Wrapper [RFC9999] rather
than as new types. See Appendix B.¶
This appendix records, for each TEE family exercised by the implementation in Section 9, 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 [I-D.ietf-rats-corim] for Reference Values rather than restating vendor formats.¶
Evidence: CBOR-encoded COSE_Sign1 attestation document from the Nitro Security Module [AWS-NITRO].¶
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.¶
Evidence: SEV-SNP attestation report [AMD-SEVSNP].¶
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 Section 10.2.¶
Platform identity: CHIP_ID. See the privacy considerations above before recording it.¶
Debug detection: the DEBUG bit of the guest POLICY field.¶
Evidence: an ECDSA quote per [INTEL-DCAP], or a signed token from Microsoft Azure Attestation [AZURE-MAA] 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 Section 9.¶
A simulator binding exists in the implementation for testing. It uses real AES-256-GCM with a simulated hardware root and Ed25519 [RFC8032] 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.¶
These are stated for working group input and are expected to change.¶
Naming. The TAP role called "TAP Verifier" collides with the [RFC9334] Verifier and should probably be renamed. See Section 2.3.¶
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
[RFC9711], a Conceptual Message Wrapper payload [RFC9999], or a SCITT
statement [RFC9943]. 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. [I-D.ietf-rats-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.¶
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.¶