Network Working Group D. Wang Internet-Draft F. Liu Intended status: Standards Track Y. Jiang Expires: 10 July 2026 J. Zhang Huawei 6 January 2026 Distributed Remote Attestation draft-wang-rats-distributed-remote-attestation-02 Abstract In many deployments, remote attestation is performed within separate administrative and trust domains. Each domain typically operates its own management plane and a Remote Attestation Service (RAS) to obtain verifier inputs (e.g., endorsement material and reference values) and produce attestation results. At scale, cross-domain scenarios face two recurring challenges: (1) enabling policy-controlled transparency so that verifiers or relying parties in one domain can discover and retrieve selected attestation artifacts from other domains; and (2) supporting many-to-many distribution and reuse of verifier inputs and verifier outputs without requiring point-to-point integrations. This document describes Distributed Remote Attestation (DRA) patterns that use a shared publication channel for selected artifacts with provenance and access control in mind. A Distributed Ledger (DL) is discussed as one concrete instantiation of such a publication channel, including an option to host verification logic on the DL. The described patterns are intended to complement existing RATS procedures and conceptual messages, and can be realized by other tamper-evident publication channels with comparable properties. 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." Wang, et al. Expires 10 July 2026 [Page 1] Internet-Draft DRA January 2026 This Internet-Draft will expire on 10 July 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Additional Definitions . . . . . . . . . . . . . . . . . 4 4. DRA Patterns . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. DL publication with off-chain attestation and verification . . . . . . . . . . . . . . . . . . . . . . 5 4.2. DL publication with optional on-chain verification . . . 6 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Freshness and Reuse . . . . . . . . . . . . . . . . . . . 8 5.2. Access Control and Provenance . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Remote attestation is increasingly deployed in federated and multi- operator environments where devices, services, and management systems span multiple administrative and trust domains. In practice, each trust domain often operates its own Remote Attestation Service (RAS) integrated into that domain's management plane, and exposes attestation capabilities and artifacts according to local policies. Wang, et al. Expires 10 July 2026 [Page 2] Internet-Draft DRA January 2026 Cross-domain deployments expose a gap that is not primarily about the attestation evidence format or the appraisal function itself, but about _how attestation artifacts are discovered, distributed, and reused_ across domains at scale. Two pain points are repeatedly observed: * _Cross-domain attestation transparency:_ A verifier or relying party in domain-A may need to obtain endorsement material, reference values, or attestation results that originate in domain- B. Direct point-to-point integration between operational sites does not scale, and is often infeasible due to operational domains and policy constraints. Deployments therefore need a policy- consensus controlled channel to publish and retrieve selected artifacts with clear provenance. * _Many-to-many distribution and reuse of security artifacts:_ Verifiers appraising heterogeneous attesters need to obtain endorser public keys, endorsements, and reference values from multiple providers. Conversely, providers need to distribute artifacts to multiple verifiers across domains. Similar many-to- many scaling issues apply when attestation results are shared for reuse by other verifiers or relying parties. Without a shared publication channel, each integration becomes a bespoke, brittle dependency. This document proposes a set of DRA patterns that make selected attestation artifacts more reusable across multiple verifiers and domains by introducing a shared publication channel. The publication channel is used to distribute: (a) verifier inputs such as endorser public keys, endorsements, and reference values; and (b) verifier outputs such as attestation results (or pointers/digests). A Distributed Ledger (DL) is discussed as one concrete instantiation of the publication channel. DLs provide tamper-evidence and append- only provenance, and can be deployed in permissioned settings with authenticated writes and controlled reads. Where appropriate, a DL can additionally host verification logic (e.g., smart contracts) to record appraisal outcomes in a shared, auditable manner. The patterns in this document are not limited to DLs and can also be realized using other tamper-evident publication channels with comparable integrity and availability properties. The rest of this document is organized as follows: Section 3 defines terminology and abbreviations; Section 4 specifies two DRA patterns (off-chain attestation/verification with on-channel publication, and an option for on-channel verification); and Section 5 discusses freshness, access control, governance, and privacy considerations. Wang, et al. Expires 10 July 2026 [Page 3] Internet-Draft DRA January 2026 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . 3. Conventions and Definitions This document uses roles and concepts defined by the RATS Architecture [RFC9334] (e.g., Attester, Verifier, Endorser, Reference Value Provider, and Relying Party). 3.1. Abbreviations DL: Distributed Ledger. DRA: Distributed Remote Attestation (the patterns described in this document). RAS: Remote Attestation Service (deployment-specific service performing verifier functions or mediating access to verifier inputs/outputs). RV: Reference Value (as in [RFC9334]). AE: Attestation Evidence (as in [RFC9334]). AR: Attestation Result (as in [RFC9334]). 3.2. Additional Definitions Artifact Publisher: An entity that publishes selected attestation artifacts to the publication channel, such as an Endorser publishing endorsement material, a Reference Value Provider publishing RVs, or a Verifier publishing ARs (or pointers/ digests). Artifact Consumer: An entity that retrieves artifacts from the publication channel, such as a Verifier retrieving RVs/ endorsements, or a Relying Party retrieving ARs for decision- making. Publication Channel: A shared channel used to publish and retrieve selected attestation artifacts with provenance. A DL is one concrete instantiation; other tamper-evident channels may also be used. Wang, et al. Expires 10 July 2026 [Page 4] Internet-Draft DRA January 2026 4. DRA Patterns This section describes two common patterns for using a DL-backed RAS as a publication channel for attestation artifacts. Both patterns assume that RVs and Endorser material (e.g., public keys and endorsement metadata) can be published to, and retrieved from, the DL under suitable access control policies. 4.1. DL publication with off-chain attestation and verification +-------------------+ +-------------------+ | Reference | | Endorsers | | value providers | | | +-------------------+ +-------------------+ | | | | | (0) RV | (0)PK | | +--------v-------------------------------------------v-----------+ | | | Distributed Ledger(Remote attestation service,RAS) | | | +-----------------------------------^----------------------------+ | | | (3)RV,PK | | (5)AR |(6)AR | | | | | | +----------------+ +--v-------------+ +-------v---+ | Attester | | Verifier | | Relying | | (1) freshness |---------->| (4) AR | | party | | proof | (2) AE | generation | | | +----------------+ +----------------+ +-----------+ Figure 1 on-chain-based publication and off-chain-based attestation/verification Figure 1: DL publication with off-chain attestation and verification As shown in Figure 1, attestation evidence exchange and appraisal follow existing RATS flows, while the DL is used to publish and retrieve verifier inputs and verifier outputs: 0) _Registration/publication of inputs:_ Reference Value Providers publish RVs to the DL/RAS. Endorsers publish endorsement-related artifacts (e.g., endorser public keys (PK) and/or endorsements) to the DL/RAS. Access control and provenance mechanisms (e.g., permissioning, signatures) are deployment-specific. 1) _Freshness proof preparation:_ A freshness challenge/context may Wang, et al. Expires 10 July 2026 [Page 5] Internet-Draft DRA January 2026 be issued by the Verifier, RP, or another authorized requester acting under policy (e.g., a domain management function). The challenge can take different forms depending on deployment (e.g., a nonce, an epoch identifier, a timestamp requirement, or a context string bound to an intended appraisal). The Attester uses the received challenge/context to construct a _freshness proof_ that will be included in AE (see step (2)). 2) _Evidence (off-chain):_ The Attester generates AE, incorporating the freshness proof required by the Verifier, and sends AE to the Verifier over an authenticated and integrity-protected channel. 3) _Retrieval of appraisal inputs:_ The Verifier retrieves RVs and Endorser artifacts (e.g., PK) from the DL/RAS (or from caches populated from it), and uses them as appraisal inputs. 4) _Result generation and publication:_ The Verifier appraises AE using the retrieved RV/PK, and generates AR. 5) _Publication of results:_ The Verifier publishes AR (or a pointer/digest to AR) to the DL/RAS for cross-domain discovery and potential reuse, subject to policy, privacy, and confidentiality constraints. 6) _Reuse:_ RP retrieves AR from the DL/RAS and decides whether to reuse it based on provenance, freshness/validity window, and local policy. 4.2. DL publication with optional on-chain verification Wang, et al. Expires 10 July 2026 [Page 6] Internet-Draft DRA January 2026 +-------------------+ +-------------------+ | Reference | | Endorsers | | value providers | | | +-------------------+ +-------------------+ | | | (0) RV | (0) PK(/endorsement) | | +--------v-------------------------------------------v-----------+ | | | +----------------+ +----------------+ | | | Registration | | Verification | | | | smart | | smart | | | | contract | | contract | | | +----------------+ +----------------+ | | | | Distributed Ledger (Remote attestation service, RAS) | | | +-------------^--------------------------------------------------+ (2) AE | | (3) AR | | +---v----------+ +----v--------------+ | Attester | | Verifier/Relying | | (1) PC | | party | +--------------+ +-------------------+ Figure 2 on-chain-based publication/attestation/verification Figure 2: DL publication with optional on-chain verification As shown in Figure 2, it can be beneficial to verify and/or record appraisal outcomes in a shared, tamper-evident way. In this pattern, the DL is used for publication as in the previous pattern, and hosts verification logic (e.g., smart contracts) or record verifiers' appraisal outcomes. 0) _Registration/publication of inputs:_ RVs and Endorser artifacts (e.g., PK/endorsements) are published to the DL/RAS. The _Registration smart contract_ supports publication authorization, schema/version checks, and governance rules. 1) _Evidence publication:_ The Attester generates AE and submits it to the DL/RAS via the Registration smart contract. AE could include a freshness proof suitable for publication and reuse (e.g., timestamp or epoch ID). The Attester may also obtain/ derive a public challenge (PC) value to support freshness/ unpredictability of the subsequent evidence. A common realization is to use a DL-derived value such as a recent block hash (or other consensus-derived header material). The block-generation process Wang, et al. Expires 10 July 2026 [Page 7] Internet-Draft DRA January 2026 (consensus, timestamps, and transaction sets) makes future block hashes hard to predict in advance, and the one-way property of hash functions prevents an attacker from predefining a desired hash by reverse-engineering corresponding block contents. Such selected PC is incorporated into AE in step (2). 2) _Verification and result recording (on-chain):_ The _Verification smart contract_ (or other on-chain verification logic) verifies AE using RVs and Endorser artifacts available from the DL/RAS, and checks freshness according to configured policy (e.g., acceptable time window / epoch constraints). The appraisal outcome is recorded as AR (or an appraisal log entry) on-chain. Triggering may be initiated by a Verifier, a Relying Party, or automatically upon AE submission, subject to policy. 3) _Result retrieval:_ The Verifier/RP queries the DL/RAS and obtains AR for decision-making and/or reuse. 5. Discussion 5.1. Freshness and Reuse For the DRA service, the blocks of the DL need to be generated at appropriate time intervals, such as every few seconds. The consensus rules trigger the new block generation process periodically through preset time parameters. Even if there is no transaction data within a specific period, nodes will still generate an empty block containing basic information like the hash of the previous block and timestamps according to established algorithms. This approach aims to maintain the continuity of the DL chain structure and the orderliness of timestamps, thereby ensuring the freshness and validity of PC. Artifact Consumers evaluates whether retrieved artifacts are fresh enough for their own threat model and acceptable staleness window. When ARs are published for reuse, it is recommended that ARs include time-of-appraisal and a validity interval, so that downstream consumers can make an informed decision. 5.2. Access Control and Provenance The publication channel enforces authorization for publication. Consumers validates provenance and integrity (e.g., signatures, trust anchors) for retrieved RVs, endorsement material, and ARs. Deployments further defines governance for artifact update/rollback and caching policies. Wang, et al. Expires 10 July 2026 [Page 8] Internet-Draft DRA January 2026 6. IANA Considerations This document has no IANA considerations. 7. Security Considerations TODO 8. References 8.1. Normative Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 8.2. Informative References [RFC9334] Thaler, D., Richardson, M., Smith, M., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", January 2023, . Acknowledgments TODO Authors' Addresses Donghui Wang Huawei Email: wangdonghui124@huawei.com Faye Liu Huawei Email: liufei19@huawei.com Yuning Jiang Huawei Email: jiangyuning2@h-partners.com Jun Zhang Huawei Email: junzhang1@huawei.com Wang, et al. Expires 10 July 2026 [Page 9]