Internet-Draft K. O. Elekula Intended status: Informational Independent Researcher Expires: 30 April 2027 31 October 2026 Interoperability, Security Evaluation, and Negative Testing for Attested TLS 1.3 and DTLS 1.3 draft-elekula-seat-attested-tls-testing-00 Abstract This document defines a framework for reproducible interoperability and security evaluation of implementations that integrate remote attestation with TLS 1.3 and DTLS 1.3. It complements protocol and architecture specifications by defining test profiles, a common result model, cross-implementation procedures, negative tests, and measurements at the boundary between transport authentication, attestation appraisal, authorization, and application-data release. In addition to per-connection attestation, the framework evaluates reusable Attestation Results and cross-connection trust-continuity mechanisms, including deployments in which an attestation endpoint and application-serving endpoint are distinct. It addresses key custody and derivation, target and workload identity, state drift, credential lifecycle, multi-relying-party isolation, proxy topology, session resumption, early data, privacy, and failure containment. This document does not define a new attestation architecture, Evidence format, TLS or DTLS extension, cryptographic key schedule, or remote-attestation protocol. It specifies an evaluation framework for comparing implementations and identifying interoperability and security gaps in declared profiles. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 April 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. Table of Contents 1. Introduction 2. Conventions and Terminology 2.1. Conventions 2.2. Terminology 3. Scope and Non-Goals 3.1. In Scope 3.2. Non-Goals 3.3. Relationship to Existing Work 4. Evaluation Model 4.1. Distinct Decision Boundaries 4.2. Trust Models 4.3. Binding Dimensions 4.4. Topology Declaration 5. Test Profiles 5.1. Profile A: Intra-Handshake Attestation 5.2. Profile B: Post-Handshake Attestation 5.3. Profile C: Mutual Attestation 5.4. Profile D: Optional or Negotiated Attestation 5.5. Profile E: Session Resumption and Early Data 5.6. Profile F: DTLS 1.3 5.7. Profile G: Cross-Connection Trust Continuity 5.8. Profile H: Proxy and Split-Endpoint Deployment 5.9. Profile I: Workload Identity 6. Expanded Security and Interoperability Gap Taxonomy 6.1. Connection and Endpoint Binding 6.2. Evidence Reuse and Result Reuse 6.3. Cross-Connection Trust Continuity 6.4. Derived-Key and Key-Custody Evaluation 6.5. Target and Workload Identity 6.6. State Drift and Re-attestation 6.7. Credential and Artifact Lifecycle 6.8. Multi-Relying-Party and Multi-Tenant Isolation 6.9. Multi-Serving-Endpoint Consistency 6.10. Proxy and Channel-Boundary Integrity 6.11. Negotiation, Downgrade, and Algorithm Agility 6.12. Session Resumption and 0-RTT 6.13. Verifier, Policy, and Trust-Anchor Failure 6.14. Privacy and Linkability 6.15. Availability and Resource Exhaustion 6.16. Cryptographic Agility and Quantum-Transition Readiness 7. Test Vector Schema and Execution 7.1. Required Vector Fields 7.2. Result Classification 7.3. Positive and Negative Controls 7.4. Cross-Implementation Procedure 7.5. Observability 8. Mandatory Worked Test Cases 8.1. ATTEST-BIND-001: Valid Per-Connection Binding 8.2. ATTEST-REPLAY-002: Cross-Connection Evidence Replay 8.3. ATTEST-RESULT-003: Permitted Cached Attestation Result 8.4. ATTEST-FWD-004: Forward Trust-Continuity Lifecycle 8.5. ATTEST-FWD-KEY-005: Shared-Key and Key-Custody Boundary 8.6. ATTEST-FWD-RP-006: Multi-Relying-Party Isolation 8.7. ATTEST-WORKLOAD-007: Workload Identity and Lifecycle 8.8. ATTEST-0RTT-008: Protected Early Data 8.9. ATTEST-DTLS-009: Datagram Loss, Duplication, and Reordering 8.10. ATTEST-PROXY-010: Split Endpoint and Proxy Boundary 9. Measurement and Reporting 10. Open Evaluation Questions for SEAT Discussion 11. Security Considerations 12. IANA Considerations 13. References 13.1. Normative References 13.2. Informative References 14. Author's Address 1. Introduction TLS peer authentication establishes a cryptographic identity for a network endpoint. It does not, by itself, establish the integrity or identity of the software and hardware environment serving the connection. Remote attestation can provide claims about a Target Environment, which a Verifier appraises and a Relying Party uses under an appraisal and authorization policy. The integration of remote attestation with TLS and DTLS introduces multiple distinct security decisions. A transport handshake can succeed while attestation is pending or has failed. Evidence can be authentic but bound to the wrong connection, endpoint, role, workload, or policy. An Attestation Result may be reusable under a Passport-model policy, while connection-bound Evidence generally is not transferable to another connection. A Relying Party may also establish trust once and exercise it over subsequent connections, provided the chosen mechanism explicitly defines that continuity. Existing SEAT work addresses use cases and security goals, intra-handshake attestation, Exported Authenticator-based post-handshake attestation, architecture, proxies, timing choices, and workload identity options. Recent work on forward attestation introduces a further evaluation dimension: a credential obtained over an attestation connection can be used to authenticate later connections to serving endpoints in the same Target Environment. This changes the test boundary from one connection to a lifecycle of related connections. The purpose of this document is to make those boundaries testable. It defines an evaluation framework rather than a competing protocol. It aims to help implementers and the SEAT community compare implementations, identify ambiguous assumptions, and prioritize interoperable test vectors. A test result is meaningful only in relation to a declared protocol revision, profile, topology, policy, implementation version, and observable enforcement point. 2. Conventions and Terminology 2.1. Conventions The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and only when, they appear in all capitals. These terms specify requirements for this evaluation framework and its declared test profiles. They do not create protocol requirements for TLS, DTLS, SEAT, or RATS beyond the referenced specifications. 2.2. Terminology Terms such as Attester, Evidence, Verifier, Attestation Result, Relying Party, Target Environment, and appraisal policy have the meanings assigned in the RATS architecture (RFC 9334) and the applicable SEAT architecture document. Attestation Connection: A connection used to perform an attestation exchange and establish an attestation-related trust artifact. Forward Connection: A subsequent connection that relies on a previously established trust artifact, where the selected protocol profile defines such reuse. Trust-Continuity Artifact: A credential, key, certificate, token, or other protocol-defined artifact used to associate a later connection with an earlier attestation decision. Serving Endpoint: An endpoint that serves application traffic and may differ from the endpoint that performed the attestation exchange. Workload Identity: An identity assigned to an application workload, service, or execution instance. It is distinct from a host, device, TEE, or transport endpoint identity unless the deployment explicitly establishes their relationship. Evidence freshness: Whether Evidence or an Attestation Result remains acceptable under the declared freshness policy. Trust-continuity freshness: Whether a previously established trust artifact remains acceptable for a later connection, given its lifetime, revocation status, policy, and Target Environment state. Enforcement point: The component that actually permits, blocks, restricts, or terminates access to protected application data or operations. 3. Scope and Non-Goals 3.1. In Scope This framework applies to TLS 1.3 (RFC 9846) and DTLS 1.3 (RFC 9147) deployments that integrate remote attestation. It evaluates: o pre-, intra-, and post-handshake attestation profiles where specified by an implementation or test profile; o background-check and Passport-model Evidence/Attestation Result flows; o per-connection binding and permitted reuse of attestation artifacts; o cross-connection trust continuity, including forward-attestation designs; o split endpoints, proxies, workload identity, and multi-tenant deployments; o session resumption, 0-RTT, re-attestation, revocation, and state drift; o interoperability, security-negative tests, and performance. 3.2. Non-Goals This document does not select a preferred SEAT protocol, prescribe a universal attestation policy, define new wire messages, define certificate profiles, specify key derivation, or certify platform trustworthiness. It does not assume that all SEAT mechanisms have identical security properties. 3.3. Relationship to Existing Work The framework is complementary to the SEAT use-case and security goals document, the SEAT architecture, attestation in TLS/DTLS, Remote Attestation with Exported Authenticators, proxy mechanisms, timing-model analysis, workload-identity options, and forward attestation proposals. Test definitions MUST identify the exact revision of each specification used. A work-in-progress document is not a stable protocol contract. Where a draft changes, affected vectors SHOULD be versioned and rerun. 4. Evaluation Model 4.1. Distinct Decision Boundaries Implementations and reports MUST distinguish at least these boundaries: 1. Transport negotiation and handshake completion. 2. TLS/DTLS peer authentication. 3. Attestation capability negotiation. 4. Evidence or Attestation Result conveyance. 5. Evidence appraisal and Attestation Result validation. 6. Target Environment and workload identity association. 7. Authorization policy evaluation. 8. Protected-data release or operation execution. 9. Re-attestation, revocation, and trust-artifact invalidation. A successful outcome at one boundary MUST NOT be reported as proof of success at a later boundary. 4.2. Trust Models Each test MUST declare whether the deployment uses the RATS background-check model, Passport model, or another explicitly described model. A cached Attestation Result is not automatically replay. Its reuse is valid only if permitted by the selected architecture and policy, and if issuer trust, target identity, freshness, policy version, and any required current-connection binding conditions are satisfied. 4.3. Binding Dimensions Tests SHOULD separately evaluate binding to: o the TLS/DTLS handshake or connection; o the initiator/responder role and message direction; o the authenticated transport peer; o the Target Environment or machine identity; o the workload/service identity; o the application-serving endpoint; o the Relying Party and intended audience; o the appraisal and authorization policy; o the trust-continuity artifact and its lifecycle. A profile may not require every dimension. The test report MUST state which dimensions are required, supplied, verified, or absent. 4.4. Topology Declaration The test topology MUST identify the Attester, Verifier, Relying Party, attestation endpoint, serving endpoint, proxies, gateways, sidecars, workload boundary, and enforcement point as applicable. The topology MUST also identify which components terminate TLS, possess private keys, see plaintext, generate Evidence, appraise Evidence, cache results, or authorize operations. 5. Test Profiles 5.1. Profile A: Intra-Handshake Attestation Evaluate transcript and session binding, role directionality, negotiation integrity, failure handling, and the point at which application data becomes available. 5.2. Profile B: Post-Handshake Attestation Evaluate Exported Authenticator or other declared post-handshake exchange, request-context binding, application gating, timeout, failure, and subsequent data restrictions. Post-handshake attestation cannot retroactively protect data released before the appraisal and authorization decision. 5.3. Profile C: Mutual Attestation Evaluate both directions independently, including partial success, role confusion, and policy requiring one or both endpoints to pass. 5.4. Profile D: Optional or Negotiated Attestation Evaluate capability discovery, mandatory versus optional policy, unsupported peers, downgrade, fallback, and negotiation mismatch. 5.5. Profile E: Session Resumption and Early Data Evaluate resumed sessions, inherited attestation state, 0-RTT, policy changes, state drift, and anti-replay. Transport early-data anti-replay and attestation Evidence replay are distinct properties. 5.6. Profile F: DTLS 1.3 Evaluate loss, duplication, reordering, retransmission, fragmentation, reassembly, record replay, connection identifiers, and path changes. Transport duplicate handling MUST NOT be conflated with semantic Evidence replay. 5.7. Profile G: Cross-Connection Trust Continuity Evaluate mechanisms in which a trust artifact established on an Attestation Connection is used on one or more later Forward Connections. This profile is applicable only where the selected protocol explicitly defines this model. The Forward Attested TLS proposal cited in this document specifies subsequent TLS connections; this framework does not imply that the same mechanism applies to DTLS. A test MUST identify whether it evaluates that specific proposal or another independently specified trust-continuity mechanism. Tests MUST distinguish fresh per-connection attestation from continuity with a prior attestation. Reports MUST NOT describe a Forward Connection as freshly attested unless a new attestation exchange actually occurs. 5.8. Profile H: Proxy and Split-Endpoint Deployment Evaluate declared cooperative and non-cooperative proxies, TLS termination boundaries, end-to-end binding, key visibility, forwarding of Evidence, and enforcement placement. 5.9. Profile I: Workload Identity Evaluate association between attested platform/TEE identity and workload identity, including workload name, namespace, service, image or measurement reference, instance identity, and lifecycle events where those attributes are part of the selected profile. 6. Expanded Security and Interoperability Gap Taxonomy 6.1. Connection and Endpoint Binding Test valid binding, wrong-connection binding, wrong peer, wrong role, wrong direction, missing binding, and mutation of binding inputs. The test must identify the precise binding value and protocol-defined derivation or transcript reference without disclosing secrets. 6.2. Evidence Reuse and Result Reuse Test connection-bound Evidence replay separately from permitted Attestation Result reuse. Include issuer substitution, target substitution, policy-version mismatch, expiry, stale revocation data, and missing current-session context. 6.3. Cross-Connection Trust Continuity Test a trust artifact established on connection A and presented on connections B and C. Evaluate whether the artifact is scoped to the intended Target Environment, Relying Party, serving endpoint set, role, and policy. Test acceptance after artifact expiry, explicit revocation, state change, and policy change. 6.4. Derived-Key and Key-Custody Evaluation For profiles deriving a trust-continuity key from TLS exporter material, evaluate: o exporter label and context separation; o role and direction separation; o algorithm negotiation and algorithm mismatch; o deterministic key-generation behaviour and implementation interoperability; o rejection of malformed or out-of-range derived material; o key-purpose separation and cross-protocol misuse; o which parties know or can reconstruct the private key; o storage, transfer, reload, backup, and deletion of key material; o compromise of either endpoint that possesses shared key material; o rotation and invalidation after compromise. A test report MUST describe the actual key-custody model. It MUST NOT characterize a deliberately shared key as exclusively TEE-confined. A signature made with a key known to both parties cannot, by itself, prove which party created the signature. This framework does not prescribe a key derivation algorithm. It tests conformance to the algorithm and key-management rules of the protocol under evaluation. If the protocol leaves an encoding, negotiation parameter, or interoperability rule unspecified, the corresponding test MUST be reported as an open design question or implementation-specific experiment, not as a protocol conformance failure. 6.5. Target and Workload Identity Test whether the attested identity refers to a host, TEE, virtual machine, confidential workload, service, process, or serving endpoint. Evaluate ambiguity and substitution between these identity levels. Test workload restart, migration, scaling, image update, namespace change, service-account change, and reassignment of a serving endpoint. 6.6. State Drift and Re-attestation Test software/firmware update, configuration change, workload restart, runtime compromise, policy change, and changes in revocation status while connections remain open or trust artifacts are reused. Measure time from a state-change event to enforcement. Record whether existing connections are terminated, restricted, or permitted to continue and why. 6.7. Credential and Artifact Lifecycle Test expiry, renewal, revocation, explicit invalidation, cache eviction, stale replicas, clock skew, certificate reload, rollback to an earlier credential, and race conditions between renewal and serving-endpoint rollout. Evaluate propagation delay across all serving endpoints. 6.8. Multi-Relying-Party and Multi-Tenant Isolation Test two or more Relying Parties attesting the same Target Environment. Evaluate whether credentials, derived keys, cached results, policies, and serving-endpoint selection are isolated. Test wrong-Relying-Party presentation, SNI/virtual-host selection, cross-tenant cache confusion, and accidental sharing of artifacts. Distinct key identifiers do not alone establish unlinkability; certificate fields and Evidence claims may still correlate parties. 6.9. Multi-Serving-Endpoint Consistency Test the same trust artifact across all declared serving endpoints. Include stale endpoint replicas, partial credential rollout, inconsistent clocks, different policy versions, compromised endpoints, and endpoint removal. Determine whether one endpoint can continue serving after another has invalidated the artifact. 6.10. Proxy and Channel-Boundary Integrity Test TLS-terminating proxies, cooperative intermediaries, sidecars, gateways, load balancers, and service meshes. Determine which component can observe plaintext, alter handshake state, access exporter material, or substitute endpoint identity. Evaluate whether the test's security claim is end-to-end or only hop-by-hop. 6.11. Negotiation, Downgrade, and Algorithm Agility Test extension stripping, unknown-extension handling, conflicting capabilities, unsupported algorithms, fallback, version skew, and inconsistent policy negotiation. Ensure a downgrade cannot silently convert mandatory attestation into optional attestation. 6.12. Session Resumption and 0-RTT Test whether attestation state remains valid for resumed sessions. Include early-data operations, PSK/session-ticket scope, policy change, state drift, credential revocation, and expiration during ticket lifetime. Determine whether resumption is prohibited, revalidated, or permitted by the profile. 6.13. Verifier, Policy, and Trust-Anchor Failure Test Verifier outage, invalid or conflicting Attestation Results, trust-anchor rotation, compromised issuer, stale reference values, appraisal-policy update, policy retrieval failure, and revocation service outage. Record fail-open, fail-closed, restricted, deferred, or terminated outcomes. 6.14. Privacy and Linkability Test disclosure of Evidence to intermediaries, identifying claims in certificates and logs, repeated presentation of credentials, correlation across Relying Parties, correlation across serving endpoints, and linkage between successive credentials after re-attestation. Evaluate both direct identifiers and quasi- identifiers. 6.15. Availability and Resource Exhaustion Test oversized Evidence, expensive appraisal, concurrent attestation requests, malformed fragments, retransmission storms, verifier queue exhaustion, cache churn, and repeated re-attestation triggers. Measure resource use and verify bounded failure behaviour. 6.16. Cryptographic Agility and Quantum-Transition Readiness Where a deployment uses cryptographic algorithms with planned transition requirements, test algorithm negotiation, certificate and signature compatibility, key rotation, mixed-version operation, and preservation of verifiable historical evidence. Do not infer that a post-quantum key-establishment mechanism provides signature authenticity, or that a signature algorithm provides confidentiality. The test profile MUST identify the algorithms and security claims actually exercised. 7. Test Vector Schema and Execution 7.1. Required Vector Fields Each vector MUST include: o identifier, version, profile, protocol and protocol-draft revision; o implementation names, versions, roles, and topology; o pseudonymous endpoint, Target Environment, workload, and Relying Party identifiers; o attestation model, Evidence type, Attestation Result type, and trust-anchor reference; o binding inputs and references, without secret material; o appraisal and authorization policy identifiers and versions; o artifact lifetime, timestamps, clock assumptions, and revocation state; o attacker capability and exact mutation; o expected handshake, binding, appraisal, authorization, and application-data state transitions; o observable enforcement point and trace reference; o actual outcome, classification, environment, and deviations. 7.2. Result Classification PASS: expected behaviour observed with required evidence. FAIL: observed behaviour contradicts expected behaviour. NOT_APPLICABLE: profile does not apply, with reason recorded. INDETERMINATE: evidence or instrumentation is insufficient or conflicting. NOT_TESTED: test was not executed. For a negative test, PASS means the defined invalid condition was handled as expected. Reports MUST distinguish a test that passed from a test that was not run. 7.3. Positive and Negative Controls Each negative-test family SHOULD include a positive control. Negative tests MUST identify the single mutation or explicitly document multiple mutations. A failed positive control makes the corresponding negative result inconclusive unless that failure is itself the test objective. 7.4. Cross-Implementation Procedure Interoperability claims MUST be based on at least two independent implementations for the relevant roles. Reports SHOULD include a matrix of client/server, Attester/Verifier/Relying Party, and serving-endpoint combinations. Self-interoperability is not cross-implementation interoperability. 7.5. Observability Record handshake completion, attestation request and response, appraisal completion, authorization completion, trust-artifact issuance/acceptance/invalidation, and first protected-data release. Use synchronized or bounded-error clocks and state the clock uncertainty. Avoid logging secrets, private keys, raw sensitive Evidence, or protected application data. 8. Mandatory Worked Test Cases 8.1. ATTEST-BIND-001: Valid Per-Connection Binding Establish a fresh connection and perform the selected attestation exchange. Supply valid Evidence whose binding corresponds to the current connection, endpoint, role, and policy. Expected: binding and appraisal succeed; authorization is evaluated; protected data is released only after the required authorization decision. Negative control: mutate one binding input. Expected: rejection or policy-defined failure and no protected-data release. 8.2. ATTEST-REPLAY-002: Cross-Connection Evidence Replay Capture a test fixture from connection A and present it on connection B without generating a valid B-specific response. Expected: connection-binding or freshness validation fails. Protected data on B remains unavailable. A fresh exchange on B acts as the positive control. 8.3. ATTEST-RESULT-003: Permitted Cached Attestation Result Present a cached result in a new connection under a profile that permits reuse. Expected: acceptance only if issuer trust, target identity, freshness, policy version, and all required current- connection context are valid. Repeat with expired, revoked, wrong-target, or stale-policy result; expected: reject or re-attest. Reuse alone is not replay. 8.4. ATTEST-FWD-004: Forward Trust-Continuity Lifecycle Establish an Attestation Connection and obtain the trust-continuity artifact defined by the selected forward-attestation protocol. Present it on two authorized Forward Connections to serving endpoints in the declared Target Environment. Expected: both endpoints accept only within the artifact's declared scope and validity. Then trigger expiry, revocation, policy change, and Target Environment state change independently. Measure propagation and ensure subsequent connections are rejected or restricted as specified. Record that Forward Connections rely on continuity and are not freshly attested unless a new exchange occurs. 8.5. ATTEST-FWD-KEY-005: Shared-Key and Key-Custody Boundary For a profile where the trust-continuity private key is known to both the Attester side and Relying Party, test unauthorized use by each key holder, compromise of the shared storage path, key export, credential reload, key rotation, and attempted use for an unauthorized protocol purpose. Expected: observed properties match the declared shared-key model; no report claims exclusive TEE possession where the key is shared. 8.6. ATTEST-FWD-RP-006: Multi-Relying-Party Isolation Establish independent attestation contexts for Relying Parties A and B against the same Target Environment. Attempt to present A's artifact to B and vice versa; test SNI/virtual-host selection and shared cache boundaries. Expected: artifacts are accepted only in their intended Relying Party scope. Record residual linkability through certificate fields and Evidence claims. 8.7. ATTEST-WORKLOAD-007: Workload Identity and Lifecycle Attest a workload with a declared identity. Restart, replace, migrate, or update the workload while retaining or changing the host/TEE identity as specified by the scenario. Expected: the relying policy distinguishes platform identity from workload identity and applies the declared invalidation or re-attestation rule. A host-level attestation MUST NOT be reported as workload identity verification unless the binding is actually established. 8.8. ATTEST-0RTT-008: Protected Early Data Attempt a policy-protected operation in 0-RTT before required attestation and authorization. Expected: the operation is withheld or rejected according to policy. Record any unprotected early data separately and distinguish TLS anti-replay from attestation replay. 8.9. ATTEST-DTLS-009: Datagram Loss, Duplication, and Reordering Inject deterministic loss, duplication, and reordering into the attestation exchange. Expected: protocol-defined retransmission and record handling work correctly; transport duplicates are not confused with new Evidence; a semantic replay from another connection is rejected. 8.10. ATTEST-PROXY-010: Split Endpoint and Proxy Boundary Exercise the declared topology with a cooperative proxy and with an unauthorized or misconfigured intermediary. Observe plaintext visibility, binding preservation, endpoint identity, key access, and application-data enforcement. Expected: the reported security property matches the actual end-to-end or hop-by-hop boundary. 9. Measurement and Reporting Performance tests SHOULD establish a baseline with the same implementation and environment absent the attestation operation under evaluation. Report sample count, hardware, software, cryptographic provider, network conditions, concurrency, workload, and warm/cold conditions. Report minimum, median, 90th, 95th, and 99th percentile, maximum, and sample count for latency. Measure handshake, Evidence generation, conveyance, appraisal, authorization, trust-artifact issuance, cache lookup, credential reload, revocation propagation, and first protected-data release separately where applicable. For forward-attestation profiles, report: o cost of initial attestation; o cost per Forward Connection; o cost and interruption of re-attestation; o number of serving endpoints updated; o maximum stale-credential acceptance window; o invalidation propagation time; o storage and distribution costs for trust artifacts. Reports MUST identify measurement boundaries and disclose deviations. Passing a test demonstrates only observed behaviour under stated conditions; it is not a security certification. 10. Open Evaluation Questions for SEAT Discussion This section identifies questions suitable for interoperability discussion. It does not assert that the referenced protocol drafts are defective. Q1. What is the minimum common test profile that independent implementations can execute across intra-handshake and Exported Authenticator-based post-handshake attestation? Q2. Which binding dimensions are mandatory for a reusable cross-connection trust artifact: Target Environment, workload, serving endpoint set, Relying Party, policy, and audience? Q3. For exporter-derived shared keys, what key-custody and compromise assumptions must a test report disclose, and which properties can a relying party actually verify? Q4. What is the expected invalidation model after runtime state change, credential compromise, policy update, or revocation? Is expiry alone adequate for each deployment? Q5. How should multi-Relying-Party credential selection and cross-tenant cache isolation be tested consistently? Q6. What evidence demonstrates that a workload identity is bound to the attested platform and the serving endpoint, rather than merely asserted by an application component? Q7. Which observations and timing boundaries are required to compare pre-, intra-, post-handshake, and forward-attestation approaches fairly? Q8. What minimum negative-test vectors and interoperability matrix should be maintained as a shared SEAT test corpus? Q9. How should privacy/linkability be measured across repeated credentials, multiple serving endpoints, and multiple Relying Parties? Q10. Which tests should be run by protocol implementers, platform vendors, Verifier operators, and independent test laboratories? 11. Security Considerations This document defines an evaluation framework, not a security protocol. Test harnesses can expose Evidence, identifiers, private keys, policy data, and application metadata. Use synthetic test claims, protect traces, restrict access, and never publish secrets. Test-vector definitions and result reports SHOULD be integrity- protected and versioned. An altered test definition can invalidate conclusions. Attestation does not guarantee that claims are true or that a platform is free of compromise. A successful appraisal means only that the Evidence satisfied a particular appraisal policy at a particular time. A successful authorization decision is a separate policy outcome. Trust continuity introduces a time interval during which later connections rely on an earlier appraisal. Tests MUST measure the effects of state drift, revocation, compromise, and policy change during that interval. Where a key is shared, signatures made with it do not prove exclusive authorship by one key holder. Privacy testing must consider both direct identifiers and linkability through repeated credentials, certificate fields, workload claims, and endpoint selection. Resource-exhaustion tests SHOULD be conducted in controlled environments with bounded retry and resource limits. 12. IANA Considerations This document has no IANA actions. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, April 2022. [RFC9261] Sullivan, N., "Exported Authenticators in TLS", RFC 9261, July 2022. [RFC9334] Birkholz, H., et al., "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023. [RFC9846] "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, July 2026. 13.2. Informative References [I-D.ietf-seat-use-cases] Mihalcea, I., Ed., "Security Goals and Use Cases for Integrating Remote Attestation with Secure Channel Protocols", draft-ietf-seat-use-cases-01, September 2026, Work in Progress. [I-D.fossati-seat-early-attestation] Sheffer, Y., et al., "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", draft-fossati-seat-early-attestation-08, October 2026, Work in Progress. [I-D.many-seat-architecture] Ritz, N., et al., "Secure Evidence and Attestation Transport (SEAT) Architecture", draft-many-seat-architecture-00, July 2026, Work in Progress. [I-D.fossati-seat-expat] Sardar, M. U., et al., "Remote Attestation with Exported Authenticators", draft-fossati-seat-expat-04, September 2026, Work in Progress. [I-D.ritz-seat-proxies] Ritz, N., et al., "Bridging Remote Attestation with Secure Channel Protocol Proxies", draft-ritz-seat-proxies-00, July 2026, Work in Progress. [I-D.usama-seat-intra-vs-post] Sardar, M. U., "Pre-, Intra- and Post-handshake Attestation", draft-usama-seat-intra-vs-post-04, July 2026, Work in Progress. [I-D.zhang-seat-selection] Zhang, J., et al., "Balancing Security and Deployability in the Selection of Attested TLS Protocol", draft-zhang-seat-selection-01, July 2026, Work in Progress. [I-D.reddy-seat-cc-workload-identity] Reddy, T., et al., "Workload Identity Options for Attested TLS in Confidential Computing", draft-reddy-seat-cc-workload-identity-00, October 2026, Work in Progress. [I-D.larraia-seat-forward-attestation] Larraia, E. and A. Tsukamoto, "Binding Attestation to Forward TLS Connections", draft-larraia-seat-forward-attestation-00, October 2026, Work in Progress. 14. Author's Address Kayode Oluwole Elekula Independent Researcher Email: kayodeelekula@gmail.com