]> Independent

tho.ietf@gmail.org

Fraunhofer SIT

henk.birkholz@ietf.contact

Independent

ietf@nritz.com

Arm

paul.howard@arm.com

Security Remote ATtestation ProcedureS RATS ReST This document describes a set of REST APIs that can be used by RATS roles to interact. These APIs facilitate the discovery of a role's capabilities, as well as the negotiation and exchange of RATS Conceptual Messages in several key scenarios, including Evidence gathering, Evidence appraisal, Endorsements and Reference Value management. This document aims to present a useful subset of possible RATS interaction patterns, rather than covering all of them. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction TODO Introduction describes APIs for the appraisal of Evidence. describes APIs for Endorsements and Reference Values management. describes APIs for requesting Evidence from a (composite) Attester, together with a data format for aggregating composite Evidence based on Collection CMWs . The Evidence appraisal and Evidence request APIs are both based on the challenge-response interaction model described in .

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.

Appraisal

Discovery

Stateless Challenge-Response

Stateful Challenge-Response

Synchronous Completion

Asynchronous Completion

Endorsements and Reference Values Management

Discovery

RIM Provisioning

RIM Retrieval, Activation and Deactivation

The Query Object

Activating RIMs

Deactivating RIMs

Retrieving RIMs

Evidence Collection

Discovery

Evidence Format for Composite Evidence

Challenge-Response

Security Considerations TODO Security

IANA Considerations TODO IANA

Normative References Fraunhofer SIT Fraunhofer SIT Huawei Technologies Cisco Systems This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. 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 CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like 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, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. 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. 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.

Collated CDDL

Composite Attestation Token bytes / [2*certs: bytes], * cose.label => cose.values, } uhdrs = {* cose.label => cose.values} cat-collection = { "__cmwc_t" => RATSD-CMWCT, "__ratsd" => [ RATSD-CLAIMS-MEDIATYPE, bytes .cbor ratsd-claims, ], + text => cmw.cbor-record, } RATSD-CLAIMS-PROFILE = "tag:github.com,2026:veraison/ratsd/v2" ratsd-claims = #6.601({ &(eat_profile: 265) => RATSD-CLAIMS-PROFILE, &(eat_nonce: 10) => bytes .size (8 .. 64), &(oemid: 258) => eat.oemid-pen / eat.oemid-ieee / eat.oemid-\ random, &(sw-name: 270) => text, &(sw-version: 271) => eat.sw-version-type, ? ( &(nonce_adjust_function: -65537) => \ nonce_adjust_function_type, &(nonce_adjust_map: -65538) => {+ text => uint}, ), }) nonce_adjust_function_type /= "shake-128" / "shake-256" RATSD-CLAIMS-MEDIATYPE = ("application/eat-ucs+cbor; eat_profile=\"\ " .cat RATSD-CLAIMS-PROFILE) .cat "\"" RATSD-CMWCT = "tag:github.com,2025:veraison/ratsd/cmw/v2" cose.label = int / tstr cose.values = any cbor-record = cmw.cbor-record cmw.cbor-record = [ type: cmw.coap-content-format-type / cmw.media-type, value: bytes, ? ind: uint .bits cmw.cm-type, ] cmw.coap-content-format-type = uint .size 2 cmw.media-type = text .abnf ("Content-Type" .cat cmw.Content-Type-\ ABNF) cmw.cm-type = &( reference-values: 0, endorsements: 1, evidence: 2, attestation-results: 3, appraisal-policy: 4, ) cmw.Content-Type-ABNF = ' Content-Type = Media-Type-Name *( *SP ";" *SP parameter ) parameter = token "=" ( token / quoted-string ) token = 1*tchar tchar = "!" / "#" / "$" / "%" / "&" / "\'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA quoted-string = %x22 *( qdtext / quoted-pair ) %x22 qdtext = SP / %x21 / %x23-5B / %x5D-7E quoted-pair = "\\" ( SP / VCHAR ) Media-Type-Name = type-name "/" subtype-name type-name = restricted-name subtype-name = restricted-name restricted-name = restricted-name-first *126restricted-name-chars restricted-name-first = ALPHA / DIGIT restricted-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "-" / "^" / "_" restricted-name-chars =/ "." ; Characters before first dot always ; specify a facet name restricted-name-chars =/ "+" ; Characters after last plus always ; specify a structured syntax suffix DIGIT = %x30-39 ; 0 - 9 POS-DIGIT = %x31-39 ; 1 - 9 ALPHA = %x41-5A / %x61-7A ; A - Z / a - z SP = %x20 VCHAR = %x21-7E ; printable ASCII (no SP) ' sw-version-type = eat.sw-version-type eat.sw-version-type = [ version: tstr, ? scheme: $version-scheme, ] eat.oemid-pen = int eat.oemid-ieee = eat.JC eat.oemid-random = eat.JC eat.JC = eat.JSON-ONLY / eat.CBOR-ONLY eat.JSON-ONLY = J .feature "json" eat.CBOR-ONLY = C .feature "cbor" eat.oemid-ieee-json = tstr .b64u eat.oemid-ieee-cbor eat.oemid-ieee-cbor = bstr .size 3 eat.oemid-random-json = tstr .b64u eat.oemid-random-cbor eat.oemid-random-cbor = bstr .size 16 oemid-pen = eat.oemid-pen oemid-ieee = eat.oemid-ieee oemid-random = eat.oemid-random ]]>

OpenAPI Schema TODO openapi

Acknowledgments The APIs described in this document were designed and prototyped as part of the Veraison project over the past few years. The authors would like to thank the Veraison community, and in particular Dhanus M Lal, Ding Ma, Ian Chin Wang, Ian Oliver, Jag Raman, Sergei Trofimov, Shefali Kamal, Simon Frost and Yogesh Deshpande, for their invaluable contributions.