]> Fraunhofer SIT

henk.birkholz@sit.fraunhofer.de

Intel

ned.smith@intel.com

arm

thomas.fossati@arm.com

hannes.tschofenig@gmx.net

Security Remote ATtestation ProcedureS evidence attestation result endorsement reference value This document defines two encapsulation formats for RATS conceptual messages (i.e., evidence, attestation results, endorsements and reference values.) The first format uses a CBOR or JSON array with two members: one for the type, another for the value. The other format wraps the value in a CBOR byte string and prepends a CBOR tag to convey the type information. Discussion Venues Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The RATS architecture defines a handful of conceptual messages (see ), such as evidence and attestation results. Each conceptual message can have multiple claims encoding and serialization formats (). Such serialized messages may have to be transported via different protocols - for example, evidence using an EAT encoding serialized as a CBOR payload in a "background check" topological arrangement, or attestation results as Attestation Results for Secure Interactions (AR4SI) payloads in "passport" mode. In order to minimize the cost associated with registration and maximize interoperability, it is desirable to reuse their typing information across such boundaries. This document defines two encapsulation formats for RATS conceptual messages that aim to achieve the goals stated above. These encapsulation formats are designed to be:

• Self-describing - which removes the dependency on the framing provided by the embedding protocol (or the storage system) to convey exact typing information.
• Based on media types - which allows amortising their registration cost across many different usage scenarios.

A protocol designer could use these formats, for example, to convey evidence, endorsements or reference values in certificates and CRLs extensions (), to embed attestation results or evidence as first class authentication credentials in TLS handshake messages , to transport attestation-related payloads in RESTful APIs, or for stable storage of attestation results in form of file system objects.

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. In this document, CDDL is used to describe the data formats. The reader is assumed to be familiar with the vocabulary and concepts defined in . This document reuses the terms defined in (e.g., "Content-Type").

Conceptual Message Wrapper Encodings Two types of RATS Conceptual Message Wrapper (CMW) are specified in this document:

1. A CMW using a CBOR or JSON array ();
2. A CMW based on CBOR tags ().

CMW Array The CMW array format is defined in . (To improve clarity, the Content-Type ABNF is defined separately in .)

CDDL definition of the Array format

It is composed of two members:

type:

Either a text string representing a Content-Type (e.g., an EAT media type ) or an unsigned Integer corresponding to a CoAP Content-Format number (.

value:

The RATS conceptual message serialized according to the value defined in the type member.

A CMW array can be encoded as CBOR or JSON . When using JSON, the value field is encoded as Base64 using the URL and filename safe alphabet (Section 5 of ) without padding. When using CBOR, the value field is encoded as a CBOR byte string.

CMW CBOR Tags CBOR Tags used as CMW are derived from CoAP Content-Format numbers. If a CoAP content format exists for a RATS conceptual message, the TN() transform defined in can be used to derive a corresponding CBOR tag in range [1668546817, 1668612095]. The RATS conceptual message is first serialized according to the Content-Format number associated with the CBOR tag and then encoded as a CBOR byte string, to which the tag is prepended. The CMW CBOR Tag is defined in .

CDDL definition of the CBOR Tag format = #6.(bytes) coap-cf-tag-number = 1668546817..1668612095 ]]>

Use of Pre-existing CBOR Tags If a CBOR tag has been registered in association with a certain RATS conceptual message independently of a CoAP content format (i.e., it is not obtained by applying the TN() transform), it can be readily used as an encapsulation without the extra processing described in . A consumer can always distinguish tags that have been derived via TN(), which all fall in the [1668546817, 1668612095] range, from tags that are not, and therefore apply the right decapsulation on receive.

Decapsulation Algorithm After removing any external framing (for example, the ASN.1 OCTET STRING if the CMW is carried in a certificate extension ), the CMW decoder does a 1-byte lookahead, as illustrated in the following pseudo code, to decide how to decode the remainder of the byte buffer:

Examples The (equivalent) examples below assume the Media-Type-Name application/vnd.example.rats-conceptual-msg has been registered alongside a corresponding CoAP Content-Format number 30001. The CBOR tag 1668576818 is derived applying the TN() transform as described in .

JSON Array

CBOR Array with the following wire representation:

CBOR Tag with the following wire representation:

Registering a Media Type for Evidence Note: Not sure whether this advice should go. When registering a new media type for evidence, in addition to its syntactical description, the author SHOULD provide a public and stable description of the signing and appraisal procedures associated with the data format.

Security Considerations This document defines two encapsulation formats for RATS conceptual messages. The messages themselves and their encoding ensure security protection. For this reason there are no further security requirements raised by the introduction of this encapsulation. Changing the encapsulation of a payload by an adversary will result in incorrect processing of the encapsulated messages and this will subsequently lead to a processing error.

IANA Considerations This document does not make any requests to IANA.

References Normative References This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed: , , and for the construction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and for indicating the use of a non-basic feature in an instance. This document defines a stored ("file") format for Concise Binary Object Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. 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. Informative References The Sensor Measurement Lists (SenML) media types support multiple types of values, from numbers to text strings and arbitrary binary Data Values. In order to facilitate processing of binary Data Values, this document specifies a pair of new SenML fields for indicating the content format of those binary Data Values, i.e., their Internet media type, including parameters as well as any content codings applied. 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 Theory LLC Qualcomm Technologies Inc. Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine how much it wishes to trust the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. Security Theory LLC Fraunhofer Institute for Secure Information Technology arm Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EAT). Cisco Systems Fraunhofer SIT MIT Arm Limited Intel This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. Arm Limited Arm Limited Arm Limited Arm Limited Arm Limited Attestation is the process by which an entity produces evidence about itself that another party can use to evaluate the trustworthiness of that entity. In use cases that require the use of remote attestation, such as confidential computing or device onboarding, an attester has to convey evidence or attestation results to a relying party. This information exchange may happen at different layers in the protocol stack. This specification provides a generic way of passing evidence and attestation results in the TLS handshake. Functionality-wise this is accomplished with the help of key attestation. Trusted Computing Group

RFC9193 ABNF

Open Issues Note to RFC Editor: please remove before publication. The list of currently open issues for this documents can be found at .

Acknowledgments The authors would like to thank Carl Wallace and Carsten Bormann for their reviews and suggestions.