Trusted Artifact Provenance (TAP): A Producer, Verifier, and Sealer Contract for Attestation-Gated Reconstruction of Stateful Assets
draft-nikolaichuk-rats-tap-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Serhii Nikolaichuk | ||
| Last updated | 2026-08-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
ORCID
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nikolaichuk-rats-tap-00
Remote ATtestation ProcedureS (RATS) S. Nikolaichuk
Internet-Draft Independent
Intended status: Informational 28 August 2026
Expires: 1 March 2027
Trusted Artifact Provenance (TAP): A Producer, Verifier, and Sealer
Contract for Attestation-Gated Reconstruction of Stateful Assets
draft-nikolaichuk-rats-tap-00
Abstract
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.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-nikolaichuk-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/.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Nikolaichuk Expires 1 March 2027 [Page 1]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relationship to the RATS Architecture . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.4. Intellectual Property Notice . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Terms Imported from RFC 9334 . . . . . . . . . . . . . . 6
2.2. Terms Defined by This Document . . . . . . . . . . . . . 6
2.3. A Note on the Name "Verifier" . . . . . . . . . . . . . . 7
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Mapping to RFC 9334 Roles . . . . . . . . . . . . . . . . 9
3.3. Topological Patterns . . . . . . . . . . . . . . . . . . 9
3.4. What TAP Adds . . . . . . . . . . . . . . . . . . . . . . 10
4. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Provenance Record . . . . . . . . . . . . . . . . . . . . 10
4.2. Attestation Results Reference . . . . . . . . . . . . . . 11
4.3. Release Record . . . . . . . . . . . . . . . . . . . . . 12
4.4. Release Log . . . . . . . . . . . . . . . . . . . . . . . 14
5. The Producer Contract . . . . . . . . . . . . . . . . . . . . 14
Nikolaichuk Expires 1 March 2027 [Page 2]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
6. The Sealer Contract . . . . . . . . . . . . . . . . . . . . . 15
6.1. Release Procedure . . . . . . . . . . . . . . . . . . . . 15
6.2. Scope of a Release . . . . . . . . . . . . . . . . . . . 16
7. The TAP Verifier Contract . . . . . . . . . . . . . . . . . . 16
8. Freshness and Replay . . . . . . . . . . . . . . . . . . . . 17
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. What Has Been Demonstrated on Hardware . . . . . . . . . 19
9.3. What Has NOT Been Demonstrated . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . 21
10.2. Replay and Freshness . . . . . . . . . . . . . . . . . . 21
10.3. Debug-Mode and Unmeasured Environments . . . . . . . . . 22
10.4. Channel Binding . . . . . . . . . . . . . . . . . . . . 23
10.5. Compromise of the Release Log . . . . . . . . . . . . . 23
10.6. Sealed Material and Key Lifetime . . . . . . . . . . . . 23
10.7. Reconstruction Fidelity Is Not a Security Property . . . 23
10.8. Error Handling and Side Channels . . . . . . . . . . . . 24
10.9. Denial of Service . . . . . . . . . . . . . . . . . . . 24
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Concrete TEE Binding Considerations . . . . . . . . 29
A.1. AWS Nitro Enclaves . . . . . . . . . . . . . . . . . . . 29
A.2. AMD SEV-SNP . . . . . . . . . . . . . . . . . . . . . . . 29
A.3. Intel SGX (DCAP and Azure Attestation) . . . . . . . . . 30
A.4. Software Simulator . . . . . . . . . . . . . . . . . . . 30
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 30
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. 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. [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]
Nikolaichuk Expires 1 March 2027 [Page 3]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
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:
1. What is the object that gets released, and what is it bound to?
2. What inputs MUST a release decision consider, beyond the
Attestation Results themselves?
3. 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.
1.1. Relationship to the RATS Architecture
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.
Nikolaichuk Expires 1 March 2027 [Page 4]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
* 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.
1.2. 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
Section 10.7.
Nikolaichuk Expires 1 March 2027 [Page 5]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.4. 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.
2. Terminology
2.1. Terms Imported from RFC 9334
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.
2.2. 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.
Nikolaichuk Expires 1 March 2027 [Page 6]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
Producing Environment: The environment in which an Artifact is
sealed. It contains an Attesting Environment and is an Attester
in the sense of [RFC9334].
Reconstruction Environment: The environment in which a Sealed
Artifact is decrypted and the Artifact is reassembled. It is an
Attester in the sense of [RFC9334].
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 (Section 5).
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 [RFC9334].
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 [RFC9334], 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 (Section 4.3).
Release Log: An append-only log to which Release Records are
committed (Section 4.4).
2.3. 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 [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";
Nikolaichuk Expires 1 March 2027 [Page 7]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
* 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.
3. Architecture
3.1. Overview
Producing Environment Reconstruction Environment
(RATS Attester) (RATS Attester)
+----------------------+ +--------------------------+
| Artifact | | Reconstruction Process |
| | | | ^ |
| v Producer | | | DEKs |
| Seal + Provenance | | | |
+----------|-----------+ +----|---------------|------+
| | |
| Sealed Artifact | | Evidence
v | v
+----------------------+ | +-------------+
| Untrusted storage |---- ciphertext -------+ | Verifier |
+----------------------+ | | (RFC 9334) |
| +------|------+
| |
| v
+------|--------------------+
| Sealer (Relying Party) |
| appraise Attestation |
| Results; decide; release |
+------------|--------------+
| Release Record
v
+---------------------------+
| Release Log (append-only) |
+------------|--------------+
|
v
+---------------------------+
| TAP Verifier (audit) |
+---------------------------+
Figure 1: TAP entities and their relationship to RFC 9334 roles
Nikolaichuk Expires 1 March 2027 [Page 8]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
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.
3.2. Mapping to RFC 9334 Roles
+================+=====================+======================+
| TAP entity | RFC 9334 role | Conceptual message |
| | | it handles |
+================+=====================+======================+
| Producing | Attester | produces Evidence |
| Environment | | |
+----------------+---------------------+----------------------+
| Reconstruction | Attester | produces Evidence |
| Environment | | |
+----------------+---------------------+----------------------+
| Sealer | Relying Party | consumes Attestation |
| | | Results |
+----------------+---------------------+----------------------+
| TAP Verifier | Relying Party | consumes Attestation |
| | | Results (historical) |
+----------------+---------------------+----------------------+
| (not defined | Verifier | Evidence to |
| here) | | Attestation Results |
+----------------+---------------------+----------------------+
| (not defined | Endorser, Reference | Endorsements, |
| here) | Value Provider | Reference Values |
+----------------+---------------------+----------------------+
Table 1: TAP entities mapped onto RFC 9334 roles
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).
3.3. Topological Patterns
TAP is compatible with both patterns of [RFC9334] 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 Section 9.
Nikolaichuk Expires 1 March 2027 [Page 9]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
Passport Model: 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.
3.4. What TAP Adds
Relative to [RFC9334], TAP adds exactly two things:
1. *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.
2. *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.
4. Objects
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
4.1. Provenance Record
A Provenance Record binds an Artifact to the attested identity of the
environment that sealed it.
Nikolaichuk Expires 1 March 2027 [Page 10]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
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).
4.2. Attestation Results Reference
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.
Nikolaichuk Expires 1 March 2027 [Page 11]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
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.
4.3. Release Record
Nikolaichuk Expires 1 March 2027 [Page 12]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
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.
Nikolaichuk Expires 1 March 2027 [Page 13]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
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.
4.4. 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 [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.
5. The Producer Contract
A Producer MUST:
1. 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.
2. 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.
3. 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.
4. 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.
Nikolaichuk Expires 1 March 2027 [Page 14]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
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.
6. The Sealer Contract
6.1. 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:
1. *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.
2. *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.
3. *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.
4. *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.
5. *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.
6. *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.
Nikolaichuk Expires 1 March 2027 [Page 15]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
7. *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.
8. *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.
6.2. 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.
7. 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:
1. 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.
Nikolaichuk Expires 1 March 2027 [Page 16]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
2. Verify the chunk digests in the Provenance Record against the
Sealed Artifact bytes.
3. Verify each Release Record signature.
4. Verify each Release Record's log-inclusion proof against the
Release Log's published root.
5. 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.
8. Freshness and Replay
[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.
Nikolaichuk Expires 1 March 2027 [Page 17]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
[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.
9. Implementation Status
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.
9.1. 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 Section 8 are implemented in the contract but are
not exercised by the captured corpus; see Section 10.2.
Licensing: Apache-2.0 relicensing is in progress. The repository is
not public at the time of writing.
Contact: The author.
Nikolaichuk Expires 1 March 2027 [Page 18]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
9.2. What Has Been Demonstrated on Hardware
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 | Distinct hardware | Identity |
| | | file hashes | identities | field |
+===========+=======+=============+===================+===========+
| AWS Nitro | 12 | 8 | 8 | Nitro |
| Enclaves | | | | Security |
| | | | | Module id |
+-----------+-------+-------------+-------------------+-----------+
| AMD SEV- | 10 | 8 | 4 | AMD-SP |
| SNP | | | | CHIP_ID |
+-----------+-------+-------------+-------------------+-----------+
| Azure SGX | 4 | 4 | 1 | SGX |
| / MAA | | | | MRENCLAVE |
+-----------+-------+-------------+-------------------+-----------+
| *Total* | *26* | *20* | *13* | |
+-----------+-------+-------------+-------------------+-----------+
Table 2: Attestation artifact corpus composition
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.
9.3. 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
Nikolaichuk Expires 1 March 2027 [Page 19]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
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.
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 Section 10.3.
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 Section 10.7.
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 Appendix A.
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
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.
10. Security Considerations
Nikolaichuk Expires 1 March 2027 [Page 20]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
10.1. 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.
10.2. Replay and Freshness
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.
Nikolaichuk Expires 1 March 2027 [Page 21]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
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.
10.3. 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 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.
Nikolaichuk Expires 1 March 2027 [Page 22]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
10.4. Channel Binding
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.
10.5. 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 [RFC9943]. A TAP Verifier SHOULD report whether
the inclusion proofs it checked were validated against a witnessed
root or an operator-asserted one.
10.6. 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.
10.7. 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.
Nikolaichuk Expires 1 March 2027 [Page 23]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
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.
10.8. 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.
10.9. 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.
11. Privacy Considerations
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.
Nikolaichuk Expires 1 March 2027 [Page 24]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
* 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.
12. IANA Considerations
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.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/rfc/rfc5116>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/rfc/rfc6962>.
Nikolaichuk Expires 1 March 2027 [Page 25]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/rfc/rfc9711>.
13.2. Informative References
[AMD-SEVSNP]
Advanced Micro Devices, Inc., "SEV Secure Nested Paging
Firmware ABI Specification, Publication 56860", 2026,
<https://www.amd.com/system/files/TechDocs/56860.pdf>.
Nikolaichuk Expires 1 March 2027 [Page 26]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
[AWS-NITRO]
Amazon Web Services, "AWS Nitro Enclaves attestation
document specification", 2026,
<https://docs.aws.amazon.com/enclaves/latest/user/verify-
root.html>.
[AZURE-MAA]
Microsoft Corporation, "Microsoft Azure Attestation",
2026, <https://learn.microsoft.com/en-
us/azure/attestation/overview>.
[I-D.ietf-rats-ar4si]
Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
Scarlata, "Attestation Results for Secure Interactions",
Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
10, 18 May 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-ar4si-10>.
[I-D.ietf-rats-corim]
Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
W. Pan, "Concise Reference Integrity Manifest", Work in
Progress, Internet-Draft, draft-ietf-rats-corim-11, 6 July
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
rats-corim-11>.
[I-D.ietf-rats-daa]
Birkholz, H., Newton, C., Chen, L., Giannetsos, T., and D.
Thaler, "Direct Anonymous Attestation for the Remote
Attestation Procedures Architecture", Work in Progress,
Internet-Draft, draft-ietf-rats-daa-09, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
daa-09>.
[I-D.ietf-rats-ear]
Fossati, T., Voit, E., Trofimov, S., and H. Birkholz, "EAT
Attestation Results", Work in Progress, Internet-Draft,
draft-ietf-rats-ear-04, 26 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
ear-04>.
[I-D.ietf-rats-endorsements]
Thaler, D., Birkholz, H., and T. Fossati, "RATS
Endorsements", Work in Progress, Internet-Draft, draft-
ietf-rats-endorsements-09, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
endorsements-09>.
Nikolaichuk Expires 1 March 2027 [Page 27]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
[I-D.ietf-rats-epoch-markers]
Birkholz, H., Fossati, T., Pan, W., Mihalcea, I., and C.
Bormann, "Epoch Markers", Work in Progress, Internet-
Draft, draft-ietf-rats-epoch-markers-05, 3 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
epoch-markers-05>.
[I-D.ietf-rats-reference-interaction-models]
Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference
Interaction Models for Remote Attestation Procedures",
Work in Progress, Internet-Draft, draft-ietf-rats-
reference-interaction-models-17, 2 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
reference-interaction-models-17>.
[I-D.ietf-scitt-scrapi]
Birkholz, H., Geater, J., and A. Delignat-Lavaud, "Supply
Chain Integrity, Transparency, and Trust (SCITT) Reference
APIs", Work in Progress, Internet-Draft, draft-ietf-scitt-
scrapi-11, 26 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-scitt-
scrapi-11>.
[INTEL-DCAP]
Intel Corporation, "Intel Software Guard Extensions (Intel
SGX) Data Center Attestation Primitives: ECDSA Quote
Library API", 2026, <https://download.01.org/intel-
sgx/latest/dcap-latest/linux/docs/>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.
[RFC9782] Lundblade, L., Birkholz, H., and T. Fossati, "Entity
Attestation Token (EAT) Media Types", RFC 9782,
DOI 10.17487/RFC9782, May 2025,
<https://www.rfc-editor.org/rfc/rfc9782>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
Nikolaichuk Expires 1 March 2027 [Page 28]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
[RFC9999] Birkholz, H., Smith, N., Fossati, T., and H. Tschofenig,
"Remote ATtestation procedureS (RATS) Conceptual Message
Wrapper (CMW)", RFC 9999, DOI 10.17487/RFC9999, July 2026,
<https://www.rfc-editor.org/rfc/rfc9999>.
[TAP-CORPUS]
Nikolaichuk, S., "Cross-TEE Attestation Corpus (docs/
CORPUS.md and evidence/MANIFEST.json)", Machine-generated
manifest of hardware-signed attestation artifacts. Not yet
publicly available; see Section 9., 2026.
Appendix A. Concrete TEE Binding Considerations
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.
A.1. AWS Nitro Enclaves
* 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.
A.2. AMD SEV-SNP
* Evidence: SEV-SNP attestation report [AMD-SEVSNP].
* Measurement: the launch MEASUREMENT field.
Nikolaichuk Expires 1 March 2027 [Page 29]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
* 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.
A.3. Intel SGX (DCAP and Azure Attestation)
* 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.4. Software Simulator
* 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.
Appendix B. Open Issues
These are stated for working group input and are expected to change.
1. *Naming.* The TAP role called "TAP Verifier" collides with the
[RFC9334] Verifier and should probably be renamed. See
Section 2.3.
Nikolaichuk Expires 1 March 2027 [Page 30]
Internet-Draft Trusted Artifact Provenance (TAP) August 2026
2. *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.
3. *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.
4. *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.
5. *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.
6. *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.
Author's Address
Serhii Nikolaichuk
Independent
Austin, TX
United States of America
Email: nikolaichuk.s.f@gmail.com
Nikolaichuk Expires 1 March 2027 [Page 31]