RATS Conceptual Messages Wrapper (CMW)
Internet-Draft draft-ietf-rats-msg-wrap-07
Henk Birkholz
Fraunhofer SIT
henk.birkholz@sit.fraunhofer.de
Ned Smith
Intel
ned.smith@intel.com
Thomas Fossati
Linaro
thomas.fossati@linaro.org
Hannes Tschofenig
hannes.tschofenig@gmx.net
24 July 2024
Security
Remote ATtestation ProcedureS
evidence
attestation results
endorsements
reference values
This document defines the RATS conceptual message wrapper (CMW) format, a type of encapsulation format that can be used for any RATS messages, such as Evidence, Attestation Results, Endorsements, and Reference Values. Additionally, the document describes a collection type that enables the aggregation of one or more CMWs into a single message.
This document also defines corresponding CBOR tag, JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims, as well as an X.509 extension. These allow embedding the wrapped conceptual messages into CBOR-based protocols, web APIs, and PKIX protocols.
Discussion Venues
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.
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 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.
This document also defines corresponding CBOR tag, JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims, as well as an X.509 extension. These allow embedding the wrapped conceptual messages into CBOR-based protocols, web APIs, and PKIX protocols.
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").
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 record (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.3.
A CMW "tunnel" type is also defined in Section 3.4 to allow transporting CBOR CMWs in JSON collections and vice-versa.
The collected CDDL is in Appendix A.
CMW Record
The format of the CMW record is shown in Figure 1. The JSON [STD90] and CBOR [STD94] representations are provided separately. Both the json-record and cbor-record have the same fields except for slight differences in the types discussed below.
A CMW record carried in a "cmw" JWT claim (Section 8.2) MUST be a json-record. A CMW record carried in a "cmw" CWT claim (Section 8.1) MUST be a cbor-record.
CDDL definition of the Record format

json-record = [
  type: media-type
  value: base64url-string
  ? ind: uint .bits cm-type
]

cbor-record = [
  type: coap-content-format-type / media-type
  value: bytes
  ? ind: uint .bits cm-type
]

Each contains two or 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]). The latter MUST NOT be used in the JSON serialization.
value:
The RATS conceptual message serialized according to the value defined in the type member. When using JSON, the value field MUST be encoded as Base64 using the URL and filename safe alphabet (Section 5 of [RFC4648]) without padding. This always applies, even if the conceptual message format is already textual (e.g., a JWT EAT). When using CBOR, the value field MUST be encoded as a CBOR byte string.
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.
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 as a macro with two parameters:
- tn, the CBOR tag number
- $fmt, the definition of the associated conceptual message
CDDL definition of the CBOR Tag format macro

cbor-tag<tn, $fmt> = #6.<tn>(bytes .cbor $fmt)

To add a new CMW, the $cbor-tag type socket is extended with a new instance of the CMW CBOR Tag macro. For example, to associate conceptual messages of type my-evidence with CBOR Tag 1668576819, one would extend $cbor-tag as follows:

$cbor-tag /= cbor-tag<1668576819, my-evidence>

my-evidence = {
  &(eat_nonce: 10) => bstr .size (8..64)
}

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.
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.
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, either native or "tunnelled" (Section 3.4). The position of a cmw entry in the cmw-collection is not significant. Labels can be strings (or integers in the CBOR serialization) that serve as a mnemonic for different conceptual messages in the collection.
The "__cmwc_t" key is reserved for associating an optional type to the overall collection and MUST NOT be used for a label. The collection type is either a Uniform Resource Identifier (URI) or an object identifier (OID). The OID is always absolute and never relative.
Since the collection type is recursive, implementations may limit the allowed depth of nesting.
CDDL definition of the CMW collection format

json-collection = {
  ? "__cmwc_t": ~uri / oid
  + &(label: text) => json-CMW / c2j-tunnel
}

cbor-collection = {
  ? "__cmwc_t": ~uri / oid
  + &(label: (int / text)) => cbor-CMW / j2c-tunnel
}

Although initially designed for the composite Attester use case, the CMW collection can be repurposed for other use cases requiring CMW aggregation.
A CMW collection carried in a "cmw" JWT claim (Section 8.2) MUST be a json-collection. A CMW collection carried in a "cmw" CWT claim (Section 8.1) MUST be a cbor-collection.
CMW Collections' role in composite Attester topology
A CMW Collection's tree structure is not required to be a spanning tree of the system's composite Attester topology. If the labels carry semantic content for a Verifier (e.g. to improve Verifier performance or aid human comprehension), the collection SHOULD be integrity protected. For example, the collection can be integrity protected by including it in a signed token such as a CWT or JWT.
CMW Tunnel
The CMW tunnel type (Figure 4) allows for moving a CMW in one serialization format, either JSON or CBOR, into a collection that uses the opposite serialization format.
Both tunnel types are arrays with two elements. The first element, a fixed text string starting with a #, acts as a sentinel value. The #, which is not an acceptable start symbol for the Content-Type production (Appendix A), makes it possible to disambiguate a CMW tunnel from a CMW record.
CDDL definition of the CMW tunnel format

c2j-tunnel = [ "#cmw-c2j-tunnel", base64url-string ]
j2c-tunnel = [ "#cmw-j2c-tunnel", bytes ]

The conversion algorithms are described in the following subsections.
CBOR-to-JSON
The CBOR byte string of the serialised CBOR CMW is encoded as Base64 using the URL and filename safe alphabet (Section 5 of [RFC4648]) without padding. The obtained string is added as the second element of the c2j-tunnel array. The c2j-tunnel array is serialized as JSON.
JSON-to-CBOR
The UTF-8 string of the serialized JSON CMW is encoded as a CBOR byte string (Major type 2). The byte string is added as the second element of the j2c-tunnel array. The j2c-tunnel array is serialized as CBOR.
Decapsulation Algorithm
Once any external framing is removed (for example, if the CMW is carried in a certificate extension), the CMW decoder performs a 1-byte lookahead to determine how to decode the remaining byte buffer. The following pseudo-code illustrates this process:

func CMWTypeSniff(b []byte) (CMW, error) {
  if len(b) == 0 {
    return Unknown
  }

  if b[0] == 0x82 || b[0] == 0x83 {
    return CBORRecord
  } else if b[0] >= 0xc0 && b[0] <= 0xdb {
    return CBORTag
  } else if b[0] == 0x5b {
    return JSONRecord
  } else if b[0] == 0x7b {
    return JSONCollection
  } else if (b[0] >= 0xa0 && b[0] <= 0xbb) || b[0] == 0xbf {
    return CBORCollection
  }

  return Unknown
}

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 (Concise Reference Integrity Manifest) [I-D.ietf-rats-corim] payload with an explicit CM indicator 0b0000_0011 (3), meaning that the wrapped message contains both Reference Values and Endorsements.
JSON Record

[
  "application/vnd.example.rats-conceptual-msg",
  "q82rzQ"
]

Note that a CoAP Content-Format number can also be used with the JSON record 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 Record

[
  30001,
  h'2347da55'
]

with the following wire representation:

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 record 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'
]

CBOR Tag

1668576818(h'2347da55')

with the following wire representation:

da 63747632    # tag(1668576818)
   44          # bytes(4)
      2347da55 # "#G\xDAU"

CBOR Record 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)

CBOR Collection
The following example is a CBOR collection that assembles conceptual messages from three attesters: Evidence for attesters A and B and Attestation Results for attester C. It is given an explicit collection type using the URI form.

{
  "attester A": [
    30001,
    h'2347da55',
    4
  ],
  "attester B": 1668576818(h'2347da55'),
  "attester C": [
    "application/eat+jwt",
    h'4c693475',
    8
  ]
}

with the following wire representation:

a3                                      # map(3)
   6a                                   # text(10)
      61747465737465722041              # "attester A"
   83                                   # array(3)
      19 7531                           # unsigned(30001)
      44                                # bytes(4)
         2347da55                       # "#G\xDAU"
      04                                # unsigned(4)
   6a                                   # text(10)
      61747465737465722042              # "attester B"
   da 63747632                          # tag(1668576818)
      44                                # bytes(4)
         2347da55                       # "#G\xDAU"
   6a                                   # text(10)
      61747465737465722043              # "attester C"
   83                                   # array(3)
      73                                # text(19)
         6170706c69636174696f6e2f6561742b6a7774 # "application/eat+jwt"
      44                                # bytes(4)
         4c693475                       # "Li4u"
      08                                # unsigned(8)

The following example shows the use of a tunnelled type to move a JSON record to a CBOR collection:

{
  "__cmwc_t": "tag:example.com,2024:composite-attester",
  0: [
    30001,
    h'2347da55',
    4
  ],
  1: 1668576818(h'2347da55'),
  2: [
    "#cmw-j2c-tunnel",
    '[ "application/eat+jwt", "Li4u", 8 ]'
  ]
}

JSON Collection
The following example is a JSON collection that assembles Evidence from two attesters.

{
  "attester A": [
    "application/eat-ucs+json",
    "e30K",
    4
  ],
  "attester B": [
    "application/eat-ucs+cbor",
    "oA",
    4
  ]
}

The following example shows the use of a tunnelled type to move a CBOR record to a JSON collection:

{
  "attester A": [
    "application/eat-ucs+json",
    "e30K",
    4
  ],
  "attester B (tunnelled)": [
    "#cmw-c2j-tunnel",
    "g3gYYXBwbGljYXRpb24vZWF0LXVjcytjYm9yQaAE"
  ]
}

Use in JWT
The following example shows the use of the "cmw" JWT claim to transport a CMW collection in a JWT [RFC7519]:

{
  "cmw": {
    "attester A": [
      "application/eat-ucs+json",
      "e30K",
      4
    ],
    "attester B (tunnelled)": [
      "#cmw-c2j-tunnel",
      "g3gYYXBwbGljYXRpb24vZWF0LXVjcytjYm9yQaAE"
    ]
  },
  "iss": "evidence collection daemon",
  "exp": 1300819380
}

Transporting CMW in X.509 Messages
CMW may need to be transported in PKIX messages, such as Certificate Signing Requests (CSRs) or in X.509 Certificates and Certificate Revocation Lists (CRLs). The former use is documented in [I-D.ietf-lamps-csr-attestation], the latter in Section 6.1 of [DICE-arch].
This section specifies the CMW extension to carry CMW objects.
The CMW extension MAY be included in X.509 Certificates, CRLs [RFC5280], and CSRs.
The CMW extension MUST be identified by the following object identifier:

id-pe-cmw  OBJECT IDENTIFIER ::=
        { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanisms(5) pkix(7) id-pe(1) TBD }

This extension SHOULD NOT be marked critical. It MAY be marked critical in cases where the attestation-related information is essential for granting resource access, and there is a risk that legacy relying parties would bypass such controls.
The CMW extension MUST have the following syntax:

CMW ::= CHOICE {
    json UTF8String,
    cbor OCTET STRING
}

The CMW MUST contain the serialized CMW object in JSON or CBOR format, using the appropriate CHOICE entry.
The DER-encoded CMW is the value of the OCTET STRING for the extnValue field of the extension.
ASN.1 Module
This section provides an ASN.1 module [X.680] for the CMW extension, following the conventions established in [RFC5912] and [RFC6268].

CMWExtn
  { 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) } ;

-- CMW Extension

ext-CMW EXTENSION ::= {
  SYNTAX CMW
  IDENTIFIED BY id-pe-cmw }

-- CMW Extension OID

id-pe-cmw  OBJECT IDENTIFIER  ::=
   { iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) id-pe(1) TBD }

-- CMW Extension Syntax

CMW ::= CHOICE {
    json UTF8String,
    cbor OCTET STRING
}

END

Compatibility with DICE ConceptualMessageWrapper
Section 6.1.8 of [DICE-arch] defines the ConceptualMessageWrapper format and the associated object identifier. The CMW format defined in [DICE-arch] allows only a subset of the CMW grammar defined in this document. Specifically, the tunnel and collection formats cannot be encoded using DICE CMWs.
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 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".
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/.
Security Considerations
This document introduces two encapsulation formats for RATS conceptual messages, record and tag. RATS conceptual messages are typically secured using cryptography. If the messages are already protected, then there are no additional security requirements imposed by the introduction of this encapsulation. If an adversary tries to modify the payload encapsulation, it will result in incorrect processing of the encapsulated message and lead to an error. If the messages are not protected, additional security must be added at a different layer. As an example, a cbor-record containing an UCCS (Unprotected CWT Claims Sets) [I-D.ietf-rats-uccs] can be signed using COSE Sign1 [STD96].
This document introduces a format for holding multiple CMW items in a collection. If the collection is not protected from tampering by external security measures (such as object security primitives) or internal mechanisms (such as intra-item binding), an attacker could easily manipulate the collection's contents.
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 [IANA.cwt] as follows:
- Claim Name: cmw
- Claim Description: A RATS Conceptual Message Wrapper
- Claim Key: TBD
- Claim Value Type(s): CBOR Map, CBOR Array, or CBOR Tag
- Change Controller: IETF
- Specification Document(s): Section 3.1, Section 3.3 and Section 3.2 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 [IANA.jwt] as follows:
- Claim Name: cmw
- Claim Description: A RATS Conceptual Message Wrapper
- Change Controller: IETF
- Specification Document(s): Section 3.1 and Section 3.3 of RFCthis
CBOR Tag Registration
IANA is requested to add the following tag to the "CBOR Tags" [IANA.cbor-tags] registry.
CBOR Tag | Data Item | Semantics | Reference
TBD | CBOR map, CBOR array, CBOR tag | RATS Conceptual Message Wrapper | Section 3.1, Section 3.2 and Section 3.3 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" (Section 4.5 of [BCP26]).
The objective is to have CMW Indicators values registered for all RATS Conceptual Messages (Section 8 of [RFC9334]).
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.
Structure of Entries
Each entry in the registry must include:
Indicator value:
A number corresponding to the bit position in the ind bitmap (Section 3.1).
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.
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
4-31 | Unassigned | RFCthis
Provisional Registration
Before the creation of the registry by IANA, new codepoints can be added to the provisional CMW Indicators registry by following the documented procedure.
Table 2 will be regularly updated to match the contents of the provisional registry.
The provisional registry will be discontinued once IANA establishes the permanent registry, which is expected to coincide with the publication of the current document.
Media Types
IANA is requested to add the following media types to the "Media Types" registry [IANA.media-types].
CMW Media Types
Name | Template | Reference
cmw+cbor | application/cmw+cbor | Section 3.1, Section 3.2 and Section 3.3 of RFCthis
cmw+json | application/cmw+json | Section 3.1 and Section 3.3 of RFCthis
application/cmw+cbor
Type name:
application
Subtype name:
cmw+cbor
Required parameters:
n/a
Optional parameters:
cmwc_t (CMW collection type in string format. The parameter value is case-insensitive. It MUST NOT be used for CMW that are not collections.)
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
application/cmw+json
Type name:
application
Subtype name:
cmw+json
Required parameters:
n/a
Optional parameters:
cmwc_t (CMW collection type in string format. The parameter value is case-insensitive. It MUST NOT be used for CMW that are not collections.)
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
CoAP Content Formats
IANA is requested to register the following Content-Format numbers in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry [IANA.core-parameters]:
New CoAP Content Formats
Content-Type | Content Coding | ID | Reference
application/cmw+cbor | - | TBD1 | Section 3.1, Section 3.2 and Section 3.3 of RFCthis
application/cmw+json | - | TBD2 | Section 3.1 and Section 3.3 of RFCthis
If possible, TBD1 and TBD2 should be assigned in the 256..999 range.
New SMI Numbers Registrations
IANA is requested to assign an object identifier (OID) for the CMW 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.
References
Normative References
[RFC4648]

The Base16, Base32, and Base64 Data Encodings
S. Josefsson
October 2006
RFC 4648
DOI 10.17487/RFC4648
[RFC5280]

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
D. Cooper
S. Santesson
S. Farrell
S. Boeyen
R. Housley
W. Polk
May 2008
RFC 5280
DOI 10.17487/RFC5280
[RFC5912]

New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
P. Hoffman
J. Schaad
June 2010
RFC 5912
DOI 10.17487/RFC5912
[RFC6268]

Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)
J. Schaad
S. Turner
July 2011
RFC 6268
DOI 10.17487/RFC6268
[RFC6838]

Media Type Specifications and Registration Procedures
N. Freed
J. Klensin
T. Hansen
January 2013
BCP 13
RFC 6838
DOI 10.17487/RFC6838
[RFC7252]

The Constrained Application Protocol (CoAP)
Z. Shelby
K. Hartke
C. Bormann
June 2014
RFC 7252
DOI 10.17487/RFC7252
[RFC7519]

JSON Web Token (JWT)
M. Jones
J. Bradley
N. Sakimura
May 2015
RFC 7519
DOI 10.17487/RFC7519
[STD90]

The JavaScript Object Notation (JSON) Data Interchange Format
T. Bray, Ed.
December 2017
STD 90
RFC 8259
DOI 10.17487/RFC8259
[RFC8610]

Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
H. Birkholz
C. Vigano
C. Bormann
June 2019
RFC 8610
DOI 10.17487/RFC8610
[RFC9165]

Additional Control Operators for the Concise Data Definition Language (CDDL)
C. Bormann
December 2021
RFC 9165
DOI 10.17487/RFC9165
[RFC9277]

On Stable Storage for Items in Concise Binary Object Representation (CBOR)
M. Richardson
C. Bormann
August 2022
RFC 9277
DOI 10.17487/RFC9277
[STD94]

Concise Binary Object Representation (CBOR)
C. Bormann
P. Hoffman
December 2020
STD 94
RFC 8949
DOI 10.17487/RFC8949
[IANA.cwt]

CBOR Web Token (CWT) Claims
IANA
22 March 2018
[IANA.jwt]

JSON Web Token (JWT)
IANA
23 January 2015
[BCP26]

Guidelines for Writing an IANA Considerations Section in RFCs
M. Cotton
B. Leiba
T. Narten
June 2017
BCP 26
RFC 8126
DOI 10.17487/RFC8126
[X.680]

Specification of Abstract Syntax Notation One (ASN.1): Specification of Basic Notation
International Telephone and Telegraph Consultative Committee
July 1994
CCITT Recommendation X.680
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[IANA.cbor-tags]

Concise Binary Object Representation (CBOR) Tags
IANA
19 September 2013
[IANA.media-types]

Media Types
IANA
5 July 2024
[IANA.core-parameters]

Constrained RESTful Environments (CoRE) Parameters
IANA
8 June 2012
[IANA.smi-numbers]

Structure of Management Information (SMI) Numbers (MIB Module Registrations)
IANA
5 July 2024
Informative References
[RFC7942]

Improving Awareness of Running Code: The Implementation Status Section
Y. Sheffer
A. Farrel
July 2016
BCP 205
RFC 7942
DOI 10.17487/RFC7942
[RFC9193]

Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format
A. Keränen
C. Bormann
June 2022
RFC 9193
DOI 10.17487/RFC9193
[STD96]

CBOR Object Signing and Encryption (COSE): Structures and Process
J. Schaad
August 2022
STD 96
RFC 9052
DOI 10.17487/RFC9052
[RFC9334]

Remote ATtestation procedureS (RATS) Architecture
H. Birkholz
D. Thaler
M. Richardson
N. Smith
W. Pan
January 2023
RFC 9334
DOI 10.17487/RFC9334
[I-D.ietf-rats-eat]

The Entity Attestation Token (EAT)
Laurence Lundblade
Security Theory LLC
Giridhar Mandyam
Mediatek USA
Jeremy O'Donoghue
Qualcomm Technologies Inc.
Carl Wallace
Red Hound Software, Inc.
8 July 2024
Internet-Draft draft-ietf-rats-eat-29
[I-D.ietf-rats-eat-media-type]

EAT Media Types
Laurence Lundblade
Security Theory LLC
Henk Birkholz
Fraunhofer Institute for Secure Information Technology
Thomas Fossati
Linaro
4 July 2024
Internet-Draft draft-ietf-rats-eat-media-type-08
[I-D.ietf-rats-ar4si]

Attestation Results for Secure Interactions
Eric Voit
Cisco Systems
Henk Birkholz
Fraunhofer SIT
Thomas Hardjono
MIT
Thomas Fossati
Linaro
Vincent Scarlata
Intel
4 March 2024
Internet-Draft draft-ietf-rats-ar4si-06
[I-D.ietf-rats-uccs]

A CBOR Tag for Unprotected CWT Claims Sets
Henk Birkholz
Fraunhofer SIT
Jeremy O'Donoghue
Qualcomm Technologies Inc.
Nancy Cam-Winget
Cisco Systems
Carsten Bormann
Universität Bremen TZI
4 July 2024
Internet-Draft draft-ietf-rats-uccs-10
[I-D.fossati-tls-attestation]

Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
Hannes Tschofenig
Yaron Sheffer
Intuit
Paul Howard
Arm Limited
Ionuț Mihalcea
Arm Limited
Yogesh Deshpande
Arm Limited
Arto Niemi
Huawei
Thomas Fossati
Linaro
8 July 2024
Internet-Draft draft-fossati-tls-attestation-07
[I-D.ietf-lamps-csr-attestation]

Use of Remote Attestation with Certification Signing Requests
Mike Ounsworth
Entrust Limited
Hannes Tschofenig
Siemens
Henk Birkholz
Fraunhofer SIT
Monty Wiseman
Beyond Identity
Ned Smith
Intel Corporation
7 July 2024
Internet-Draft draft-ietf-lamps-csr-attestation-10
[I-D.ietf-rats-corim]

Concise Reference Integrity Manifest
Henk Birkholz
Fraunhofer SIT
Thomas Fossati
Linaro
Yogesh Deshpande
arm
Ned Smith
Intel
Wei Pan
Huawei Technologies
8 July 2024
Internet-Draft draft-ietf-rats-corim-05
[DICE-arch]

DICE Attestation Architecture
Trusted Computing Group
January 2024
Collected CDDL

start = cmw

cmw = json-CMW / cbor-CMW

json-CMW = json-record / json-collection
cbor-CMW = cbor-record / cbor-collection / $cbor-tag

json-record = [
  type: media-type
  value: base64url-string
  ? ind: uint .bits cm-type
]

cbor-record = [
  type: coap-content-format-type / media-type
  value: bytes
  ? ind: uint .bits cm-type
]

cbor-tag<tn, $fmt> = #6.<tn>(bytes .cbor $fmt)

json-collection = {
  ? "__cmwc_t": ~uri / oid
  + &(label: text) => json-CMW / c2j-tunnel
}

cbor-collection = {
  ? "__cmwc_t": ~uri / oid
  + &(label: (int / text)) => cbor-CMW / j2c-tunnel
}

c2j-tunnel = [ "#cmw-c2j-tunnel", base64url-string ]
j2c-tunnel = [ "#cmw-j2c-tunnel", bytes ]

media-type = text .abnf ("Content-Type" .cat Content-Type-ABNF)
base64url-string = text .regexp "[A-Za-z0-9_-]+"

cm-type = &(
  reference-values: 0
  endorsements: 1
  evidence: 2
  attestation-results: 3
)

coap-content-format-type = uint .size 2

oid = text .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*"

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)
'

Registering and Using CMWs
Figure 5 describes the registration preconditions for using CMWs in either CMW record or CBOR tag forms. When using CMW collection, the preconditions apply for each entry in the collection.
How To Create a CMW

Reuse

EAT/CoRIM

Register

media

type(s)

new

media
                +

profile

type

Register

new

CoAP

Content-Format

Automatically

Existing

derive

CBOR

CBOR

tag

[RFC9277]

tag

CBOR

tag

CMW

CMW

       .---------------.   .---------.
      | 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
    .--------------------------------------.
   /                 CMW                  /
  `--------------------------------------'

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 Brian Campbell, Carl Wallace, Carsten Bormann, Dionna Glaze, Laurence Lundblade, Michael B. Jones, Mohit Sethi, Russ Housley, and Tom Jones 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.