]> Fraunhofer SIT

henk.birkholz@sit.fraunhofer.de

Intel

ned.smith@intel.com

Linaro

thomas.fossati@linaro.org

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 encapsulation format uses a CBOR or JSON array with two mandatory members, one for the type, another for the value, and a third optional member complementing the type field that says which kind of conceptual message(s) are carried in the value. The other format wraps the value in a CBOR byte string and prepends a CBOR tag to convey the type information. This document also defines a corresponding CBOR tag, as well as JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims. These allow embedding the wrapped conceptual messages into CBOR-based protocols and web APIs, respectively. 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 (). Throughout their lifetime, RATS conceptual messages are typically transported over different protocols. For example,

• EAT Evidence in a "background check" topological arrangement first flows from Attester to Relying Party, and then from Relying Party to Verifier, over separate protocol legs.
• Attestation Results for Secure Interactions (AR4SI) payloads in "passport" mode would be sent by the Verifier to the Attester and then, at a later point in time and over a different channel, from the Attester to the Relying Party.

It is desirable to reuse any typing information associated with the messages across such protocol boundaries to minimize the cost associated with type registrations and maximize interoperability. With the CMW format described in this document, protocol designers do not need to update protocol specifications to support different conceptual messages. This approach reduces the implementation effort for developers to support different attestation technologies. For example, an implementer of a Relying Party application does not need to parse attestation-related conceptual messages, such as different Evidence formats, but can instead utilize the CMW format to be agnostic to the attestation technology. This document defines two encapsulation formats for RATS conceptual messages that aim to achieve the goals stated above. These encapsulation formats have been specifically designed to possess the following characteristics:

• They are self-describing, which means that they can convey precise typing information without relying on the framing provided by the embedding protocol or the storage system.
• They are based on media types , which allows the cost of their registration to be spread across numerous usage scenarios.

A protocol designer could use these formats, for example, to convey Evidence, Endorsements and 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 the 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 ().

A further CMW "collection" type that holds together multiple CMW items is defined in . The collected CDDL is in .

CMW Array The CMW array format is defined in . The CDDL generic JC<> is used where there is a variance between CBOR and JSON. The first argument is the CDDL for JSON and the second is the CDDL for CBOR.

CDDL definition of the Array format ? ind: uint .bits cm-type ] coap-content-format = uint .size 2 media-type = text .abnf ("Content-Type" .cat Content-Type-ABNF) base64-string = text .regexp "[A-Za-z0-9_-]+" cm-type = &( reference-values: 0 endorsements: 1 evidence: 2 attestation-results: 3 ) ]]>

It is composed of three 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.

ind:

An optional bitmap that indicates which conceptual message types are carried in the value field. Any combination (i.e., any value between 1 and 15, included) is allowed. This is useful only if the type is potentially ambiguous and there is no further context available to the CMW consumer to decide. For example, this might be the case if the base media type is not profiled (e.g., application/eat+cwt), if the value field contains multiple conceptual messages with different types (e.g., both Reference Values and Endorsements within the same application/signed-corim+cbor), or if the same profile identifier is shared by different conceptual messages. Future specifications may add new values to the ind field; see .

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 () without padding. When using CBOR, the value field is encoded as a CBOR byte string.

CMW CBOR Tags CBOR Tags used as CMW may be 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) cbor-tag-numbers = 0..18446744073709551615 ]]>

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: = 0xc0 && b[0] <= 0xdb { return CBORTag } else if b[0] == 0x5b { return JSONArray } return Unknown } ]]>

CMW Collections Layered Attesters and composite devices (Sections and of ) generate Evidence that consists of multiple parts. For example, in data center servers, it is not uncommon for separate attesting environments (AE) to serve a subsection of the entire machine. One AE might measure and attest to what was booted on the main CPU, while another AE might measure and attest to what was booted on a SmartNIC plugged into a PCIe slot, and a third AE might measure and attest to what was booted on the machine's GPU. To address the composite Attester use case, this document defines a CMW "collection" as a container that holds several CMW items, each with a label that is unique within the scope of the collection. The CMW collection () is defined as a CBOR map or JSON object with CMW values. The position of a cmw entry in the cmw-collection is not significant. Instead, the labels identify a conceptual message that, in the case of a composite Attester, should typically correspond to a component of a system. Labels can be strings or integers that serve as a mnemonic for different conceptual messages in the collection.

CDDL definition of the CMW collection format cmw } cmw-collection-entry-label = text / int .feature "cbor" ]]>

Although initially designed for the composite Attester use case, the CMW collection can be repurposed for other use cases requiring CMW aggregation.

Examples The (equivalent) examples in , , and assume that 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 . The example in is a signed CoRIM payload with an explicit CM indicator 0b0000_0011 (3), meaning that the wrapped message contains both Reference Values and Endorsements.

JSON Array Note that a CoAP Content-Format number can also be used with the JSON array form. That may be the case when it is known that the receiver can handle CoAP Content-Formats and it is crucial to save bytes.

CBOR Array with the following wire representation: Note that a Media-Type-Name can also be used with the CBOR array form, for example if it is known that the receiver cannot handle CoAP Content-Formats, or (unlike the case in point) if a CoAP Content-Format number has not been registrered.

CBOR Tag with the following wire representation:

CBOR Array with explicit CM indicator with the following wire representation:

Transporting CMW and CMW Collections in X.509 Messages There are cases where CMW and CMW collection payloads need to be transported in PKIX messages, for example in Certificate Signing Requests (CSRs) , or in X.509 Certificates and Certificate Revocation Lists (CRLs) . For CMW, Section 6.1.8 of already defines the ConceptualMessageWrapper format and the associated object identifier. This section specifies the CMWCollection extension to carry CMW collection objects. The CMWCollection extension MAY be included in X.509 Certificates, CRLs , and CSRs. The CMWCollection extension MUST be identified by the following object identifier: This extension MUST NOT be marked critical. The CMWCollection extension MUST have the following syntax: The CMWCollection MUST contain the serialized CMW collection object in JSON or CBOR format, using the appropriate CHOICE entry.

ASN.1 Module This section provides an ASN.1 module for the CMWCollection extension, following the conventions established in and .

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Project Veraison The organization responsible for this implementation is Project Veraison, a Linux Foundation project hosted at the Confidential Computing Consortium. The software, hosted at , provides a Golang package that allows encoding and decoding of CMW payloads. The implementation covers all the features presented in this draft. The maturity level is alpha. The license is Apache 2.0. The developers can be contacted on the Zulip channel: .

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 RFC Editor: replace "RFCthis" with the RFC number assigned to this document.

CWT cmw Claim Registration IANA is requested to add a new cmw claim to the "CBOR Web Token (CWT) Claims" registry as follows:

• Claim Name: cmw
• Claim Description: A RATS Conceptual Message Wrapper
• Claim Key: TBD
• Claim Value Type(s): CBOR Array, or CBOR Tag
• Change Controller: IETF
• Specification Document(s): and of RFCthis

The suggested value for the Claim Key is 299.

JWT cmw Claim Registration IANA is requested to add a new cmw claim to the "JSON Web Token Claims" sub-registry of the "JSON Web Token (JWT)" registry as follows:

• Claim Name: cmw
• Claim Description: A RATS Conceptual Message Wrapper
• Claim Value Type(s): JSON Array
• Change Controller: IETF
• Specification Document(s): of RFCthis

CBOR Tag Registration IANA is requested to add the following tag to the "CBOR Tags" registry.

CBOR Tag	Data Item	Semantics	Reference
TBD	CBOR array, CBOR tag	RATS Conceptual Message Wrapper	and of RFCthis

RATS Conceptual Message Wrapper (CMW) Indicators Registry This specification defines a new "RATS Conceptual Message Wrapper (CMW) Indicators" registry, with the policy "Expert Review" (). The objective is to have Indicators values registered for all RATS Conceptual Messages ().

Instructions for the Designated Expert The expert is instructed to add the values incrementally. Acceptable values are those corresponding to RATS Conceptual Messages defined by the RATS architecture and any of its updates.

Structure of Entries Each entry in the registry must include:

Indicator value:

A number corresponding to the bit position in the cm-ind bitmap.

Conceptual Message name:

A text string describing the RATS conceptual message this indicator corresponds to.

Reference:

A reference to a document, if available, or the registrant.

The initial registrations for the registry are detailed in . CMW Indicators Registry Initial Contents

Indicator value	Conceptual Message name	Reference
0	Reference Values	RFCthis
1	Endorsements	RFCthis
2	Evidence	RFCthis
3	Attestation Results	RFCthis

Media Types IANA is requested to add the following media types to the "Media Types" registry . CMW Media Types

Name	Template	Reference
cmw+cbor	application/cmw+cbor	and of RFCthis
cmw+json	application/cmw+json	of RFCthis
cmw-collection+cbor	application/cmw-collection+cbor	of RFCthis
cmw-collection+json	application/cmw-collection+json	of RFCthis

application/cmw+cbor

Type name:

application

Subtype name:

cmw+cbor

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary (CBOR)

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer CMW payloads over HTTP(S), CoAP(S), and other transports.

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/cbor". (No fragment identification syntax is currently defined for "application/cbor".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

application/cmw+json

Type name:

application

Subtype name:

cmw+json

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary (JSON is UTF-8-encoded text)

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer CMW payloads over HTTP(S), CoAP(S), and other transports.

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/json". (No fragment identification syntax is currently defined for "application/json".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

application/cmw-collection+cbor

Type name:

application

Subtype name:

cmw-collection+cbor

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary (CBOR)

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer collections of CMW payloads over HTTP(S), CoAP(S), and other transports.

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/cbor". (No fragment identification syntax is currently defined for "application/cbor".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

application/cmw-collection+json

Type name:

application

Subtype name:

cmw-collection+json

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary (JSON is UTF-8-encoded text)

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Attesters, Verifiers, Endorsers and Reference-Value providers, Relying Parties that need to transfer collections of CMW payloads over HTTP(S), CoAP(S), and other transports.

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/json". (No fragment identification syntax is currently defined for "application/json".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

New SMI Numbers Registrations IANA is requested to assign an object identifier (OID) for the CMWCollection extension defined in in the "Certificate Extension" sub-registry of the "SMI Numbers" registry. IANA is requested to assign an object identifier (OID) for the ASN.1 Module defined in in the "Module Identifier" sub-registry of the "SMI Numbers" registry.

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 memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. 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. IANA IANA Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. International Telephone and Telegraph Consultative Committee 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. IANA IANA IANA Informative References This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. 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. 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 the type and degree of trust placed in 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 Linaro 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. Intuit 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. Entrust Limited Siemens Fraunhofer SIT A client requesting a certificate from a Certification Authority (CA) may wish to offer believable claims about the protections afforded to the corresponding private key, such as whether the private key resides on a hardware security module or the protection capabilities provided by the hardware. This document describes how to encode Evidence produced by an Attester for inclusion in Certificate Signing Requests (CSRs), and any certificates necessary for validating it. Including Evidence along with a CSR can help to improve the assessment of the security posture for the private key, and the trustworthiness properties of the submitted key to the requested certificate profile. These Evidence Claims can include information about the hardware component's manufacturer, the version of installed or running firmware, the version of software installed or running in layers above the firmware, or the presence of hardware components providing specific protection capabilities or shielded locations (e.g., to protect keys). Trusted Computing Group

Collected CDDL .feature "cbor" cmw-array = [ type: coap-content-format / media-type value: JC ? ind: uint .bits cm-type ] coap-content-format = uint .size 2 media-type = text .abnf ("Content-Type" .cat Content-Type-ABNF) base64-string = text .regexp "[A-Za-z0-9_-]+" cm-type = &( reference-values: 0 endorsements: 1 evidence: 2 attestation-results: 3 ) cmw-cbor-tag = #6.(bytes) cbor-tag-numbers = 0..18446744073709551615 cmw-collection = { + cmw-collection-entry-label => cmw } cmw-collection-entry-label = text / int .feature "cbor" ; from RFC9193 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) ' JSON-ONLY = J .feature "json" CBOR-ONLY = C .feature "cbor" JC = JSON-ONLY / CBOR-ONLY ]]>

Registering and Using CMWs describes the registration preconditions for using CMWs in either array or CBOR tag forms.

How To CMW

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

Acknowledgments The authors would like to thank Carl Wallace and Carsten Bormann for their reviews and suggestions. The definition of a CMW collection has been modelled on a proposal originally made by Simon Frost for an EAT-based Evidence collection type. The CMW collection intentionally attains binary compatibility with Simon's design and aims at superseding it by also generalizing on the allowed Evidence formats.