Secure Evidence and Attestation Transport (SEAT) Architecture

Secure Evidence and Attestation Transport (SEAT) Architecture Independent

ietf@nritz.com

NVIDIA

tfossati@nvidia.com

Nokia

kondtir@gmail.com

Arm

ionut.mihalcea@arm.com

Inria

yuxuan.song@inria.fr

remote attestation TLS confidential computing transport security This document defines an architectural framework for composing Remote ATtestation procedureS (RATS) with Secure Evidence and Attestation Transport (SEAT). The document establishes normalized terminology for SEAT, aligns RATS roles to transport endpoints, outlines topological patterns for attestation delivery timing, and characterizes the abstract cryptographic pattern by which Evidence is bound to a given transport connection. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction

Establishing Trust in Secure Communications

"Cryptography without system integrity is like investing in an armored car to carry money between a customer living in a cardboard box and a person doing business on a park bench." — Gene Spafford

Traditional secure channel protocols, such as those based on authenticated key exchange (AKE), primarily establish trust in a peer's cryptographic identity. This is typically achieved through mechanisms like Public Key Infrastructure (PKI), where a trusted Certification Authority (CA) vouches for the binding between a public key and an identifier such as a hostname (e.g., ). However, this model has a core limitation: identity authentication provides no assurance about the peer's internal state or the integrity of its software stack. A compromised server, for instance, can still present a valid X.509 certificate and be considered "trusted" by a client. This gap allows compromised endpoints to maintain network access and the trust of their peers, posing a significant security risk in many environments.

The Role of Remote Attestation Remote Attestation (RA), as described in the RATS architecture , is a mechanism designed to fill this gap. RA allows an entity (the "Attester") to produce verifiable "Evidence" about its current runtime state. This Evidence covers the Attester's security state, and can thus include measurements of its firmware, operating system, application code, as well as the configuration of its hardware and software security features (e.g., secure boot status, memory isolation). A "Relying Party" can then use this Evidence, often with the help of a trusted "Verifier", to appraise the Attester's trustworthiness.

Purpose and Scope By integrating RA into a secure channel establishment protocol, a second dimension of trust is added to complement regular peer authentication: trustworthiness. This allows a Relying Party to make authorization decisions based not just on the Attester's cryptographic identity, but also on what its security capabilities are (e.g., whether it is a Confidential Computing-capable server) and whether its security state is acceptable. This document is intended as an input to the design of protocol solutions within the SEAT working group. One primary goal is to define operational considerations that remain agnostic to any specific attestation technology (e.g., Trusted Platform Modules (TPMs), Intel TDX, AMD SEV, Arm CCA, etc.). For the scope of this architecture, the term "transport" is used interchangeably with "secure transport" to refer to secure channel establishment protocols such as TLS and LAKE .

Use Cases The use cases motivating this architecture are defined in . Readers are directed there to review the security property goals and various deployment scenarios that the protocol work in the SEAT working group is expected to satisfy.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used in this document. Terms defined in are used with the meanings established there; the definitions below extend or specialize those terms for the transport context. This document adopts terms of art such as intra- and post- as coined by .

Transport Signing Key (TSK):: An asymmetric key pair whose private key is used to authenticate the Attester’s transport endpoint (for example, signing the TLS CertificateVerify message). Evidence produced by the Attesting Environment MUST include a binding to the TSK. It is RECOMMENDED that the TSK be generated and maintained exclusively within the Target Environment (e.g., a TEE).
Attesting Environment Key (AEK):: The asymmetric key used by the Attesting Environment to sign Evidence. The Verifier trusts the AEK through an Endorsement chain that typically roots in a hardware manufacturer or a device‑specific CA. The AEK is used solely for attestation and is distinct from any key used for transport authentication.
Attestation Result Key (ARK):: The asymmetric key used by a Verifier to sign Attestation Results. The Relying Party must possess the corresponding trust anchor for the ARK so that it can verify the integrity and authenticity of received Attestation Results.
Authenticated Identity ("identity"):: The identity of a peer as established by the secure channel establishment protocol's authentication (for example, TLS handshake authentication, see ). I.e., a name cryptographically bound to the key or credential the peer authenticates with (for example, a certificate subject as in ).

How authenticated identity and those credentials are issued is outside the scope of this document. For some additional discussion of adjacent work related to RA and identity, see .

Attestation Credential:: The attestation payload conveyed by the Attester to the Relying Party across the transport connection. Depending on the RATS conveyance model in use, this payload consists of either Evidence (Background-Check Model) or an Attestation Result (Passport Model). Where a statement applies specifically to one but not the other, this document uses the more specific term.

While Evidence is exclusively generated by the Attester and Attestation Results are generated by a Verifier, in the SEAT transport context, the Attestation Credential is always presented by the Attester directly to the Relying Party over the secure channel.

Attested Channel:: A transport session in which at least one endpoint has produced Evidence that has been appraised, and in which that Evidence is cryptographically bound to the session such that the appraisal cannot be replayed to a different session or transferred to a different endpoint.
Attestation Timing Model:: The temporal relationship between Evidence conveyance and connection establishment time. This document defines two timing models: Intra-Handshake Attestation and Post- Handshake Attestation. See .
Evidence Generation Time:: The point at which an Attester's Claims are signed to produce Evidence. Depending on the internal workings of the Attester, the Evidence reflects the reported state at the time the underlying Claims were collected and may not represent a snapshot of state at the exact moment of signing the evidence. In all cases, it makes no representation about the Attester's state at any later time.
Connection Establishment Time:: The point at which a transport handshake completes and the session becomes usable for application data exchange.
Lifetime of Connection:: The period from Connection Establishment Time until the session is torn down. Post-handshake re- attestation operates during the Lifetime of Connection, allowing Evidence to reflect the Attester's current state rather than its state at Connection Establishment Time.
Re-attestation:: The production and appraisal of fresh Evidence during an established session's Lifetime of Connection.
Intra-Handshake Window:: The interval during transport connection establishment in which Evidence is conveyed within the handshake messages themselves, prior to the transition to application data exchange.
Post-Handshake Window:: The interval following connection establishment in which Evidence is conveyed to the Relying Party using post-handshake protocol mechanisms (e.g., Exported Authenticators or application-layer exchanges).
Session Binding Value:: A value, uniquely determined by a specific transport session, from which Attestation Binders are derived. A Session Binding Value may be public or secret depending on the topology; what is required is that it cannot be known before the session is initiated. See .
Attestation Binder:: A cryptographic value derived from a Session Binding Value and committed to by the Attesting Environment into its Evidence payload. This value binds the Evidence to a specific session guaranteed under typical cryptographic assumptions.
Transmission Anchor:: The point in the protocol at which an Attestation Binder is included in a protocol message. A binder may be computed and transmitted before peer authentication is complete.
Verification Anchor:: The protocol mechanism by which the integrity of a transmitted Attestation Binder is established. Depending on the Attestation Timing Model, this may be achieved via a MAC that authenticates the handshake transcript (e.g., the TLS Finished message), or through post-handshake cryptographic binding (e.g., Exported Authenticators).
Split Deployment:: A deployment topology in which the Attesting Environment and the transport stack reside in different execution contexts (vertical seperation). The transport stack is in the Target Environment; the Attesting Environment (e.g., a TEE) must receive the attestation binder input — typically a handshake transcript hash or exported key — from the transport stack via a trusted interface.
Multi-Endpoint Deployment:: A deployment topology in which multiple distinct transport endpoints reside within the same Target Environment (horizontal separation). An attestation endpoint manages attestation exchanges, while one or more separate serving endpoints terminate application data channels.

TODO: Explore security outcomes and operational considerations for proposed Multi-Endpoint Deployment topologies.

Roles and Entities The SEAT architecture maps the roles defined in to standard transport protocol entities. The subsections below describe each role and its specific character in the transport context. The overarching goal for SEAT is to establish an attested channel between an Attester and a Relying Party (or between two endpoints acting mutually in both roles). shows the transport and RATS roles that are involved in achieving this goal, and how they interact.

Attested Secure Channel | Relying Party | | | | Environment | | ^ | '-------------' | | | [AEK] | | | | | | '-^-----------' | | | | | | Collect | | Attest'n | | | | Claims | | Binder | | | .-+-----------. | | | | | | .---------. | | | | .---------. | | | | Transport | | | | | | Transport | | | | | peer |<+--+----------+-----------+--->| peer | | | | '---------' | | Secure Channel | '---------' | | | [TSK] | | | | | | | | | | | | Target | | | | | | Environment | | | | | '-------------' | | | '---------------------' '---------------------' ]]>

Attester The Attester produces Evidence about its current state for consumption by a Verifier. In the transport context, the Attester is a network endpoint — either the Client or the Server — that possesses an Attesting Environment (such as a Trusted Execution Environment) capable of securely collecting Claims and signing them with an attestation key. The Attester's transport stack provides the attestation binder input to the Attesting Environment so that Evidence can be bound to the specific session. In a Split Deployment, the transport stack is in the Target Environment and the interface between the transport stack and the Attesting Environment is a security-critical boundary. See . In mutual attestation deployments, both the Client and the Server simultaneously act as Attesters. Each endpoint's Attesting Environment independently generates Evidence bound to the session.

Relying Party The Relying Party consumes an Attestation Result and uses it to make authorization decisions about the transport connection. In the transport context, the Relying Party is typically the endpoint opposite the Attester — the Server when the Client attests, or the Client when the Server attests.

Verifier The Verifier appraises the validity of Evidence and produces Attestation Results, as defined in . The appraisal is driven by an Appraisal Policy for Evidence, a set of rules that determines which Endorsements and Reference Values are required, which Claims must be present, and under what conditions Evidence is considered acceptable. The Appraisal Policy may be configured as part of the Verifier’s trust anchors or supplied by a Relying Party in a deployment-specific manner. When Attestation Results are produced, they reflect the outcome of applying that policy.

The Interface Between RATS and SEAT Integrating Remote Attestation with secure transport requires a clean separation of concerns between transport state and platform appraisal. The transport protocol maintains channel confidentiality, message integrity, and session uniqueness, but remains agnostic to internal platform measurement formats (see ). Conversely, the RATS layer collects and appraises Evidence, relying on the transport layer to anchor that appraisal to a specific connection (see ).

Composite Trust Anchors An Attested Channel requires the Relying Party to evaluate orthogonal dimensions of trust, each rooting in a distinct cryptographic anchor:

The Transport Anchor (Identity): The trust anchor (typically a WebPKI or enterprise CA) that vouches for the binding between the peer's Authenticated Identity and its Transport Signing Key (TSK).
The Attestation Anchor (Posture): The trust anchor (typically a hardware manufacturer root, device-specific CA, or configured Verifier key) that vouches for the integrity of the Attesting Environment and its Attesting Environment Key (AEK).

Such anchors operate independently. For example, a CA issuing the transport certificate is generally unaware of the platform's hardware state, and the hardware manufacturer issuing the attestation endorsement is unaware of the application-level identity the platform is hosting.

Transport-to-Attestation Invocation When attestation is negotiated, the transport stack supplies two inputs across the boundary to the Attesting Environment: a session-unique Session Binding Value and the public component of the Transport Signing Key (TSK) (see and ). The Attesting Environment commits both parameters into its Evidence payload. This asserts that the attested execution state is bound to the endpoint controlling TSK on that active session.

Conveyance Models illustrates how Evidence and Attestation Results flow under the two conveyance models.

RATS Conveyance Models in the Transport Context | Relying Party |---------->| Verifier | | | | |<----------| | +----------+ +---------------+ Att.Res. +----------+ Passport Model (the Attester conveys Evidence to the Verifier and presents the resulting Attestation Results to the Relying Party) +----------+ Evidence +----------+ | Attester |---------->| Verifier | | |<----------| | +----------+ Att.Res. +----------+ | | Attestation Results v +---------------+ | Relying Party | +---------------+ ]]> How Evidence reaches the Verifier follows one of the two RATS conveyance models ():

Background-Check Model:: The Relying Party conveys the Attester's Evidence to the Verifier and receives Attestation Results in return. The Verifier may be co-located with the Relying Party, appraising Evidence inline, for example during an intra-handshake exchange that requires a real-time result before the connection is finalized or operated as a remote service (see and ).
Passport Model:: The Attester conveys its Evidence to a remote Verifier, obtains Attestation Results, and presents those Results to the Relying Party (see and ).

Fail-Closed Binding Semantics A transport session achieves the status of an Attested Channel only when the cryptographic binder is evaluated as a strict, non-optional invariant by the appraisal engine (see ). Appraisal interfaces must not treat session challenges as optional filters. If a verification interface permits an empty, null, or zero-length session challenge to proceed without failure, or if an unconfigured Verifier evaluates platform state and signatures while skipping the equality assertion against session context, the channel binding guarantee fails silently. Under such conditions, the system evaluates platform execution state in the abstract, but fails to prove that the platform is attached to the live communication session. To preserve the integrity of an Attested Channel, appraisal implementations must enforce fail-closed semantics (see ):

Mandatory Challenge Presence: The appraisal engine must treat the presence of a non-empty, well-formed Session Binding Value as a prerequisite for successful verification (see ).
Complete Parameter Matching: The comparison between the connection-derived binder and the value committed within the Attestation Credential must be evaluated as a strict equality check.
Terminal Abort: If an incoming credential omits the binder, presents an unparseable challenge structure, or fails the equality comparison, the appraisal engine must report a terminal verification failure, prompting the transport layer to terminate the session (see ).

RATS Trust Model This section describes the trust relationships required to establish an Attested Channel. The general trust model described in applies; the subsections below specialise it for the transport context.

Target Environment Trust and Key Provenance TODO: Explore security outcomes and options when using a non-confidential TSK as seen discussed in this open SEAT use case proposal (see ). In the transport context, establishing an Attested Channel requires demonstrating key provenance: proving that the private Transport Signing Key (TSK) used for channel authentication is physically confined within an authorized Target Environment. This relies on an unbroken chain of trust spanning the platform supply chain to the active transport session:

Target Environment Trust and Key Provenance Because the TSK (rooted in the Transport Anchor) and the AEK (rooted in the Attestation Anchor) originate in orthogonal trust domains, committing to the TSK within signed Evidence cryptographically binds them. This assures the Verifier and Relying Party that the transport identity is not merely valid, but physically resident within the attested Target Environment.

Verifier Trust and Appraisal Policy The Relying Party must have a trust relationship with the Verifier commensurate with the sensitivity of the authorization decision. This reliance requires the Relying Party to trust both the Verifier's cryptographic signature and the Verifier's Appraisal Policy. In the co-located Verifier deployment, this relationship is implicit: the Verifier's logic is part of the Relying Party's own implementation. In the remote Verifier deployment, the Relying Party must authenticate the Verifier and confirm that the Verifier's Appraisal Policy for Evidence is consistent with the Relying Party's own requirements before accepting any Attestation Credentials.

Compound Trust and Cross-Domain Authorization The defining characteristic of the SEAT trust model is compound authorization. Trusting the transport identity does not imply trusting the execution environment, and verifying the execution environment does not authorize the transport identity for a given service.

Relying Party Trust The Relying Party evaluates both trust domains jointly. It validates the TSK against its Transport Anchor to confirm the peer's identity (for example, by verifying the reference identifier per ), evaluates the Attestation Credential against its Attestation Anchor to confirm platform integrity and TSK residency, and verifies the session binder to confirm they are co-located. This binder confirms that the Attestation Credential is bound to the current session — ensuring it has not been replayed from a different session or transferred from a different endpoint. This assurance is provided by the session binding mechanism described in ; the check may be performed by the Relying Party itself or delegated to the Verifier, but it cannot be pre-computed independently of the session. Only when all elements satisfy their respective trust anchors does the session achieve the status of an Attested Channel.

Timing Models The timing and conveyance of Attestation Credentials relative to the transport handshake define the two Attestation Timing Models used in this architecture. Depending on the approach, an Attestation Credential may be conveyed during the Intra-Handshake Window or during the Post-Handshake Window, utilizing either native transport protocol extensions or application-level framing. If the credential is Evidence, the Relying Party acts as or forwards it to a Verifier to appraise the Evidence. If the credential is an Attestation Result, the Relying Party evaluates it against its own Appraisal Policy for Attestation Results. In both cases, an authorization decision must be made before the transport state machine permits application data to flow.

Intra-Handshake Attestation An Attestation Credential is conveyed by the Attester during the transport connection establishment to the Relying Party within the handshake messages themselves, prior to the transition to application data exchange. Upon receipt, the Relying Party processes the Attestation Credential. The Relying Party, which may be deployed with a co-located Verifier, appraises the Evidence in real time and makes an authorization decision before the transport state machine permits application data to flow.

Post-Handshake Attestation An Attestation Credential is conveyed by the Attester after transport connection establishment to the Relying Party. Conveyance may occur within the transport layer using post-handshake protocol mechanisms utilizing either native transport protocol extensions or above the transport layer within application protocols. The Attestation Binder is derived after initial handshake completion, tying the Attestation Credential to the established session context. Regardless of whether post-handshake conveyance is implemented directly within the transport stack or localized in an application-level wrapper (such as a sidecar proxy), authorization policies must dictate which data exchanges are required to stall until the attestation procedure completes successfully.

Combining Timing Models Protocol specifications building on this architecture MAY support one or both timing models. When designing solutions, it is important to distinguish the timing model used for conveyance (Intra-Handshake vs. Post-Handshake) from the lifecycle event being satisfied (initial trust establishment vs. re-attestation). Initial attestation can be performed using either timing model: Intra-Handshake mechanisms can establish baseline trust during connection setup, or Post-Handshake mechanisms can be used to withhold application data exchange immediately after connection establishment. Re-attestation, by definition, occurs during the Lifetime of Connection. A comprehensive solution might combine both models — using Intra-Handshake for initial trust and Post-Handshake for re-attestation — or it might rely entirely on Post-Handshake mechanisms to handle both initial session trust and ongoing periodic re-attestation.

Operational Considerations This document introduces several operational and manageability considerations for deploying attested secure channels.

Protocol Scope and Operational Trust Boundaries Designing and evaluating an attested transport protocol requires a precise distinction between the cryptographic guarantees provided by the transport design and the operational assumptions required of the surrounding deployment. The SEAT protocol layer provides channel and key binding:

Deriving a Session Binding Value that commits to two-sided session randomness (see ).
Binding the Transport Signing Key (TSK) to the attested execution environment, evaluated at appraisal time (see ).
Injecting the Session Binding Value into the attestation challenge (see ).
Ensuring that Evidence presented on one transport session cannot be relayed or replayed on a different session (see ).

Under its stated cryptographic assumptions, SEAT guarantees session co-presence: the entity completing transport authentication is the entity possessing the attested platform state. However, the overall security of an attested connection depends on operational and appraisal layers that sit outside the transport protocol. Failures at these external layers result in operational breakdowns in prerequisite trust domains:

Appraisal Engine Mechanics: If an appraisal library contains implementation flaws - such as permitting an empty, null, or uninspected challenge parameter to bypass verification. (see ).
Policy Specification: If an operator configures an appraisal policy that accepts unmeasured container images, outdated firmware, or loose software digests, the verifier will faithfully certify an unapproved workload (see and ).
Destination Identity Validation: Transport binding proves that an enclave is present, not that it is the destination the client intended to reach. If a relying party validates a genuine hardware quote but omits matching the peer's presented identity against the intended reference identity (see , the connection is vulnerable to diversion attacks.

Protocol Attack Vectors Protocol designers, implementers, operators, and users must consider the specific security goals and requirements for any given deployment and understand the corresponding attacker models that may apply, such as the potential threat and impact of network attackers or malicious peers. See to review these considerations and their remedies. For an architectural overview of additional security-related concerns for attested transport channels, see .

Operational Challenges Under the Background-Check Model Deploying SEAT protocols requires resolving a core topological trade-off between the Background-Check and Passport conveyance models (see ). While protocol mechanisms determine how messages are framed on the wire, the operational profile of the transport channel is governed by where and when Evidence is appraised. For short-lived or latency-sensitive connections, the Passport model can minimize setup latency by allowing local evaluation of pre-appraised credentials during channel establishment. For persistent, long-lived connections, periodic re-attestation over the established Attested Channel accommodates dynamic platform evolution; the conveyance model determines whether the appraisal is synchronous (Background Check) or asynchronous (Passport). The conveyance models differ in where Evidence is disclosed and when appraisal occurs (see ); both require withholding application data until the initial appraisal completes (see ). This section outlines a number of operational challenges that operators and implementers of SEAT protocols may encounter when deploying the Background-Check conveyance model.

Hardware Information Disclosure Conveying raw Evidence directly to the Relying Party may expose granular hardware topology, silicon identity keys, and platform patch state to the peer. Protecting this sensitive platform state requires due care to avoid unnecessary information disclosure (see ). By contrast, the Passport model discloses raw measurements exclusively to an authorized Verifier out-of-band. This may make it operationally simpler to present a minimized Attestation Result that asserts policy conformance without disclosing underlying hardware metrics. Where the Background-Check model is used, implementations may mitigate exposure by decoupling static platform endorsements from ephemeral session binders, or by evaluating manufacturer PKIs out-of-band.

Bounded Credential Lifecycles Attestation Evidence reflects a point-in-time observation of platform state, which can introduce an operational Time-of-Check to Time-of-Use (TOCTOU) gap over long-running connections (see ). While platform-enforced hardware latches protect boot-time state, assurances regarding unlatched software components may drift as execution continues. In the Passport model, freshness is governed by explicit validity windows; however, tight lifetimes risk mid-session expiration while longer lifetimes increase exposure to unobserved state changes. Deployments can address this tension by isolating long-lived baseline manifests from lightweight session-binding proofs.

Runtime State Drift Adapting to runtime state evolution or appraisal context drift can be addressed via periodic re-attestation (see ). In the Background-Check model, executing continuous appraisal directly over the active Attested Channel incurs synchronous round trips to an available Verifier, introducing potential for pipeline stalls or transport timeouts. Under the Passport model, re-attestation occurs asynchronously out-of-band: the Attester fetches an updated Attestation Result and ingests it via standard transport mechanisms without blocking channel execution. Where continuous background checks are necessary, separating target state monitoring from asynchronous context drift tracking can help reduce active channel friction.

Handshake Latency and Network Reliability In the Background-Check model, the Relying Party must withhold application data while performing a synchronous appraisal query to an available Verifier. This verification fan-out latency compounds channel setup delays, which increases communication timeouts in lossy or distributed networks. Furthermore, uncompressed platform Evidence may exceed network Path MTU limits, causing datagram fragmentation and connection aborts. On datagram-based transports packet drops cannot generally be recovered selectively at the transport layer, meaning lost fragments can precipitate full-message retransmissions and session aborts rather than mere latency delays . To mitigate these transport reliability challenges, implementations can evaluate compact proofs (see ) or distribute heavy reference manifests out-of-band to keep on-wire payloads within standard Path MTU limits.

Failure handling

Failure handling within Intra-Handshake Window When remote attestation occurs within the Intra-Handshake Window, the transport handshake withholds progression to application data exchange until the Attestation Result is available: application data exchange has not yet begun. A Verifier rejection, or a Relying Party policy rejection of an otherwise valid Attestation Result, MUST result in a fatal error consistent with the transport protocol's existing handshake-failure handling. It is RECOMMENDED that the failure mode be interpretable by the application as a remote-attestation-related fault. Remote attestation specificity provides greater flexibility to apply application-layer policies, and assists in auditing and general debugging.

Failure handling within Post-Handshake Window Failure handling in the Post-Handshake Window depends on whether the appraisal relates to the initial attestation event or to a subsequent re-attestation. For an initial attestation event using the Post-Handshake model, authorization policies withhold application data exchange until the attestation procedure completes successfully; thus, application data has not yet begun to flow. A failure at this stage prevents the initial authorization to exchange application data. When Re-attestation fails during the Lifetime of Connection, the transport session is already established and application data has already been flowing. allows a failed Attester appraisal to result in reduced access or privileges rather than outright rejection. Depending on whether enforcement is handled by the transport stack or the application, the Appraisal Policy determines whether the underlying transport session is torn down or restricted to an authorized subset of data streams. Failure handling of Re-attestation does not retroactively protect application data already exchanged prior to the failed appraisal; it bounds further exposure going forward.

Session Binding

Attestation Session Binding Regardless of which timing model is used or which transport protocol is in use, a correctly bound attested channel requires that three conditions hold in sequence. The first condition is Session Binding Value establishment. The endpoints must derive or obtain a shared, session-specific Session Binding Value from which Attestation Binders can be derived. The Session Binding Value is bound to the specific session instance by construction, and may be public (for example, a handshake transcript) or secret (for example, an exporter-derived value). The second condition is directional Binder derivation. From the Session Binding Value, the protocol derives distinct Attestation Binders for the initiator and the responder. The binders are directional: the initiator's binder cannot be substituted for the responder's and vice versa. This ensures that Evidence produced by one endpoint cannot satisfy the verification requirement for the opposite endpoint, even within the same session. The third condition is channel binding to an Attestation Credential. The Attesting Environment signs its directional Attestation Binder into its Evidence payload, committing that Evidence to this specific session. For this condition to hold when using the Passport model, the Verifier must propagate this binding into the resulting Attestation Result, ensuring the final Attestation Credential presented to the Relying Party remains committed to the specific transport session. The above conditions aim to mitigate two primary attack vectors:

Replay Across Sessions: Because the Session Binding Value is unique to the session, an Attestation Credential committed to a binder derived from it cannot be presented in a different session. Where the Session Binding Value is secret, only the session participants can derive it. Where it is public, for example, a handshake transcript, its uniqueness follows from the ephemeral keying material that the transport establishes per session, so the transcript, and hence the binder, cannot recur across sessions.
Key Substitution: A valid Attestation Credential produced by a genuine attested execution environment is presented while the TSK (Subject Key) used for authentication was not generated or protected within that environment. Session binding alone does not bind the Subject Key to the attested environment; this is handled at the RATS layer, as discussed under Key Non-exportability in .

The Attestation Credential itself plays a critical role in verifying that these three session binding conditions have been successfully achieved. Beyond the cryptographic inclusion of the Attestation Binder, strict requirements for the internal structure and the application of logical safeguards protecting the Attestation Credential are necessary to provide assurance that the Attestation Credential could not have been generated through alternative means such as side-channel exploits. When all three conditions are met, the channel-binding check may be performed either by the Relying Party itself or by the Verifier. As a session participant, the Relying Party holds the Session Binding Value and can compute the binder locally and MAY send it to the Verifier which compares it with the binder in the Evidence, avoiding the need for the Relying Party to decode the Evidence first. If the Relying Party is directly consuming Evidence (Background-Check model), it rejects Evidence whose binder does not match. If the Relying Party is consuming an Attestation Result (Passport model) and expects per-session freshness (see ), it MUST reject the Attestation Result if it cannot affirmatively evaluate that the Verifier explicitly tied the Attestation Result to the current session's Attestation Binder.

Freshness The freshness of Evidence is critical to its value as a trustworthiness signal. In the transport context, freshness has several distinct scopes that must be addressed separately.

Per-session freshness Per-session freshness ensures that Evidence is bound to the specific session being evaluated and cannot be replayed from a prior session. This property is addressed directly by the session binding mechanism of . The Session Binding Value is specific to the session and cannot be known before the session is initiated, providing nonce-style freshness in the sense of Section 10. Evidence committed to an Attestation Binder derived from the Session Binding Value is therefore intrinsically fresh with respect to the session: a replay from a different session will carry an Attestation Binder derived from a different Session Binding Value, and appraisal will fail.

Session resumption Session resumption introduces a specific freshness consideration. When a transport session is resumed, a previously obtained Attestation Credential may no longer reflect the Attester's current state.

Re-Attestation in Long-Running Sessions Initial attestation at Connection Establishment Time addresses the architectural invariants the Relying Party's policy requires before application data may flow. Re-attestation addresses the dynamic reality that established sessions may outlast the validity of a single trust assessment. Protocol specifications building on this architecture SHOULD treat these as distinct concerns. Per-session freshness ensures Evidence cannot be replayed across sessions but does not address changes in the Attester's state during the Lifetime of Connection, nor does it prevent replay of previously presented Evidence within the same session. Protocol specifications supporting re-attestation must require fresh Evidence generation bound to an updated session challenge (e.g., using Extended Key Update or an epoch-specific transport exporter). A Relying Party MAY require Re-attestation before continuing to transmit sensitive data to a peer whose trust assessment has expired or whose deployment environment may have changed in ways material to its policy. Re-attestation does not retroactively protect data transmitted before a state change occurred. It bounds further exposure by conditioning continued sensitive data transmission on a current trust assessment. Whether to terminate a session upon re-attestation failure or continue with reduced privilege is a matter of Relying Party policy; see .

Attestation Credential Lifecycle Boundaries Remote attestation provides a point-in-time observation of the target platform's security state. Additionally, the point-in-time when the claims representing the Attester's state are collected is also necessarily earlier than when the Evidence is signed. The interval between Claim Collection Time, Evidence Generation Time and subsequent application data exchange introduces a theoretical Time-of-Check to Time-of-Use (TOCTOU) gap (see ). In typical attestation architectures (see exceptions below), this gap is bounded by hardware-and platform-enforced immutability critical sections:

Hardware-Latched State: Sensitive platform state, including secure boot measurements and platform configuration, is cryptographically latched into write-once hardware registers hardware registers that cannot be altered without resetting the platform.
Memory Isolation: Memory encryption and access-control boundaries prevent an untrusted host (as well as peer enclaves) from altering enclave memory during execution.
Durable logs or deferred updates: Critical software updates either require an instance restart that resets the measurement latch, or otherwise provide an append-only log bound to an extend-only measurement latch (such as when live firmware updates are supported by the platform). It must be possible for the Relying Party to assess whether a critical software update can happen without the Attester being terminated.

Point-in-time measurements therefore provide durable security assurances for properties governed by platform immutability latches. Over long-running sessions, operational risk arises from two distinct sources:

Target State Evolution: Internal modifications to the platform's active security state during execution, such as live firmware updates advancing a security version number (SVN) or appending to the firmware activity log.
Appraisal Context Drift: External changes to the evaluation environment independent of the target platform, including endorsement credential revocation, updated reference value manifests (e.g., CoRIM), or revised appraisal policies deprecating previously acceptable states in response to newly disclosed vulnerabilities.

Periodic re-attestation during the connection lifetime addresses both factors by capturing fresh evidence of the target's current operational state and confirming that the established session remains aligned with current appraisal criteria (see ).

Privacy Considerations

Evidence Payload Confidentiality The Evidence payload carries Claims about the Attester's state and is the most privacy-sensitive artifact in the protocol. It is RECOMMENDED that Evidence payloads be encrypted to a key held exclusively by the intended recipient (typically the Verifier), so that the Evidence content is disclosed only to that recipient and not to the Relying Party or to other parties on the path. The complementary control for the Relying Party surface is minimization: the Attestation Results returned to the Relying Party SHOULD NOT re-expose sensitive Claims that were protected in any encrypted Evidence. A framework for consistent handling of sensitive Evidence across RATS roles, including claim classification, Trusted Verifier management, and Attestation Credential minimization, is provided in .

Transport Metadata The transport connection discloses metadata — IP addresses, server name indications, and connection timing — that is visible to passive network observers. This disclosure is inherent to the transport protocol and is not specific to the attestation layer.

Attestation Key Correlation When the same attestation signing key is used across multiple sessions, any party with access to Evidence from more than one of those sessions can correlate the sessions to the same Attesting Environment. This linkability consideration is particularly relevant for client Attesters where privacy of individual connections is a concern.

Anonymous Client Attestation The SEAT architecture supports deployments where a client Attester attests to the trustworthiness of its Attesting Environment without presenting a TLS client identity certificate, enabling anonymous client attestation. In this deployment, the Relying Party's appraisal policy applies to the client's hardware and software state rather than to a disclosed identity.

Scope Boundary and Internet Openness The IAB has issued a statement cautioning that using client attestation as a barrier to access for otherwise open protocols and services risks undermining Internet openness . The statement distinguishes services with intentionally restricted access — for which client attestation is recognized as a valuable security measure — from openly accessible services, for which imposing hardware or software requirements on participating implementations is inappropriate. SEAT is scoped to the former category: the use cases motivating this work involve confidential workloads, enterprise-controlled environments, and TEE-backed services where access is explicitly conditioned on verified platform state. The IAB statement further identifies the disclosure of vendor- specific hardware and software information as a distinct risk: attestation evidence that reveals which specific implementations are in use can restrict access and enable tracking in ways that undermine the open internet. Protocol designs building on this architecture should minimize vendor-specific claim disclosure consistent with the Attestation Credential minimization controls described in this section and in .

Security Considerations This section enumerates the security properties and considerations of the SEAT architecture. Security goals state outcomes the architecture is designed to achieve; they carry no normative mandates. Security properties state technical characteristics the protocol is expected to exhibit and may carry normative requirements. Implementations MUST also consider the Security Considerations of and of any protocol specification that instantiates this architecture. Cryptographic Session Binding and Relay Prevention. An Attestation Credential presented on a session MUST be cryptographically bound to that session and to the endpoint role in which it is presented. This is achieved by binding the Attestation Credential to an Attestation Binder derived from a Session Binding Value that is specific to the session and cannot be known before the session is initiated. Consequently, a valid Attestation Credential from one session cannot satisfy a Verifier or Relying Party on a different session or from a different endpoint; a replay carries a Binder derived from a different Session Binding Value and MUST be rejected. See . Split-Deployments. Because a compromised host could attempt to use the Attesting Environment as a signing oracle by substituting the attestation binder input, the architecture relies on cryptographic binding rather than continuous state monitoring. The Attesting Environment MUST bind the Attestation Credential to the private identity key (TSK) it holds to authenticate a connection (for example, by including a hash of the associated public key in the signed payload). The Relying Party then verifies that this claim matches the identity key presented in the transport handshake, preventing an untrusted host from successfully substituting the binder. Key Non-exportability (informative). The specific concern of demonstrating that the Subject Key (TSK) used for transport authentication is physically confined within the attested execution environment is addressed at the RATS layer by and is not re-specified here. Evidence Freshness. Evidence reflects the Attester's state at or near the Evidence Generation Time for the session in which it is presented. Per-session freshness ensures Evidence from a prior session cannot be replayed against a new one. When re-attestation occurs during a session's Lifetime of Connection, the re-attestation Evidence reflects the Attester's state at the time of re-attestation, not at Connection Establishment Time. Evidence Confidentiality. Evidence payloads SHOULD be protected by object-level encryption to a key held exclusively by the intended recipient. See . Session Resumption. When a transport session is resumed, a previously obtained Attestation Credential may no longer reflect the Attester's current state. Attestation from a prior session does not carry over to a resumed session. Directional Endpoint Binding. Distinct Attestation Binders MUST be derived for the initiator and the responder from the same Session Binding Value using distinct inputs. Evidence produced by one endpoint MUST NOT satisfy the verification requirement for the opposite endpoint. See . Transmission and Verification Anchor Soundness. An Attestation Binder may be included in a transport message before peer authentication is complete (the Transmission Anchor). Implementations MUST ensure the transport protocol's integrity guarantee covers the message carrying the Attestation Binder; for example, the TLS 1.3 handshake MAC (the Verification Anchor) retroactively guarantees the Binder's integrity at handshake completion. Downgrade Prevention. Two endpoints that both support attestation cannot be caused by an active adversary to negotiate a connection without it. The negotiation of attestation capabilities is protected against suppression. Dynamic Verification Code Integrity. When client-side attestation verification logic is dynamically delivered by the endpoint under appraisal (such as browser-based JavaScript), a circular trust dependency exists. Unless the client's execution environment enforces an independent, orthogonal guarantee of code integrity and binary transparency, application-layer attestation cannot provide security assurance, as the Attester may serve malicious code that bypasses cryptographic validation.

Additional attacker models The following adopts the attacker model of and evaluates security goals that are broadly inherited from the Security Considerations extending the broader RATS ecosystem. See .

Unauthorized System Hosting of Valid Credentials Attacker capabilities: A malicious peer possesses a valid, CA-endorsed authentication private key for an authorized peer identity and controls an endorsed Target Environment capable of producing authentic, fresh Evidence. Targeted assurance: The Relying Party verifies that the specific Target Environment is authorized to execute operations under the authenticated peer identity, preventing communication with an unauthorized system. Preconditions and attack: The Relying Party validates identity credentials and platform Evidence independently. The attacker hosts the valid key inside an unapproved confidential workload, completes the cryptographic transcript binding, and establishes the TLS connection. When the Relying Party's policy checks pass in isolation, it authorizes the session. Why validation succeeds: TLS proof of possession and platform Evidence verify against their respective independent trust roots, and the connection binder confirms channel co-location. Validation succeeds because neither root evaluates the other's domain, and the Relying Party lacks a policy rule linking them. Cryptographic channel binding alone is insufficient to establish that an attested environment is an authorized system for a given Authenticated Identity. Mitigation strategy: To prevent communication with an unauthorized system, compound authentication requires joint evaluation of the peer identity and platform measurements.

Encrypted Evidence and Blind Envelope Substitution Attacker capabilities: A network attacker or untrusted intermediary that can obtain or induce valid encrypted Evidence envelopes constructed against the current connection challenge. The attacker does not possess the Verifier's private decryption key, the Attestation Key, or the peer authentication key. Targeted assurance: The Evidence evaluated by the Verifier corresponds strictly to the encrypted payload conveyed across the secure channel. Preconditions and attack: When a Relying Party is restricted from handling claims directly, Evidence may be encrypted for an external Verifier to protect claim privacy (see ), leaving the Relying Party as a blind forwarder. The attacker intercepts the encrypted Evidence envelope and substitutes a different valid envelope constructed against the same connection challenge. The Relying Party forwards the substituted envelope to the Verifier, which decrypts it and returns an Attestation Result confirming valid Evidence for that challenge. The Relying Party completes the connection, falsely attributing the substituted posture to the peer. Why validation succeeds: The Relying Party cannot inspect inner claims. Verifier appraisal succeeds because the substituted payload contains valid signatures and matches the expected challenge. Standard channel authentication confirms control of the identity key, but remains cryptographically uncoupled from the inner Evidence. Mitigation strategy: The Relying Party computes a cryptographic commitment directly over the opaque encrypted Evidence bytes on the wire, and the Verifier binds this commitment into the signed Attestation Result, establishing transitive cryptographic closure between the channel transcript and the appraised payload.

IANA Considerations This document has no IANA actions.

References Normative References Remote ATtestation procedureS (RATS) Architecture In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Security Goals and Use Cases for Integrating Remote Attestation with Secure Channel Protocols Arm This document outlines desirable security goals and use cases for integrating remote attestation (RA) capabilities with secure channel establishment protocols (e.g., TLS and DTLS). Peer authentication in such protocols establishes trust in a peer's network identifiers but provides no assurance regarding the integrity of its underlying software and hardware stack. Remote attestation addresses this gap by enabling a peer to provide verifiable evidence about the current state of the Target Environment. This document specifies a set of essential security goals the protocol solution must have, including cryptographic binding to the secure connection, evidence freshness, and flexibility to support different attestation models. It then explores relevant use cases, such as confidential data collaboration and secure secrets provisioning, to motivate the need for this integration. This document is intended to serve as an input to the design of protocol solutions within the SEAT working group. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Service Identity in TLS Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. Ephemeral Diffie-Hellman Over COSE (EDHOC) This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW) The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. Together, these mechanisms allow CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts such as X.509 certificates. Additionally, this document defines media types and CoAP Content-Formats that may be used to identify CMWs when transported over protocols such as HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, enables the evolution of message serialization formats without breaking compatibility, and avoids the need to redefine how messages are handled within each protocol. Automatic Certificate Management Environment (ACME) Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. Privacy Framework for Remote ATtestation procedureS Cryptic Forest Software University of the Bundeswehr Munich University of Applied Sciences Bonn-Rhein-Sieg This document extends the RATS Architecture to consider "coercive uses of RATS" where a malicious Verifier or Relying Party uses RATS protocols to extract sensitive information from an Attester or a victim Verifier that it would not otherwise be inclined to disclose. This over-disclosure can include revealing sensitive measurements, stable identifiers, device fingerprints, vendor information, or conclusions derived from Evidence. This document defines a privacy framework for Remote Attestation that identifies this threat surfaces; classifies claims produced by Attesters and Presenters; restricts sensitive Evidence disclosure to authorized Trusted Verifiers using confidentiality protection; and describes privacy- preserving Attestation Results based on data minimization, Selective Disclosure, and Zero-Knowledge Proofs. Key Attestation for Entity Attestation Tokens (EAT) Nokia University of the Bundeswehr Munich Linaro Arm Limited Fraunhofer SIT This document defines an Entity Attestation Token (EAT) profile and a new EAT claim that convey the subject public key and its protection properties within attestation evidence. Combined with protocol-level proof of possession from the surrounding protocol, this establishes a cryptographic binding between a private key and an attested execution environment. The subject public key is conveyed using the EAT cnf claim defined in [RFC8747] and [RFC7800], and freshness uses the EAT eat_nonce claim defined in [RFC9711]. The proof of possession of the subject key is obtained from the surrounding protocol, such as TLS certificate-based authentication or CSR signature verification. Because the EAT is signed by a hardware-backed Attestation Key (AK), successful verification of the EAT signature together with protocol-level proof of possession establishes a cryptographic binding between the private key and the attested platform state. This mechanism addresses key substitution attacks that arise when attestation evidence and the certificate private keys are validated independently. Remote attestation over EDHOC Inria Ericsson AB This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. Automated Certificate Management Environment (ACME) Remote Attestation Identifier and Challenge Type Huawei Cryptic Forest Software, Ltd Sandelman Software Works Inc AppViewX, Inc Keyfactor This document describes an approach where an ACME Server can challenge an ACME Client to provide Evidence, Endorsements, or Attestation Result according to the Remote ATtestation procedureS (RATS) framework in any format supported by the Conceptual Message Wrapper (CMW). The ACME Server can optionally challenge the Client for specific claims that it wishes attestation for. Use of Remote Attestation with Certification Signing Requests Cryptic Forest Software Siemens Fraunhofer SIT Independent Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines ASN.1 structures which may carry attestation data for PKCS#10 and Certificate Request Message Format (CRMF) messages. Both standardized and proprietary attestation formats are supported by this specification. Extended Key Update for Transport Layer Security (TLS) 1.3 Siemens Münster Univ. of Applied Sciences Nokia Siemens Zscaler TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post- compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh execution of the key exchange negotiated during the initial handshake within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. Add Web PKI identity injection use case for ephemeral containers SEAT WG n.d. IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet Internet Architecture Board (IAB) Trusted Sockets Layer: A TLS 1.3 Based Trusted Channel Protocol Springer International Publishing Post-Quantum Signatures in Public-Key Infrastructures (plants) IETF n.d. Post-Quantum Authentication in Enterprise and Mobile Networks Nokia University of the Bundeswehr Munich

Implementing Transport Integration (informational) The Timing Models of describe when an Attestation Credential is conveyed relative to connection establishment. This section describes two structural implementation examples by which a transport protocol conveys an Attestation Credential to the Relying Party without requiring the transport specification itself to encode RATS semantics. Depending on the conveyance model, the Relying Party either forwards Evidence to a Verifier to receive an authorization decision (Background-Check Model) or validates an Attestation Result directly (Passport Model). This section describes two in-band structural implementations (Extension-Based and Structured Payload Conveyance).

Extension-Based Conveyance In this pattern, the transport protocol's existing identity or authentication structures (such as an X.509 certificate extension, or a comparable protocol-specific extension point) are reused to carry an Attestation Credential. The transport stack itself remains unaware of semantics: it recognizes only that an extension it is configured to process is present, and delegates interpretation of the extension's contents to an external callback. The transport state machine suspends progress at the point the extension is processed, invokes the callback with the extension payload, and resumes or aborts the handshake based on the callback's return value. The callback interface is transport-external: it need not be specified by the transport protocol itself, only supported by it as an extension point.

Session Binding in Intra-Handshake Solutions (informational) Cryptographic binding of Evidence to a per-connection session can be achieved in TLS 1.3 {RFC9846}} as follows:

Binder Derivation: The server computes the binder over the ClientHello...ServerHello transcript checkpoint, binding it directly to the hash of the server's public key.
Evidence Transmission: The Evidence containing this binder is conveyed within a dedicated Remote Attestation extension of the Certificate message.
Cumulative Transcript Incorporation: The Certificate message (carrying the Evidence and binder) becomes an immutable input into the running handshake transcript.
Transcript Sealing and Key Derivation: That cumulative transcript is signed by CertificateVerify and authenticated by the Finished MAC. The very same transcript snapshot directly derives the application traffic keys.

Structured Payload Conveyance In this pattern, the transport protocol defines a dedicated, opaque field for authorization-related data as part of its handshake or key-exchange messages, distinct from the identity structures used for peer authentication. The Attestation Credential, and any associated attestation-specific protocol elements, are carried within this field. The transport stack extracts the field's contents and passes them to an adjacent component responsible for semantics, without needing to parse or understand the contents themselves. As in Extension-Based Conveyance, the transport state machine halts pending the outcome of this processing. The distinction between the two patterns is where the extension point is anchored: an existing identity structure being overloaded (Extension-Based Conveyance) versus a field purpose-defined by the transport protocol for authorization data (Structured Payload Conveyance). Both patterns satisfy the requirement that an Attestation Credential be conveyed prior to the transition to application data exchange; the choice between them depends on the target transport protocol's extension model and is otherwise architecturally equivalent from an perspective.

Adjacent Work The SEAT WG is not the only WG within the IETF composing Remote Attestation with established IETF building blocks. Beyond the LAKE WG's own RA draft , another promiment example is the Automated Certificate Management Environment (ACME) WG and their adopted protocol extension ACME RATS .

ACME RATS The ACME protocol is designed to allow a CA and an applicant to automate the process of verification and issuance of Public Key Infrastructure X.509 (PKIX) certificates. An applicant requests a given identifier to appear in the certificate, and the ACME server provides a list of proof-of-control challenges. The ACME RATS extension defines a specialized RA challenge answered with a RATS Conceptual Message Wrapper (CMW) capable of carrying Evidence, Endorsements, or an Attestation Result in any RATS-supported format. This enables ACME RATS to provide a general, RATS-ecosystem-native framework for conveying supplemental trust and posture information, decoupled from certificate identifiers. The extension also includes a property where the applicatant can fetch an encryption public key that it can use for encrypting the remote- attestation (CMW) challenge response (see ).

Architectual Comparisions In operation, an X.509 certificate enhanced with RA such as or obtained through ACME RATS represents a textbook example of the RATS Passport conveyance model. However, such a certificate has a fixed validity period. If a Certificate Authority signs a standard 90-day certificate based on a boot-time measurement and a host later falls out of conformance with its expected security state 3 days later, then without continuous revocation mechanisms, a standard TLS 1.3 implementation will still accept the certicate, representing a significant TOCTOU risk (see ). A complimentary approach in addressing these kinds of TOCTOU risks may be addressed by deploying a dedicated protocol solution such as Attested TLS. For example, executing an in-band attestation exchange during TLS establishment allows the relying party to request a real-time, connection-bound re-evaluation of Attester's security state against current appraisal policy. This would work as a form of reattestation (see ) and enables reassessment of a given platform without having to reissue the identity certificate.

Acknowledgments The authors wish to thank all SEAT WG participants for their thoughtful input and contributions that have helped influence this document.

Document History

draft-many-seat-architecture-01

Terminology: Introduced TSK, capitalized key identifiers (AEK, ARK), and defined Authenticated Identity.
Architecture: Defined the RATS/SEAT interface with fail-closed semantics, formalized compound authorization and key provenance, and refreshed core diagrams.
Timing Models: Clarified post-handshake conveyance mechanisms within the transport layer (e.g., Exported Authenticators) alongside application framing, and decoupled conveyance timing from connection lifecycle events (initial trust establishment vs. periodic re-attestation).
Operations: Added a dedicated section detailing operational scope, trust boundaries, and attestation credential lifecycles; documented operational trade-offs and challenges under the Background-Check model and refined post-handshake failure handling to distinguish initial attestation gating from mid-connection re-attestation.
Security: Added threat models covering unauthorized credential hosting and blind envelope substitution under encrypted Evidence.
Appendices: Added TLS 1.3 session binding transcript derivation, comparative analysis with ACME RATS, and an out-of-band appraisal integration pattern using pre-cached Attestation Results.
Editorial: Added Yuxuan Song as co-author, updated affiliations, and revised references (including PLANTS-WG and IAB PQWS citations).

draft-many-seat-architecture-00

Initial version