Futurewei

dlu@futurewei.com

RATS EAT attestation mobile security device integrity This document defines a federated infrastructure layer for cross-platform device and application attestation. The proposed architecture extends the Remote ATtestation ProcedureS (RATS) architecture by introducing privacy-preserving federation, decentralized endorsement distribution, decentralized normalization of attestation claims, and software supply-chain provenance integration. The architecture enables interoperable attestation across heterogeneous operating systems, application ecosystems, and trust providers without requiring centralized platform ownership. This document defines architectural roles, protocol interactions, endorsement distribution semantics, provenance integration models, and privacy requirements.

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). Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted at any time.

Introduction Remote ATtestation procedureS (RATS) Architecture defines a generalized architecture for remote attestation systems. However, existing attestation deployments remain highly platform-centric and rely on vertically integrated trust infrastructures. Examples include proprietary mobile integrity services, hardware vendor-specific endorsement chains, cloud-provider-specific attestation APIs, and disconnected software supply-chain verification systems. These models create several limitations including fragmentation across ecosystems, inability to interoperate across trust domains, centralized endorsement bottlenecks, privacy leakage, opaque claim semantics, and weak integration with software provenance systems. This document defines a Federated Infrastructure Layer for cross-platform attestation interoperability. The architecture enables interoperable attestation verification, decentralized trust distribution, portable claim semantics, composable trust evaluation, and provenance-aware application integrity assessment.

Terminology 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 .

Federated Verifier A verifier capable of consuming attestation evidence from multiple heterogeneous attestation providers.

Claim Normalizer A logical role that transforms platform-specific attestation claims into normalized semantic claims.

Endorsement Distributor A decentralized service responsible for distributing endorsements, reference values, and trust anchors.

Provenance Authority An authority responsible for validating software supply-chain provenance metadata.

Requirements

R1: Cross-Platform Interoperability The system MUST support heterogeneous attestation providers and operating systems.

R2: Decentralized Trust Distribution The architecture MUST avoid mandatory centralized endorsement authorities.

R3: Privacy Preservation The architecture MUST minimize device-identifying information leakage.

R4: Claim Portability The architecture MUST support normalized semantic claims across ecosystems.

R5: Provenance Awareness The architecture MUST support integration with software supply-chain provenance systems.

R6: Federated Extensibility The architecture MUST permit independently governed attestation domains.

Discussion The requirements defined in this section are motivated by increasing fragmentation in modern attestation ecosystems. Current industry deployments are typically vertically integrated and optimized for a single vendor trust domain. Mobile ecosystems commonly bind attestation semantics to proprietary platform APIs, cloud providers expose provider-specific confidential computing attestation formats, and enterprise endpoint systems frequently rely on closed posture-assessment protocols. Cross-platform interoperability is therefore required to support heterogeneous device fleets and multi-cloud execution environments. Decentralized trust distribution is motivated by operational and geopolitical concerns surrounding centralized trust anchors. Privacy preservation reflects growing industry movement toward minimizing globally correlatable identifiers. Claim portability is motivated by the operational burden created by incompatible attestation semantics. Provenance awareness reflects the growing importance of software supply-chain security following widespread adoption of SBOMs, SLSA, Sigstore, and in-toto frameworks.

Architectural Overview

Core Roles

• Attester
• Verifier
• Relying Party
• Reference Value Provider

Extended Roles

• Federated Claim Normalizer
• Endorsement Distributor
• Provenance Authority
• Federation Coordinator

Federated Trust Architecture

Trust Domains Each ecosystem MAY operate an independent trust domain. Examples include mobile platform vendors, cloud providers, enterprise PKIs, open-source foundations, and hardware manufacturers.

Cross-Domain Verification Federated verifiers MAY validate evidence originating from multiple trust domains. Trust relationships MAY be established through cross-signing, transparency logs, policy registries, threshold trust models, and decentralized trust registries.

Trust Portability A relying party SHOULD be able to evaluate trust equivalence between ecosystems using normalized semantic claims.

Discussion The federated trust model defined in this section is motivated by the operational reality that modern computing environments are inherently multi-domain and multi-stakeholder. Current industry practice already demonstrates partial federation models in adjacent domains including federated identity systems, public key infrastructures, certificate transparency ecosystems, and software package trust systems. Trust domains are introduced to enable independently governed attestation ecosystems while still supporting interoperable verification. Cross-domain verification is motivated by real-world scenarios where relying parties must assess devices or workloads originating outside their direct ecosystem. Trust portability addresses one of the largest operational gaps in current attestation deployments: the inability to express security intent independently of vendor implementation.

Privacy-Preserving Federation

Selective Disclosure Attesters SHOULD support selective disclosure of claims.

Minimization of Persistent Identifiers Attestation evidence MUST NOT require globally stable device identifiers.

Verifier Isolation Federated verifiers SHOULD be isolated from ecosystem-global tracking systems.

Discussion Privacy-preserving federation is motivated by longstanding concerns that attestation systems can become de facto device tracking infrastructures. Industry practice increasingly recognizes that attestation must balance trust establishment with user privacy. Selective disclosure mechanisms are motivated by the principle of least privilege. Minimization of persistent identifiers reflects broader industry migration away from stable hardware identity exposure. Verifier isolation is motivated by concerns that centralized verification infrastructures can aggregate cross-service behavioral data.

Decentralized Endorsement Distribution

Distributed Endorsement Registries Endorsements MAY be distributed using transparency logs, content-addressable storage, distributed ledgers, and signed metadata registries.

Endorsement Objects An endorsement object MAY contain hardware model metadata, firmware measurements, OS build metadata, application signing metadata, revocation status, and provenance bindings.

Discussion Decentralized endorsement distribution is motivated by operational scalability limitations and governance concerns associated with centralized endorsement infrastructures. Industry practice increasingly favors distributed trust metadata systems such as certificate transparency logs, decentralized software repositories, and software transparency systems. Distributed endorsement registries reduce single points of operational failure. Transparency requirements reflect industry movement toward verifiable infrastructure governance. Multi-authority endorsements recognize that no single entity fully controls modern computing stacks.

Decentralized Claim Normalization

Normalized Semantic Claims Normalized claims abstract vendor-specific representations into interoperable semantics. Example Normalized Claims

Normalized Claim	Vendor-Specific Sources
oemboot	Android Verified Boot, Apple Secure Boot
hw_backed_keys	StrongBox, Secure Enclave
app_integrity	Play Integrity, App Attest

Discussion Decentralized claim normalization is motivated by incompatible claim semantics across vendors and ecosystems. Different ecosystems expose similar security properties using incompatible terminology, evidence structures, confidence models, and verification semantics. Normalized semantic claims abstract implementation details into policy-relevant security properties. Layered confidence models reflect the operational reality that attestation strength varies significantly depending on implementation characteristics.

Supply Chain Provenance Integration

Motivation Traditional attestation systems validate runtime integrity but often ignore software provenance.

Provenance Sources The architecture MAY integrate SBOM systems, SLSA provenance, in-toto attestations, Sigstore transparency records, reproducible build verification, and package registry signatures.

Discussion Supply-chain provenance integration is motivated by the growing recognition that runtime integrity alone is insufficient for establishing trustworthy software execution. Recent industry incidents involving compromised build systems, malicious dependencies, package repository attacks, and signed malware have demonstrated that valid runtime attestation may coexist with compromised software provenance. Industry practice has increasingly shifted toward end-to-end software supply-chain verification. Provenance binding enables attestation systems to connect runtime measurements with software lifecycle evidence. Composite trust evaluation reflects common enterprise security practice where trust decisions incorporate multiple dimensions simultaneously.

Composite Attestation Results

Multi-Source Aggregation Composite results MAY combine hardware attestation, OS attestation, application integrity, provenance verification, and enterprise posture assessment.

Policy Evaluation Relying parties MAY define policies over normalized claims.

Discussion Composite attestation results are motivated by the operational reality that modern trust evaluation is inherently multi-dimensional and risk-based. Current industry practice increasingly combines multiple security signals into unified policy engines. Multi-source aggregation recognizes that no individual attestation mechanism provides complete assurance. Federated trust scoring reflects broader industry adoption of probabilistic and weighted trust models.

Security Considerations The architecture introduces security considerations including federation poisoning, normalization ambiguity, transparency log compromise, and provenance forgery.

Privacy Considerations The architecture prioritizes correlation resistance, unlinkability, metadata minimization, and privacy-preserving transparency mechanisms.

IANA Considerations This document requests no IANA actions.

Normative References

Example Claim Normalization Schema

Example Provenance Binding

Threat Model The architecture assumes adversaries MAY attempt endorsement forgery, verifier compromise, federation poisoning, provenance tampering, privacy correlation attacks, and semantic claim manipulation. The architecture is specifically designed to reduce centralized trust concentration, ecosystem lock-in, opaque trust semantics, verifier overreach, and provenance fragmentation.