Remote ATtestation ProcedureS H. Birkholz Internet-Draft Fraunhofer SIT Intended status: Standards Track N. Smith Expires: 2 August 2024 Intel T. Fossati Linaro H. Tschofenig 30 January 2024 RATS Conceptual Messages Wrapper (CMW) draft-ietf-rats-msg-wrap-03 Abstract 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 This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-ftbs-rats-msg-wrap. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Birkholz, et al. Expires 2 August 2024 [Page 1] Internet-Draft RATS CMW January 2024 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." This Internet-Draft will expire on 2 August 2024. Copyright Notice Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Conceptual Message Wrapper Encodings . . . . . . . . . . . . 4 3.1. CMW Array . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. CMW CBOR Tags . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Use of Pre-existing CBOR Tags . . . . . . . . . . . . 6 3.3. Decapsulation Algorithm . . . . . . . . . . . . . . . . . 7 3.4. CMW Collections . . . . . . . . . . . . . . . . . . . . . 7 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. JSON Array . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. CBOR Array . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. CBOR Tag . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. CBOR Array with explicit CM indicator . . . . . . . . . . 9 5. Transporting CMW and CMW Collections in X.509 Messages . . . 10 5.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 10 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 6.1. Project Veraison . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8.1. CWT cmw Claim Registration . . . . . . . . . . . . . . . 12 Birkholz, et al. Expires 2 August 2024 [Page 2] Internet-Draft RATS CMW January 2024 8.2. JWT cmw Claim Registration . . . . . . . . . . . . . . . 13 8.3. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 13 8.4. RATS Conceptual Message Wrapper (CMW) Indicators Registry . . . . . . . . . . . . . . . . . . . . . . . . 13 8.4.1. Instructions for the Designated Expert . . . . . . . 14 8.4.2. Structure of Entries . . . . . . . . . . . . . . . . 14 8.5. Media Types . . . . . . . . . . . . . . . . . . . . . . . 14 8.5.1. application/cmw+cbor . . . . . . . . . . . . . . . . 15 8.5.2. application/cmw+json . . . . . . . . . . . . . . . . 15 8.5.3. application/cmw-collection+cbor . . . . . . . . . . . 16 8.5.4. application/cmw-collection+json . . . . . . . . . . . 17 8.6. New SMI Numbers Registrations . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Collected CDDL . . . . . . . . . . . . . . . . . . . 21 Appendix B. Registering and Using CMWs . . . . . . . . . . . . . 22 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 23 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction The RATS architecture defines a handful of conceptual messages (see Section 8 of [RFC9334]), such as Evidence and Attestation Results. Each conceptual message can have multiple claims encoding and serialization formats (Section 9 of [RFC9334]). Throughout their lifetime, RATS conceptual messages are typically transported over different protocols. For example, * EAT [I-D.ietf-rats-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) [I-D.ietf-rats-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 Birkholz, et al. Expires 2 August 2024 [Page 3] Internet-Draft RATS CMW January 2024 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 [RFC6838], 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 ([DICE-arch]), to embed Attestation Results or Evidence as first-class authentication credentials in TLS handshake messages [I-D.fossati-tls-attestation], to transport attestation-related payloads in RESTful APIs, or for stable storage of Attestation Results in the form of file system objects. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. In this document, CDDL [RFC8610] [RFC9165] is used to describe the data formats. The reader is assumed to be familiar with the vocabulary and concepts defined in [RFC9334]. This document reuses the terms defined in Section 2 of [RFC9193] (e.g., "Content-Type"). 3. Conceptual Message Wrapper Encodings Two types of RATS Conceptual Message Wrapper (CMW) are specified in this document: Birkholz, et al. Expires 2 August 2024 [Page 4] Internet-Draft RATS CMW January 2024 1. A CMW using a CBOR or JSON array (Section 3.1); 2. A CMW based on CBOR tags (Section 3.2). A further CMW "collection" type that holds together multiple CMW items is defined in Section 3.4. The collected CDDL is in Appendix A. 3.1. CMW Array The CMW array format is defined in Figure 1. 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. 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 ) Figure 1: CDDL definition of the Array format It is composed of three members: type: Either a text string representing a Content-Type (e.g., an EAT media type [I-D.ietf-rats-eat-media-type]) or an unsigned integer corresponding to a CoAP Content-Format number (Section 12.3 of [RFC7252]). value: The RATS conceptual message serialized according to the value defined in the type member. Birkholz, et al. Expires 2 August 2024 [Page 5] Internet-Draft RATS CMW January 2024 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 Section 8.4. A CMW array can be encoded as CBOR [STD94] or JSON [STD90]. When using JSON, the value field is encoded as Base64 using the URL and filename safe alphabet (Section 5 of [RFC4648]) without padding. When using CBOR, the value field is encoded as a CBOR byte string. 3.2. 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 Appendix B of [RFC9277] 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 Figure 2. cmw-cbor-tag = #6.(bytes) cbor-tag-numbers = 0..18446744073709551615 Figure 2: CDDL definition of the CBOR Tag format 3.2.1. 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 Section 3.2. Birkholz, et al. Expires 2 August 2024 [Page 6] Internet-Draft RATS CMW January 2024 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. 3.3. Decapsulation Algorithm After removing any external framing (for example, the ASN.1 OCTET STRING if the CMW is carried in a certificate extension [DICE-arch]), 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: func CMWTypeSniff(b []byte) (CMW, error) { if len(b) == 0 { return Unknown } if b[0] == 0x82 || b[0] == 0x83 { return CBORArray } else if b[0] >= 0xc0 && b[0] <= 0xdb { return CBORTag } else if b[0] == 0x5b { return JSONArray } return Unknown } 3.4. CMW Collections Layered Attesters and composite devices (Sections 3.2 and 3.3 of [RFC9334]) 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 (Figure 3) 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 Birkholz, et al. Expires 2 August 2024 [Page 7] Internet-Draft RATS CMW January 2024 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. cmw-collection = { + cmw-collection-entry-label => cmw } cmw-collection-entry-label = text / int .feature "cbor" Figure 3: CDDL definition of the CMW collection format Although initially designed for the composite Attester use case, the CMW collection can be repurposed for other use cases requiring CMW aggregation. 4. Examples The (equivalent) examples in Section 4.1, Section 4.2, and Section 4.3 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 Section 3.2. The example in Section 4.4 is a signed CoRIM payload with an explicit CM indicator 0b0000_0011 (3), meaning that the wrapped message contains both Reference Values and Endorsements. 4.1. JSON Array [ "application/vnd.example.rats-conceptual-msg", "q82rzQ" ] 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. 4.2. CBOR Array [ 30001, h'2347da55' ] with the following wire representation: Birkholz, et al. Expires 2 August 2024 [Page 8] Internet-Draft RATS CMW January 2024 82 # array(2) 19 7531 # unsigned(30001) 44 # bytes(4) 2347da55 # "#G\xDAU" 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. [ "application/vnd.example.rats-conceptual-msg", h'2347da55' ] 4.3. CBOR Tag 1668576818(h'2347da55') with the following wire representation: da 63747632 # tag(1668576818) 44 # bytes(4) 2347da55 # "#G\xDAU" 4.4. CBOR Array with explicit CM indicator [ "application/signed-corim+cbor", h'd28443a10126a1', 3 ] with the following wire representation: 83 # array(3) 78 1d # text(29) 6170706c69636174696f6e2f7369676e65642d636f72696d2b63626f72 # "application/signed-corim+cbor" 47 # bytes(7) d28443a10126a1 # "҄C\xA1\u0001&\xA1" 03 # unsigned(3) Birkholz, et al. Expires 2 August 2024 [Page 9] Internet-Draft RATS CMW January 2024 5. 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) [I-D.ietf-lamps-csr-attestation], or in X.509 Certificates and Certificate Revocation Lists (CRLs) [DICE-arch]. For CMW, Section 6.1.8 of [DICE-arch] 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 [RFC5280], and CSRs. The CMWCollection extension MUST be identified by the following object identifier: id-pe-cmw-collection OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-pe(1) TBD } This extension MUST NOT be marked critical. The CMWCollection extension MUST have the following syntax: CMWCollection ::= CHOICE { json UTF8String, cbor OCTET STRING, } The CMWCollection MUST contain the serialized CMW collection object in JSON or CBOR format, using the appropriate CHOICE entry. 5.1. ASN.1 Module This section provides an ASN.1 module [X.680] for the CMWCollection extension, following the conventions established in [RFC5912] and [RFC6268]. Birkholz, et al. Expires 2 August 2024 [Page 10] Internet-Draft RATS CMW January 2024 CMWCollectionExtn { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmw-collection-extn(TBD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS EXTENSION FROM PKIX-CommonTypes-2009 -- RFC 5912 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; -- CMWCollection Extension ext-CMWCollection EXTENSION ::= { SYNTAX CMWCollection IDENTIFIED BY id-pe-cmw-collection } -- CMWCollection Extension OID id-pe-cmw-collection OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-pe(1) TBD } -- CMWCollection Extension Syntax CMWCollection ::= CHOICE { json UTF8String, cbor OCTET STRING, } END 6. 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 [RFC7942]. 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 Birkholz, et al. Expires 2 August 2024 [Page 11] Internet-Draft RATS CMW January 2024 features. Readers are advised to note that other implementations may exist. According to [RFC7942], "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". 6.1. 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 https://github.com/veraison/cmw, 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: https://veraison.zulipchat.com/#narrow/stream/383526-CMW/. 7. 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. 8. IANA Considerations // RFC Editor: replace "RFCthis" with the RFC number assigned to this document. 8.1. CWT cmw Claim Registration IANA is requested to add a new cmw claim to the "CBOR Web Token (CWT) Claims" registry [IANA.cwt] as follows: * Claim Name: cmw * Claim Description: A RATS Conceptual Message Wrapper Birkholz, et al. Expires 2 August 2024 [Page 12] Internet-Draft RATS CMW January 2024 * Claim Key: TBD * Claim Value Type(s): CBOR Array, or CBOR Tag * Change Controller: IETF * Specification Document(s): Section 3.1 and Section 3.2 of RFCthis The suggested value for the Claim Key is 299. 8.2. 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 [IANA.jwt] as follows: * Claim Name: cmw * Claim Description: A RATS Conceptual Message Wrapper * Claim Value Type(s): JSON Array * Change Controller: IETF * Specification Document(s): Section 3.1 of RFCthis 8.3. CBOR Tag Registration IANA is requested to add the following tag to the "CBOR Tags" [IANA.cbor-tags] registry. +==========+=============+=================+========================+ | CBOR | Data Item | Semantics | Reference | | Tag | | | | +==========+=============+=================+========================+ | TBD | CBOR array, | RATS Conceptual | Section 3.1 and | | | CBOR tag | Message Wrapper | Section 3.2 of RFCthis | +----------+-------------+-----------------+------------------------+ Table 1 8.4. RATS Conceptual Message Wrapper (CMW) Indicators Registry This specification defines a new "RATS Conceptual Message Wrapper (CMW) Indicators" registry, with the policy "Expert Review" (Section 4.5 of [BCP26]). Birkholz, et al. Expires 2 August 2024 [Page 13] Internet-Draft RATS CMW January 2024 The objective is to have Indicators values registered for all RATS Conceptual Messages (Section 8 of [RFC9334]). 8.4.1. 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 [RFC9334] and any of its updates. 8.4.2. 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 Table 2. +=================+=========================+===========+ | Indicator value | Conceptual Message name | Reference | +=================+=========================+===========+ | 0 | Reference Values | RFCthis | +-----------------+-------------------------+-----------+ | 1 | Endorsements | RFCthis | +-----------------+-------------------------+-----------+ | 2 | Evidence | RFCthis | +-----------------+-------------------------+-----------+ | 3 | Attestation Results | RFCthis | +-----------------+-------------------------+-----------+ Table 2: CMW Indicators Registry Initial Contents 8.5. Media Types IANA is requested to add the following media types to the "Media Types" registry [IANA.media-types]. Birkholz, et al. Expires 2 August 2024 [Page 14] Internet-Draft RATS CMW January 2024 +=====================+=====================+=================+ | Name | Template | Reference | +=====================+=====================+=================+ | cmw+cbor | application/ | Section 3.1 and | | | cmw+cbor | Section 3.2 of | | | | RFCthis | +---------------------+---------------------+-----------------+ | cmw+json | application/ | Section 3.1 of | | | cmw+json | RFCthis | +---------------------+---------------------+-----------------+ | cmw-collection+cbor | application/cmw- | Section 3.4 of | | | collection+cbor | RFCthis | +---------------------+---------------------+-----------------+ | cmw-collection+json | application/cmw- | Section 3.4 of | | | collection+json | RFCthis | +---------------------+---------------------+-----------------+ Table 3: CMW Media Types 8.5.1. application/cmw+cbor Type name: application Subtype name: cmw+cbor Required parameters: n/a Optional parameters: n/a Encoding considerations: binary (CBOR) Security considerations: Section 7 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 8.5.2. application/cmw+json Type name: application Subtype name: cmw+json Birkholz, et al. Expires 2 August 2024 [Page 15] Internet-Draft RATS CMW January 2024 Required parameters: n/a Optional parameters: n/a Encoding considerations: binary (JSON is UTF-8-encoded text) Security considerations: Section 7 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 8.5.3. 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: Section 7 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 Birkholz, et al. Expires 2 August 2024 [Page 16] Internet-Draft RATS CMW January 2024 8.5.4. 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: Section 7 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 8.6. New SMI Numbers Registrations IANA is requested to assign an object identifier (OID) for the CMWCollection extension defined in Section 5 in the "Certificate Extension" sub-registry of the "SMI Numbers" [IANA.smi-numbers] registry. IANA is requested to assign an object identifier (OID) for the ASN.1 Module defined in Section 5.1 in the "Module Identifier" sub-registry of the "SMI Numbers" [IANA.smi-numbers] registry. 9. References 9.1. Normative References [BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [IANA.cbor-tags] IANA, "Concise Binary Object Representation (CBOR) Tags", . Birkholz, et al. Expires 2 August 2024 [Page 17] Internet-Draft RATS CMW January 2024 [IANA.cwt] IANA, "CBOR Web Token (CWT) Claims", . [IANA.jwt] IANA, "JSON Web Token (JWT)", . [IANA.media-types] IANA, "Media Types", . [IANA.smi-numbers] IANA, "Structure of Management Information (SMI) Numbers (MIB Module Registrations)", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, . [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . Birkholz, et al. Expires 2 August 2024 [Page 18] Internet-Draft RATS CMW January 2024 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC9165] Bormann, C., "Additional Control Operators for the Concise Data Definition Language (CDDL)", RFC 9165, DOI 10.17487/RFC9165, December 2021, . [RFC9277] Richardson, M. and C. Bormann, "On Stable Storage for Items in Concise Binary Object Representation (CBOR)", RFC 9277, DOI 10.17487/RFC9277, August 2022, . [STD90] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [STD94] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [X.680] International Telephone and Telegraph Consultative Committee, "Specification of Abstract Syntax Notation One (ASN.1): Specification of Basic Notation", CCITT Recommendation X.680, July 1994. 9.2. Informative References [DICE-arch] Trusted Computing Group, "DICE Attestation Architecture", January 2024, . Birkholz, et al. Expires 2 August 2024 [Page 19] Internet-Draft RATS CMW January 2024 [I-D.fossati-tls-attestation] Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I., and Y. Deshpande, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati- tls-attestation-04, 23 October 2023, . [I-D.ietf-lamps-csr-attestation] Ounsworth, M., Tschofenig, H., and H. Birkholz, "Use of Remote Attestation with Certificate Signing Requests", Work in Progress, Internet-Draft, draft-ietf-lamps-csr- attestation-02, 9 October 2023, . [I-D.ietf-rats-ar4si] Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V. Scarlata, "Attestation Results for Secure Interactions", Work in Progress, Internet-Draft, draft-ietf-rats-ar4si- 05, 30 August 2023, . [I-D.ietf-rats-eat] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", Work in Progress, Internet-Draft, draft-ietf-rats-eat-25, 15 January 2024, . [I-D.ietf-rats-eat-media-type] Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media Types", Work in Progress, Internet-Draft, draft-ietf-rats- eat-media-type-05, 7 November 2023, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC9193] Keränen, A. and C. Bormann, "Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format", RFC 9193, DOI 10.17487/RFC9193, June 2022, . Birkholz, et al. Expires 2 August 2024 [Page 20] Internet-Draft RATS CMW January 2024 [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . Appendix A. Collected CDDL cmw = cmw-array / cmw-cbor-tag .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 Birkholz, et al. Expires 2 August 2024 [Page 21] Internet-Draft RATS CMW January 2024 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 Appendix B. Registering and Using CMWs Figure 4 describes the registration preconditions for using CMWs in either array or CBOR tag forms. Birkholz, et al. Expires 2 August 2024 [Page 22] Internet-Draft RATS CMW January 2024 .---------------. .---------. | Reuse EAT/CoRIM | | Register | | media type(s) | | new media | | + profile | | type | `---+----+------' `-+----+--' | | | | | .-+------------+-. | | | | Register | | | .-(-+-' new CoAP `-+-(-. | | | Content-Format | | | | | `-------+--------' | | | | | | | | | v | | | | .--------------. | | .--------. | | | Automatically | | | | Existing | | | | derive CBOR | | | | CBOR | | | | tag [RFC9277] | | | | tag | | | `------+-------' | | `---+----' | | | | | | | | |.----------(--(-----' | | | | | | | v | | | | .----------------. | | | | / CBOR tag CMW / | | v v `----------------' v v .--------------------------------------. / Array CMW / `--------------------------------------' Figure 4: How To CMW Appendix C. Open Issues The list of currently open issues for this documents can be found at https://github.com/thomas-fossati/draft-ftbs-rats-msg-wrap/issues. // 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. Birkholz, et al. Expires 2 August 2024 [Page 23] Internet-Draft RATS CMW January 2024 Authors' Addresses Henk Birkholz Fraunhofer SIT Email: henk.birkholz@sit.fraunhofer.de Ned Smith Intel Email: ned.smith@intel.com Thomas Fossati Linaro Email: thomas.fossati@linaro.org Hannes Tschofenig Email: hannes.tschofenig@gmx.net Birkholz, et al. Expires 2 August 2024 [Page 24]