RFC 9999

Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW)

πŸ“… published July 2026, from ietf

Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW) πŸŽ€

Okay bestie, so this is RFC 9999 and it's giving "the messages are the stars, the wrapper is the glam squad" πŸ’–βœ¨ Let's get into it!

Internet Engineering Task Force (IETF) 🌸 Request for Comments: 9999 πŸ¦‹ Category: Standards Track πŸ‘‘ ISSN: 2070-1721 πŸ’œ Date: July 2026 πŸ“

Authors: H. Birkholz (Fraunhofer SIT), N. Smith (Independent), T. Fossati (Linaro), H. Tschofenig (UniBw M.) 🫢

Quick heads-up on the title block: this one is a Standards Track document, which means it's an actual Internet Standard in the making, not just a vibe. ✨ The "obsoletes" and "updates" details aren't listed in the title block of this copy, so I'm not going to invent any. πŸ™ˆ

Abstract ✨

Okay so the conceptual messages from the RATS architecture ([RFC9334]) are protocol-agnostic data units that get passed between RATS roles during RATS interactions. πŸ’… They describe what a message means and what it does in a data flow, without saying how it's written down on the wire, encoded, transported, or processed. ✨ The starter set is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. 🌈

This document introduces the Conceptual Message Wrapper (CMW), which is basically a shared outfit for wrapping all of these messages. πŸŽ€ It defines a dedicated Concise Binary Object Representation (CBOR) tag, matching JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. 🧚

Together, these let CMWs show up in CBOR-based protocols, web APIs that use JWTs and CWTs, and PKIX artifacts like X.509 certificates. πŸ’– It also defines media types and CoAP Content-Formats that can be used to label CMWs when they travel over protocols like HTTP, MIME, and CoAP. πŸ¦‹

The goal is interoperability and flexibility for remote attestation protocols. πŸ”₯ A shared message format like CMW means you can support different attestation message types consistently, evolve serialization formats without breaking compatibility, and skip redefining how messages get handled inside every single protocol. πŸ‘‘ It's giving efficiency, no cap! πŸ’…

Status of This Memo ✨

This is an Internet Standards Track document. πŸŽ€

This document is a product of the Internet Engineering Task Force (IETF). 🌸 It represents the consensus of the IETF community. πŸ’œ It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). πŸ‘‘ Further information on Internet Standards is available in Section 2 of RFC 7841. πŸ¦‹

Info about the current status of this document, any errata, and how to give feedback can be found at https://www.rfc-editor.org/info/rfc9999. 🫢

Copyright (c) 2026 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, since 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
2.  Conventions and Definitions
3.  Conceptual Message Wrappers
  3.1.  Record CMW
    3.1.1.  Conceptual Message Type
  3.2.  Tag CMW
    3.2.1.  How to Plug in a New Tag CMW
  3.3.  Collection CMW
  3.4.  Demuxing
4.  Cryptographic Protection of CMWs
  4.1.  Signing CBOR CMW Using COSE_Sign1
  4.2.  Signing JSON CMW Using JWS
  4.3.  Transporting CMW in COSE and JSON Web Tokens
    4.3.1.  Encoding Requirements
  4.4.  Transporting CMW in PKIX Formats
    4.4.1.  ASN.1 Module
    4.4.2.  Compatibility with Trusted Computing Group (TCG)
            ConceptualMessageWrapper
5.  Examples
  5.1.  JSON-Encoded Record
  5.2.  CBOR-Encoded Record
  5.3.  CBOR-Encoded Tag CMW
  5.4.  CBOR-Encoded Record with an Explicit Conceptual Message
        Indicator
  5.5.  CBOR-Encoded Collection
  5.6.  JSON-Encoded Collection
  5.7.  Use in JWT
6.  Collected CDDL
7.  Privacy Considerations
8.  Security Considerations
  8.1.  CMW Protection
  8.2.  Using Collection CMWs for Evidence of Composite or Layered
        Devices
  8.3.  Integrating CMW into Protocols
9.  IANA Considerations
  9.1.  CWT cmw Claim Registration
  9.2.  JWT cmw Claim Registration
  9.3.  +jws Structured Syntax Suffix
    9.3.1.  Registry Entry
  9.4.  RATS Conceptual Message Wrapper (CMW) Indicators Registry
    9.4.1.  Structure of Entries
  9.5.  Media Types
    9.5.1.  application/cmw+cbor
    9.5.2.  application/cmw+json
    9.5.3.  application/cmw+cose
    9.5.4.  application/cmw+jws
  9.6.  CoAP Content-Formats
    9.6.1.  Registering New CoAP Content-Formats for Parameterized
            CMW Media Types
    9.6.2.  CBOR Tags per RFC 9277
  9.7.  SMI Number Registration
10. References
  10.1.  Normative References
  10.2.  Informative References
Appendix A.  Registering and Using CMWs
Acknowledgments
Contributors
Authors' Addresses

Heads up, this is the table of contents for the whole RFC, so we'll be filling it in across all 7 parts. πŸ§šπŸ’œ

1. Introduction 🌸

The conceptual messages from the RATS architecture ([RFC9334]) are protocol-agnostic data units that get passed between RATS roles during RATS interactions. πŸ’… They describe what each message means and does in RATS data flows, without specifying a wire format, encoding, transport mechanism, or processing details. ✨ The starter set is defined in Section 8 of [RFC9334] and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. πŸ¦‹

Each conceptual message can have multiple claim-encoding and serialization formats (Section 9 of [RFC9334]). πŸŽ€ Over their lifetime, RATS conceptual messages usually travel over different protocols. 🌈 For example:

  • In a "background-check" topology (Section 5.2 of [RFC9334]), Evidence (e.g., Entity Attestation Token (EAT) [RFC9711]) first flows from the Attester to the Relying Party (RP), and then from the RP to the Verifier, with each leg using a separate protocol path. πŸ’– See Figure 1.
                              .------------.
                              |  Verifier  |
                              '------------'
                                  ^
                                  | EAT
                                  | over
                                  | REST API
  .------------.              .---|--------.
  |  Attester  +------------->|--'      RP |
  '------------' EAT over TLS '------------'

       Figure 1: Conveyance of RATS Conceptual Messages in the
                     'background-check' Topology
  • In a "passport" topology (Section 5.1 of [RFC9334]), an attestation result payload (e.g., EAT Attestation Result (EAR) [EAR]) is first sent from the Verifier to the Attester, and later it is sent over a different channel from the Attester to the RP. πŸ”₯ See Figure 2.
   .------------.
   |  Verifier  |
   '--------+---'
        EAR |
       over |
   REST API |
            v
   .------------.              .------------.
   |  Attester  +------------->|     RP     |
   '------------' EAR over TLS '------------'

       Figure 2: Conveyance of RATS Conceptual Messages in the
                         'passport' Topology

By using the CMW format from this document, protocol designers can skip updating their protocol specs every time a new conceptual message or serialization format shows up from some attestation technology. πŸ‘‘ That makes implementing things way easier for developers, so supporting diverse attestation technologies is smoother. πŸ’… For instance, an RP application implementer doesn't need to parse attestation messages like Evidence from Internet of Things (IoT) devices with Trusted Platform Modules (TPMs), or servers using confidential computing hardware like Intel Trust Domain Extensions (TDX). πŸ™ˆ They can just use the CMW format and stay agnostic to the specific attestation technology. ✨

Extensibility is another big goal. 🌈 Adding support for new conceptual messages and new attestation technologies should not change the core of the processor, and a CMW stack can be designed with a plug-in interface for both encoding and decoding. 🧚 To make this work, the format must provide consistent message encapsulation and explicit typing. πŸ’œ These features let the right message handler get selected based on its type identifier, and an opaque message can then be passed between the core and the handler. πŸ¦‹

This document defines two encapsulation formats for RATS conceptual messages that aim to achieve the goals above. πŸŽ€

These encapsulation formats are specifically designed to have the following characteristics: πŸ’–

  • They are self-describing: 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 to: πŸ”₯

  • convey Evidence, Endorsements, and Reference Values in certificates and Certificate Revocation List (CRL) extensions [DICE-ARCH];
  • embed Attestation Results or Evidence as first-class authentication credentials in TLS handshake messages [RA-TLS-DTLS] [RA-EXP-AUTH];
  • transport attestation-related payloads in RESTful APIs (where "RESTful" refers to the Representational State Transfer (REST) architecture); or
  • serve as stable storage of Attestation Results in the form of file system objects. πŸ‘‘

This document also defines a corresponding CBOR tag, JWT and CWT claims, and an X.509 extension. πŸ’… These allow embedding the wrapped conceptual messages into CBOR-based protocols, web APIs, and PKIX formats and protocols. 🧚 In addition, media types and CoAP Content-Formats are defined for transporting CMWs in HTTP, MIME, CoAP, and other Internet protocols. ✨

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. πŸŽ€ The rule here is simple: they only count when they're in ALL CAPS. πŸ™ˆ

In this document, Concise Data Definition Language (CDDL) (see [RFC8610], [RFC9165], and [RFC9741]) 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"). πŸ’–

To be continued in Part 2 (Section 3: Conceptual Message Wrappers) 🧚✨

3. Conceptual Message Wrappers ✨

okay bestie, so a RATS CMW has a tree structure 🌳 Leaf nodes are either type "Record" (Section 3.1) or "Tag" (Section 3.2). Intermediate nodes are type "Collection" (Section 3.3), and they hold multiple CMW items together 🫢

here's the top-level productions snippet:

start = cmw

cmw = json-cmw / cbor-cmw

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

the complete CDDL is in Section 6 πŸ’…

Sections 4.3 and 4.4 cover how CMWs get transported using CBOR, JWTs, and PKIX formats, like Certificate Signing Requests (CSRs), X.509 certificates, and CRLs πŸ“œ

⚠️ this document only defines an encapsulation, NOT a security format. the Attester is responsible for making sure the CMW contents have the necessary security protection. security considerations are in Section 8, so go read that one, it's serious 😭

3.1. Record CMW

the Record CMW format is shown in Figure 3. the JSON [STD90] and CBOR [STD94] representations are given separately. json-record and cbor-record have the same fields, with slight differences in the types (more on that below) πŸŽ€

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
]

Figure 3: CDDL Definition of the Record CMW

each one has two or three members 🌸

  • type: either a text string for a Content-Type (like an EAT media type [RFC9782]), or an unsigned integer matching a CoAP Content-Format ID (Section 12.3 of [RFC7252]). the integer version is NOT used in JSON, bestie πŸ™…β€β™€οΈ
  • value: the RATS conceptual message, serialized the way type says. when using JSON, value MUST be encoded as Base64 with the URL and filename-safe alphabet (Section 5 of [RFC4648]) and no padding. this applies EVEN if the message is already textual (like a JWT EAT) πŸ’– when using CBOR, value MUST be encoded as a CBOR byte string ✨
  • ind: an optional bitmap, max 4 bytes, that tells you which conceptual message types are inside value. any combo is allowed (basically any value from 1 to 2^32-1 inclusive). only 5 bits are registered in this document, so right now the valid values are just 1 to 31 πŸ¦‹ it's only useful when the type is kinda ambiguous and the consumer has no other context to figure it out. like when the base media type isn't profiled (say, application/eat+cwt), when value holds multiple messages of different types (like both Reference Values and Endorsements in the same application/rim+cose), or when one profile ID is shared by different conceptual messages πŸ‘€ the value MUST be non-zero πŸ”₯ if you don't know the conceptual message indicator, you just leave out the ind field entirely. more details in Section 3.1.1 ✨

3.1.1. Conceptual Message Type

the cm-type is the control type for the ind field, so it decides which bits are allowed to be set in the bitmap πŸ’œ

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

Figure 4: CDDL Definition of the CM Type

this document says cm-type has five allowed values: Reference Values, Endorsements, Evidence, Attestation Results, and Appraisal Policy, all defined in Section 8 of [RFC9334] 🧚 fun detail: an Appraisal Policy could be about Evidence OR Attestation Results, depending on whether the consumer is a Verifier or an RP πŸ“

it is recommended that future specs that extend the RATS conceptual messages add new values to cm-type using the process in Section 9.4 🌈

3.2. Tag CMW

Tag CMWs get their tag numbers from a matching CoAP Content-Format ID, using the TN() transform from Appendix B of [RFC9277]. those CBOR tag numbers sit in the range [1668546817, 1668612095] πŸ”’

the way it works: the RATS conceptual message gets serialized according to the Content-Format ID, then encoded as a CBOR byte string, and the TN-derived tag number goes in front of it ✨

the Tag CMW is defined in Figure 5 with two macros: one for CBOR-encoded types, and one for everything else. both macros take the CBOR tag number tn as a parameter. tag-cm-cbor also takes the CDDL definition of the conceptual message fmt as a second parameter πŸ’…

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

tag-cm-data<tn> = #6.<tn>(bytes)

Figure 5: CDDL Definition of the Tag CMW Macros

3.2.1. How to Plug in a New Tag CMW

to plug a new Tag CMW into the CDDL from Section 6, you have to extend the $cbor-tag type socket with a new instance of the Tag CMW macro (so either tag-cm-cbor or tag-cm-data) πŸ”Œ

for example, say a conceptual message of type my-evidence has the TN-derived CBOR tag 1668612069. then $cbor-tag gets extended like this:

$cbor-tag /= tag-cm-cbor<1668612069, my-evidence>

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

and if it's a (non-CBOR) conceptual message with the TN-derived CBOR tag 1668612070, you extend it like this instead:

$cbor-tag /= tag-cm-data<1668612070>

the socket gets initialized as described in Figure 7 πŸ¦‹

3.3. Collection CMW

okay this one is my favorite πŸ₯Ή layered Attesters and composite devices (Sections 3.2 and 3.3 of [RFC9334]) produce Evidence in multiple parts. for example, in data center servers it's pretty common for separate attesting environments (AEs) to each cover a piece of the whole machine. one AE might measure and attest what got booted on the main CPU, another might do the same for a SmartNIC in a PCI Express (PCIe) slot, and a third for the machine's Graphics Processing Unit (GPU) πŸ–₯️✨ so to let you bundle up multiple, possibly totally different, evidence formats from different AEs, this document defines a Collection CMW. it's a container holding several CMW items, and each one has a label that's unique inside that collection πŸŽ€

it was built for layered Attesters and composite devices, but it can be used for other stuff that needs RATS conceptual messages bundled together too. like grouping Endorsements, Reference Values, Attestation Results, and more πŸ’œ one Collection CMW can mix different message types, and it can carry messages for multiple devices at once 🌈

the Collection CMW (Figure 6) is a CBOR map or a JSON object full of CMW values. the order of cmw entries in the cmw-collection doesn't matter πŸ™ƒ labels can be strings (or integers in the CBOR serialization), and they act like a mnemonic for each conceptual message in the collection 🧠

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

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

Figure 6: CDDL Definition of the Collection CMW

a collection MUST have at least one CMW entry 🚨

the "__cmwc_t" key is reserved for attaching an optional type to the whole collection, and it MUST NOT be used for any purpose other than what's described here πŸ”’

the value of "__cmwc_t" is either a Uniform Resource Identifier (URI) or an object identifier (OID). the OID is always absolute, never relative. the URI MUST be in absolute form (Section 4.3 of [RFC3986]) 🌐

"__cmwc_t" works kind of like an EAT profile claim (see Section 4.3.2 of [RFC9711]) but one level up. it can say stuff like the CBOR serialization and CBOR Object Signing and Encryption (COSE) algorithms, just like an EAT profile does. it gives you a namespace where the collection labels get interpreted 🏷️ at that higher level, it can also describe what a valid Collection CMW assembly looks like (kinda like how EAT profiles say which claims are required and/or allowed) πŸ‘‘ for an example of a "__cmwc_t" defined for a bundle of endorsements and reference values, check Section 4.3.1 of [CoRIM] πŸ¦‹

since the Collection CMW is recursive (a Collection CMW is itself a CMW), implementations MAY limit how deep the nesting goes πŸͺ†

Implementation note: an API that uses CMW may support a discoverable "max-cmw-depth" attribute, so applications can advertise their own limits. also, a protocol using CMW may require its users to specify a minimum depth. how exactly such a limit is discovered or set is out of scope for this document πŸ’€

3.4. Demuxing

the split between the JSON and CBOR decoding paths is expected to happen via the media type or content format (see Sections 9.5 and 9.6, respectively), or via the container context of the embedded CMW (see Sections 9.1 and 9.2 for CWT/JWT, and Section 9.7 for X.509) πŸ”

the pseudocode below shows how a one-byte look-ahead is enough to figure out how to decode the rest of the byte buffer 🀯

func exampleCMWTypeDemux(b []byte) CMWType {
  if len(b) == 0 {
    return Unknown
  }

  switch b[0] {
  case 0x82: // 2-elements cbor-record (w/o ind field)
  case 0x83: // 3-elements cbor-record (w/ ind field)
  case 0x9f: // start of cbor-record using indefinite-length encoding
    return CBORRecord
  case 0xda: // tag-cm-cbor (CBOR tag in the TN range)
    return CBORTag
  case 0x5b: // ASCII '[', start of json-record
    return JSONRecord
  case 0x7b: // ASCII '{', start of json-collection
    return JSONCollection
  case 0xa0..0xbb: // CBOR map start values, start of cbor-collection
  case 0xbf:       // ditto
    return CBORCollection
  }

  return Unknown
}

this code is just for information, so it's not expected that implementations will follow this demuxing strategy 🫠

4. Cryptographic Protection of CMWs πŸ”

this section is a highlight reel of mechanisms that protocol designers can use to add data origin authentication, integrity, and (if you're using a challenge-response protocol) anti-replay protection when working with CMWs πŸ›‘οΈ these properties must be evaluated carefully in the context of the protocol's overall security model, so don't just assume they're handled 😀

4.1. Signing CBOR CMW Using COSE_Sign1 ✨

okay so a CBOR CMW can get signed with COSE [RFC9052] πŸ” A signed-cbor-cmw is basically a COSE_Sign1 that looks like this:

signed-cbor-cmw = [
  protected: bytes .cbor signed-cbor-cmw-protected-hdr
  unprotected: signed-cbor-cmw-unprotected-hdr
  payload: bytes .cbor cbor-cmw
  signature: bytes
]

The payload MUST be the CBOR-encoded Tag, Record, or Collection CMW πŸ’Œ

signed-cbor-cmw-protected-hdr = {
  1 => int                            ; alg
  3 => "application/cmw+cbor" / 273   ; cty
  * cose.label => cose.values
}

signed-cbor-cmw-unprotected-hdr = {
  * cose.label => cose.values
}

cose.label = int / text
cose.values = any

Okay this next bit is the important part 🫢 The protected header MUST include the signature algorithm identifier. It also MUST include either the media type application/cmw+cbor or the CoAP Content-Format 273. Other header parameters MAY be added to the header buckets, like a kid that tells you which signing key to use πŸ”‘

4.2. Signing JSON CMW Using JWS 🌈

A JSON CMW can be signed with JSON Web Signature (JWS) [RFC7515] πŸ’« A signed-json-cmw can use either the Flattened JSON Serialization (Section 7.2.2 of [RFC7515]) or the Compact Serialization (Section 3.1 of [RFC7515]). Two styles, one vibe ✨

signed-json-cmw = jws-flattened-json / jws-compact

jws-flattened-json = {
  "protected": protected
  ? "header": unprotected
  "payload": payload
  "signature": signature
}

jws-compact =
  (((protected .cat ".") .cat payload) .cat ".") .cat signature

protected = text .b64u (text .json signed-json-cmw-protected-hdr)
unprotected = text .b64u (text .json signed-json-cmw-unprotected-hdr)
payload = text .b64u (text .json json-cmw)
signature = text .b64u bytes

The payload MUST be the JSON-encoded Record or Collection CMW πŸ“

signed-json-cmw-protected-hdr = {
  "alg": text
  "cty": "application/cmw+json"
  * text => text
}

signed-json-cmw-unprotected-hdr = {
  * text => text
}

The protected header MUST include the signature algorithm identifier and the media type application/cmw+json. Other header parameters MAY be added to the header buckets, for example, a kid that identifies the signing key πŸ—οΈπŸ’œ

4.3. Transporting CMW in COSE and JSON Web Tokens 🧚

So you want to stuff CMWs into CBOR-based protocols and web APIs? Same πŸ™ˆ To make that easy, this document defines two "cmw" claims, one for JWT and one for CWT πŸ¦‹

The definitions for these claims can be found in Sections 9.2 and 9.1, respectively πŸ“–

4.3.1. Encoding Requirements πŸ’…

A Collection CMW carried in a "cmw" JWT claim MUST be a json-collection. A Collection CMW carried in a "cmw" CWT claim MUST be a cbor-collection πŸŽ€

A Record CMW carried in a "cmw" JWT claim MUST be a json-record. A Record CMW carried in a "cmw" CWT claim MUST be a cbor-record ✨

4.4. Transporting CMW in PKIX Formats 🏰

CMW may need to ride along in PKIX formats, like CSRs or X.509 certificates and CRLs 🌸

The use of CMW in CSRs is documented in [RA-CERT-SIGN], and one of the possible applications in X.509 certificates and CRLs is detailed in Section 6.1 of [DICE-ARCH] πŸ“œ

This section is all about the CMW extension, which exists to carry CMW objects. Section 7 talks about some privacy considerations for transporting CMW in X.509 formats, so don't skip it πŸ‘€

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) 35 }

This extension SHOULD NOT be marked critical. The one exception: if the wrapped conceptual message is essential for granting resource access, and there's a risk that legacy RPs would bypass crucial controls, it is acceptable to mark the extension as critical 🚨

The CMW extension has the following syntax 🧩

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

The CMW MUST include the serialized CMW object in either JSON or CBOR format, using the matching CHOICE entry πŸ’–

The DER-encoded [X.690] CMW is the value of the OCTET STRING for the extnValue field of the extension πŸ’Ž

4.4.1. ASN.1 Module πŸͺ„

This section gives you an ASN.1 module [X.680] for the CMW extension, following the conventions set out 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-extn(123) }

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) 35 }

-- CMW Extension Syntax

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

END

4.4.2. Compatibility with Trusted Computing Group (TCG) ConceptualMessageWrapper 🀝

Section 6.1.8 of [DICE-ARCH] specifies the ConceptualMessageWrapper (CMW) format and its matching object identifier. Heads up though: the CMW format in [DICE-ARCH] only covers a subset of the CMW grammar in this document. Specifically, the collection format can't be encoded using TCG CMWs πŸ₯Ί

5. Examples 🎬

The (equivalent) examples in Sections 5.1, 5.2, and 5.3 assume that the Media-Type-Name application/vnd.example.rats-conceptual-msg has been registered alongside a corresponding CoAP Content-Format ID, 64999 [RFC9876]. The CBOR tag 1668612070 comes from applying the TN() transform described in Section 3.2 ✨

All of these examples focus on the wrapping bits. The wrapped messages aren't real conceptual messages, so don't stress about the contents 🫢

5.1. JSON-Encoded Record 🍭

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

5.2. CBOR-Encoded Record 🌷

[
  64999,
  h'2347da55'
]

with the following wire representation:

82             # array(2)
   19 fde7     # unsigned(64999)
   44          # bytes(4)
      2347da55 # "#G\xDAU"

Note that a Media-Type-Name can also be used with the CBOR-encoded Record form. That's handy if you know the receiver can't handle CoAP Content-Formats, or (unlike our example) if a CoAP Content-Format ID hasn't been registered πŸ’‘

[
  "application/vnd.example.rats-conceptual-msg",
  h'2347da55'
]

5.3. CBOR-Encoded Tag CMW πŸ¦‹

1668612070(h'2347da55')

with the following wire representation:

da 6374ffe6    # tag(1668612070)
   44          # bytes(4)
      2347da55 # "#G\xDAU"

5.4. CBOR-Encoded Record with an Explicit Conceptual Message Indicator πŸ‘‘

This is an example of a signed CoRIM (Concise Reference Integrity Manifest) [CoRIM] with an explicit ind value of 0b0000_0011 (3), which says the wrapped message contains both Reference Values and Endorsements πŸ›‘οΈ

[
  "application/rim+cose",
  h'd28440a044d901f5a040',
  3
]

with the following wire representation (this example uses line wrapping per [RFC8792]):

=============== NOTE: '\' line wrapping per RFC 8792 ================

83                                      # array(3)
   74                                   # text(20)
      6170706c69636174696f6e2f72696d2b636f7365 # "application/rim+\
                                                                cose"
   4a                                   # bytes(10)
      d28440a044d901f5a040              # serialized CM value
   03                                   # unsigned(3)

5.5. CBOR-Encoded Collection 🧺

The following example is a CBOR-encoded Collection CMW that bundles conceptual messages from three Attesters: Evidence for Attesters A and B, and Attestation Results for Attester C. It gets an explicit "__cmwc_t" using the URI form 🌈

{
  "__cmwc_t": "tag:example.com,2024:composite-attester",
  / attester A / 0: [
    64999,
    h'2347da55',
    4
  ],
  / attester B / 1: 1668612070(h'2347da55'),
  / attester C / 2: [
    "application/eat+jwt",
    h'2e2e2e',
    8
  ]
}

5.6. JSON-Encoded Collection πŸ’œ

The following example is a JSON-encoded Collection CMW that bundles Evidence from two Attesters 🫧

{
  "__cmwc_t": "tag:example.com,2024:another-composite-attester",
  "attester A": [
    "application/eat-ucs+json",
    "e30K",
    4
  ],
  "attester B": [
    "application/eat-ucs+cbor",
    "oA",
    4
  ]
}

5.7. Use in JWT πŸŽ€

The following example shows the "cmw" JWT claim carrying a Collection CMW inside a JWT Claims Set [RFC7519] 🧚

{
  "cmw": {
    "__cmwc_t": "tag:example.com,2024:another-composite-attester",
    "attester A": [
      "application/eat-ucs+json",
      "e30K",
      4
    ],
    "attester B": [
      "application/eat-ucs+cbor",
      "oA",
      4
    ]
  },
  "iss": "evidence collection daemon",
  "exp": 1300819380
}

6. Collected CDDL ✨

okay bestie, this section is basically the whole CDDL toolbox in one place 🧰 every CDDL definition from this spec, all lined up so you can find anything you need πŸ’…

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
]

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

tag-cm-data<tn> = #6.<tn>(bytes)

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

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

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

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

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

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

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

signed-cbor-cmw = [
  protected: bytes .cbor signed-cbor-cmw-protected-hdr
  unprotected: signed-cbor-cmw-unprotected-hdr
  payload: bytes .cbor cbor-cmw
  signature: bytes
]

signed-cbor-cmw-protected-hdr = {
  1 => int                            ; alg
  3 => "application/cmw+cbor" / 273   ; cty
  * cose.label => cose.values
}

signed-cbor-cmw-unprotected-hdr = {
  * cose.label => cose.values
}

cose.label = int / text
cose.values = any


signed-json-cmw = jws-flattened-json / jws-compact

jws-flattened-json = {
  "protected": protected
  ? "header": unprotected
  "payload": payload
  "signature": signature
}

jws-compact =
  (((protected .cat ".") .cat payload) .cat ".") .cat signature

signed-json-cmw-protected-hdr = {
  "alg": text
  "cty": "application/cmw+json"
  * text => text
}

signed-json-cmw-unprotected-hdr = {
  * text => text
}

protected = text .b64u (text .json signed-json-cmw-protected-hdr)
unprotected = text .b64u (text .json signed-json-cmw-unprotected-hdr)
payload = text .b64u (text .json json-cmw)
signature = text .b64u bytes

$cbor-tag /= tag-cm-cbor<1668547091, cbor-collection>
$cbor-tag /= tag-cm-cbor<1668547092, signed-cbor-cmw>

$cbor-tag /= tag-cm-data<1668547093> ; bytes(cmw+json collection)
$cbor-tag /= tag-cm-data<1668547094> ; bytes(cmw+jws)

7. Privacy Considerations πŸ”’

okay, privacy is a big deal here 🫢 the privacy stuff in Section 11 of [RFC9334] totally applies, no cap. when a CMW has Personally Identifiable Information (PII) in it, which is the case for Evidence and sometimes for other conceptual messages too, care must be taken to stop unintended recipients from getting their hands on it πŸ‘€ using secure channels between the parties swapping CMWs is generally a great way to help with this πŸ’œ

there's a specific situation that comes up when a public key certificate gets issued based on Evidence the certificate requestor gave to the issuing Certification Authority (CA) 😭 like, someone going for a publicly trusted code signing certificate might be totally fine sharing the details of the hardware where their code signing keys live (think a Hardware Security Module (HSM) model, patch level, and so on) πŸ› οΈ but they probably do NOT want that info being publicly visible. so if an app wants to publicly "broadcast" Evidence claims it got from a third party through X.509 certificates, it should define a certification practice statement [RFC3647] that clearly spells out when the CA is allowed to put that data in the issued certificate πŸ“œ

one more thing: this doesn't apply when X.509 certificates are explicitly designed to be a security envelope for Evidence claims, like in [DICE-ARCH] πŸ¦‹

8. Security Considerations πŸ›‘οΈ

the security considerations in Section 12.2 of [RFC9334] about protecting conceptual messages are fully applicable, periodt πŸ’… the subsections below give extra detail on these points, especially for Collection CMWs πŸŽ€

8.1. CMW Protection

Record, Tag, and Collection CMWs on their own do NOT give you authenticity, integrity protection, or confidentiality 😳 it's on the designer of each use case to figure out which security properties they need and then actually implement them 🧠

RATS conceptual messages are usually secured with cryptography πŸ” if the messages are already protected, this encapsulation doesn't add any extra security requirements. but if an attacker tries to mess with the payload encapsulation, the encapsulated message will get processed incorrectly and you'll get an error πŸ’€ and if the messages aren't protected, extra security has to be added at a different layer. for example, a cbor-record holding an Unprotected CWT Claims Set (UCCS) [RFC9781] can be signed the way Section 4.1 describes ✍️

Section 4 lays out a bunch of methods you can use to add cryptographic protection to CMW, so go check those out πŸ¦‹

8.2. Using Collection CMWs for Evidence of Composite or Layered Devices

okay this one is SERIOUS 😭 when a Collection CMW is used to wrap Evidence for composite or layered attestation of a single device, all Evidence messages inside the CMW MUST be cryptographically bound together. the whole point is stopping an attacker from swapping Evidence from a compromised device with Evidence from a clean one 🚨 if the Collection CMW isn't protected from tampering by outside security measures (like object security primitives) or inside mechanisms (like intra-item binding), an attacker could mess with what's in the collection and trick the Verifier into accepting fake Evidence as legit πŸ™…β€β™€οΈ

authenticity and integrity protection are expected to come from the underlying attestation technology 🧚 for example, the key material used to sign or bind an entire Collection CMW should be an attestation key, handled the way Section 12.1 of [RFC9334] describes. the binding doesn't have to be a signature over the Collection CMW, though πŸ™Œ it could also come from identifiers, linking claims (like nonces) across the Collection CMW items, or signing or hashing between the members of the collection. and the Attester who creates the Collection CMW is the one responsible for making sure the contents of the collection are integrity protected 🫢

8.3. Integrating CMW into Protocols

when CMW gets integrated into some hosting protocol (like attested CSR [RA-CERT-SIGN] or attested TLS [RA-TLS-DTLS] [RA-EXP-AUTH]), that hosting protocol is the one that has to describe how CMW is meant to be used and how it fits into the overall security model 🌸

that analysis should look at the types of conceptual messages allowed (including which combinations are permitted), the protection requirements, the interface with the hosting protocol, and any other security-relevant stuff that comes out of the interaction between the CMW assembly and the hosting protocol πŸ”₯

9. IANA Considerations πŸ“‹

9.1. CWT cmw Claim Registration

IANA added a brand new cmw claim to the "CBOR Web Token (CWT) Claims" registry [IANA.cwt], and it looks like this ✨

Claim Name:  cmw
Claim Description:  RATS Conceptual Message Wrapper
JWT Claim Name:  cmw
Claim Key:  299
Claim Value Type:  CBOR map, CBOR array, or CBOR tag
Change Controller:  IETF
Reference:  Sections 3.1, 3.2, and 3.3 of RFC 9999

9.2. JWT cmw Claim Registration

IANA also added a new cmw claim to the "JSON Web Token Claims" registry inside the "JSON Web Token (JWT)" registry group [IANA.jwt] πŸŽ€

Claim Name:  cmw
Claim Description:  RATS Conceptual Message Wrapper
Change Controller:  IETF
Reference:  Sections 3.1 and 3.3 of RFC 9999

9.3. +jws Structured Syntax Suffix

IANA registered the +jws structured syntax suffix in the "Structured Syntax Suffixes" registry [IANA.structured-suffixes], following the process in [RFC6838] πŸ’– it can be used to say the media type is encoded as JWS [RFC7515] 🧁

9.3.1. Registry Entry

Name:  JSON Web Signature (JWS)

+suffix:  +jws

References:  [RFC7515]

Encoding Considerations:  binary.  Values are represented as a JSON
   Object or as a series of base64url-encoded values, each separated
   from the next by a single period ('.') character.

Interoperability Considerations:  N/A

Fragment Identifier Considerations:  N/A

Security Considerations:  See Section 10 of [RFC7515]

Contact:  RATS WG mailing list (rats@ietf.org) or IETF Security Area
   (saag@ietf.org)

Author/Change Controller:  Remote ATtestation procedureS (RATS)
   Working Group.  The IETF has change control over this
   registration.

9.4. RATS Conceptual Message Wrapper (CMW) Indicators Registry

IANA created a new "RATS Conceptual Message Wrapper (CMW) Indicators" registry inside the "Remote Attestation Procedures (RATS)" registry group [IANA.rats] 🌈 the registration procedure for it is IETF Review (Section 4.8 of [RFC8126]) πŸ’…

the goal is to register CMW Indicator values for all RATS conceptual messages (see Section 8 of [RFC9334]) ⭐

indicator values should be added in ascending order, with no gaps between them πŸ”’

acceptable values line up with the RATS conceptual messages defined by the RATS architecture [RFC9334] and any updates to it πŸ¦‹

9.4.1. Structure of Entries ✨

okay so every entry in the "RATS Conceptual Message Wrapper (CMW) Indicators" registry must have these three fields, no skipping 🫢

  • Indicator Value: a number that matches the bit position in the ind bitmap (Section 3.1).
  • Conceptual Message Name: a text string describing the RATS conceptual message this indicator is for.
  • Reference: a reference to the document that defines the entry.

The starting contents of the registry are in Table 1, and honestly it's giving very organized 🌸

+=================+=========================+===============+
| Indicator Value | Conceptual Message Name | Reference     |
+=================+=========================+===============+
| 0               | Reference Values        | Section 3.1.1 |
|                 |                         | of RFC 9999   |
+-----------------+-------------------------+---------------+
| 1               | Endorsements            | Section 3.1.1 |
|                 |                         | of RFC 9999   |
+-----------------+-------------------------+---------------+
| 2               | Evidence                | Section 3.1.1 |
|                 |                         | of RFC 9999   |
+-----------------+-------------------------+---------------+
| 3               | Attestation Results     | Section 3.1.1 |
|                 |                         | of RFC 9999   |
+-----------------+-------------------------+---------------+
| 4               | Appraisal Policy        | Section 3.1.1 |
|                 |                         | of RFC 9999   |
+-----------------+-------------------------+---------------+
| 5-31            | Unassigned              |               |
+-----------------+-------------------------+---------------+

Table 1: Initial Contents of the RATS CMW Indicators Registry

9.5. Media Types πŸŽ€

IANA has added the following media types to the "Media Types" registry [IANA.media-types] πŸ¦‹

+==========+======================+=====================+
| Name     | Template             | Reference           |
+==========+======================+=====================+
| cmw+cbor | application/cmw+cbor | Sections 3.1, 3.2,  |
|          |                      | and 3.3 of RFC 9999 |
+----------+----------------------+---------------------+
| cmw+json | application/cmw+json | Sections 3.1 and    |
|          |                      | 3.3 of RFC 9999     |
+----------+----------------------+---------------------+
| cmw+cose | application/cmw+cose | Section 4.1 of RFC  |
|          |                      | 9999                |
+----------+----------------------+---------------------+
| cmw+jws  | application/cmw+jws  | Section 4.2 of RFC  |
|          |                      | 9999                |
+----------+----------------------+---------------------+

Table 2: CMW Media Types

9.5.1. application/cmw+cbor πŸ’œ

  • Type name: application
  • Subtype name: cmw+cbor
  • Required parameters: N/A
  • Optional parameters: cmwc_t, the Collection CMW type in string format. OIDs must use the dotted-decimal notation. The parameter value is case-insensitive. It must not be used for CMWs that are not collections.
  • Encoding considerations: binary (CBOR)
  • Security considerations: Section 8 of RFC 9999 πŸ”
  • Interoperability considerations: N/A
  • Published specification: RFC 9999
  • Applications that use this media type: Attesters, Verifiers, Endorsers and Reference-Value providers, and 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

9.5.2. application/cmw+json 🌈

  • Type name: application
  • Subtype name: cmw+json
  • Required parameters: N/A
  • Optional parameters: cmwc_t, the Collection CMW type in string format. OIDs must use the dotted-decimal notation. The parameter value is case-insensitive. It must not be used for CMWs that are not collections.
  • Encoding considerations: binary (JSON is UTF-8-encoded text)
  • Security considerations: Section 8 of RFC 9999 πŸ”
  • Interoperability considerations: N/A
  • Published specification: RFC 9999
  • Applications that use this media type: Attesters, Verifiers, Endorsers and Reference-Value providers, and 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

9.5.3. application/cmw+cose πŸ¦‹

  • Type name: application
  • Subtype name: cmw+cose
  • Required parameters: N/A
  • Optional parameters: cmwc_t, the Collection CMW type in string format. OIDs must use the dotted-decimal notation. The parameter value is case-insensitive. It must not be used for CMWs that are not collections. Note that the cose-type parameter is explicitly not supported, as it is understood to be "cose-sign1". πŸ™ˆ
  • Encoding considerations: binary (CBOR)
  • Security considerations: Section 8 of RFC 9999 πŸ”
  • Interoperability considerations: N/A
  • Published specification: RFC 9999
  • Applications that use this media type: Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer CMW payloads over HTTP(S), CoAP(S), and other transports.
  • Fragment identifier considerations: N/A
  • 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

9.5.4. application/cmw+jws ✨

  • Type name: application
  • Subtype name: cmw+jws
  • Required parameters: N/A
  • Optional parameters: cmwc_t, the Collection CMW type in string format. OIDs must use the dotted-decimal notation. The parameter value is case-insensitive. It must not be used for CMWs that are not collections.
  • Encoding considerations: 8bit. Values are represented as a JSON Object or as a series of base64url-encoded values, each separated from the next by a single period ('.') character.
  • Security considerations: Section 8 of RFC 9999 πŸ”
  • Interoperability considerations: N/A
  • Published specification: RFC 9999
  • Applications that use this media type: Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer CMW payloads over HTTP(S), CoAP(S), and other transports.
  • Fragment identifier considerations: N/A
  • 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

9.6. CoAP Content-Formats πŸ“

IANA has registered the following Content-Format IDs in the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group [IANA.core-parameters] πŸ’–

+======================+================+=====+=====================+
| Content-Type         | Content Coding | ID  | Reference           |
+======================+================+=====+=====================+
| application/         |       -        | 273 | Sections 3.1, 3.2,  |
| cmw+cbor             |                |     | and 3.3 of RFC 9999 |
+----------------------+----------------+-----+---------------------+
| application/         |       -        | 274 | Sections 3.1 and    |
| cmw+json             |                |     | 3.3 of RFC 9999     |
+----------------------+----------------+-----+---------------------+
| application/         |       -        | 275 | Section 4.1 of RFC  |
| cmw+cose             |                |     | 9999                |
+----------------------+----------------+-----+---------------------+
| application/         |       -        | 276 | Section 4.2 of RFC  |
| cmw+jws              |                |     | 9999                |
+----------------------+----------------+-----+---------------------+

Table 3: CoAP Content-Formats

9.6.1. Registering New CoAP Content-Formats for Parameterized CMW Media Types πŸ‘‘

New CoAP Content-Formats can be created based on parameterized instances of the application/cmw+json, application/cmw+cbor, application/cmw+cose, and application/cmw+jws media types.

When assigning a new CoAP Content-Format ID for a CMW media type that utilizes the cmwc_t parameter, the registrar must check (directly or through the designated expert) the following:

  • The corresponding CMW is a collection (Section 3.3).
  • The cmwc_t value is either an (non-relative) OID or an absolute URI.
Heads up bestie: those two checks are the whole vibe for cmwc_t Content-Formats, so don't skip them 🫢

9.6.2. CBOR Tags per RFC 9277 🧚

Registering the CoAP Content-Formats listed in Table 3 automatically allocates CBOR tags in the range [1668546817, 1668612095] using the TN() transform defined in Appendix B of [RFC9277]. The allocated CBOR tag numbers and the corresponding data items are shown in Table 4.

Note that CMWs in Tag and Record form are excluded. This is because they can already be represented as a CMW, so the extra wrapping would be redundant. πŸ™ƒ

+============+===============================+
| Tag Number | Tag Content                   |
+============+===============================+
| 1668547091 | bytes .cbor cbor-collection   |
+------------+-------------------------------+
| 1668547092 | bytes .cbor signed-cbor-cmw   |
+------------+-------------------------------+
| 1668547093 | bytes-wrapped json-collection |
+------------+-------------------------------+
| 1668547094 | bytes-wrapped signed-json-cmw |
+------------+-------------------------------+

Table 4: TN-Derived CBOR Tags

Figure 7 extends the $cbor-tag socket defined in Section 3.2 to add the definitions of the associated Tag CMWs. πŸ’…

$cbor-tag /= tag-cm-cbor<1668547091, cbor-collection>
$cbor-tag /= tag-cm-cbor<1668547092, signed-cbor-cmw>
$cbor-tag /= tag-cm-data<1668547093> ; bytes(cmw+json collection)
$cbor-tag /= tag-cm-data<1668547094> ; bytes(cmw+jws)

Figure 7: Tag CMW Definitions

9.7. SMI Number Registration πŸ”’βœ¨

okay bestie, IANA has given the CMW extension its very own OID in the "SMI Security for PKIX Certificate Extension" registry, which is part of the "Structure of Management Information (SMI) Numbers (MIB Module Registrations)" registry group [IANA.smi-numbers]. it's giving official πŸ’… Section 4.4 is the one that defines the extension, so here's the entry:

+=========+=============+=========================+
| Decimal | Description | Reference               |
+=========+=============+=========================+
| 35      | id-pe-cmw   | Section 4.4 of RFC 9999 |
+---------+-------------+-------------------------+

             Table 5: CMW Extension OID

IANA also gave an OID to the ASN.1 module defined in Section 4.4.1. That one goes in the "SMI Security for PKIX Module Identifier" registry, which lives in the same registry group [IANA.smi-numbers]. Main character energy πŸŽ€

+=========+=================+===========================+
| Decimal | Description     | Reference                 |
+=========+=================+===========================+
| 123     | id-mod-cmw-extn | Section 4.4.1 of RFC 9999 |
+---------+-----------------+---------------------------+

                Table 6: ASN.1 Module OID

10. References πŸ“šπŸ«Ά

okay so this is the reading list, and honestly it's the receipts 🧾 The references are split into normative and informative pieces. Here's the normative part first, since the spec really needs all of it.

10.1. Normative References 🌸

More references are coming up in the next part, so stay tuned πŸ§šπŸ’œ

10.2. Informative References πŸ¦‹

okay so these are the "for context" refs πŸ“š they're not the core spec stuff, but they're the receipts for the attestation world this doc lives in ✨

Appendix A. Registering and Using CMWs πŸŽ€

okay so Figure 8 is the cheat sheet for how to register stuff before you use CMWs πŸ’… it covers both Record CMW and Tag CMW forms. if you're using a Collection CMW, the same preconditions apply to every single entry in the collection 🫢

        .---------------.   .---------.
       | Reuse EAT/CoRIM | | Register  |
       | media type(s)   | | new media |
       | + profile       | | type      |
        `---+----+------'   `-+----+--'
            |    |            |    |
            |  .-+------------+-.  |
            | |  |  Register  |  | |
          .-(-+-'   new CoAP   `-+-(-.
         |  | |  Content-Format  | |  |
         |  |  `-------+--------'  |  |
         |  |          |           |  |
         |  |          v           |  |
         |  |   .--------------.   |  |
         |  |  | Automatically  |  |  |
         |  |  | derive CBOR    |  |  |
         |  |  | tag (RFC 9277) |  |  |
         |  |   `------+-------'   |  |
         |  |          |           |  |
         |  |          |           |  |
         |  |          |           |  |
         |  |          v           |  |
         |  |   .----------------. |  |
         |  |  /    Tag CMW     /  |  |
         v  v `----------------'   v  v
     .--------------------------------------.
    /             Record CMW               /
   `--------------------------------------'

                       Figure 8: How to Create a CMW

Acknowledgments πŸ’–

the authors wanna give a huge shoutout πŸ“£ to Alexey Melnikov, Amanda Baber, Benjamin Schwartz, Brian Campbell, Carl Wallace, Carsten Bormann, Christian AmsΓΌss, Dave Thaler, Deb Cooley, Dionna Glaze, Γ‰ric Vyncke, IonuΘ› Mihalcea, Mahesh Jethanandani, Michael B. Jones, Mike Ounsworth, Michael StJohns, Mike Bishop, Mohamed Boucadair, Mohit Sethi, Orie Steele, Paul Howard, Peter Yee, Russ Housley, Steven Bellock, Tim Bray, Tom Jones, and Usama Sardar for reviewing and giving suggestions 🌸

the Collection CMW idea is based on a proposal Simon Frost first made for an EAT-based Evidence collection type πŸ¦‹ the Collection CMW is meant to supersede it by widening the Evidence formats it allows ✨

Contributors 🧚

  • Laurence Lundblade
    • Security Theory LLC
    • Email: lgl@securitytheory.com

laurence made big contributions to beefing up the security requirements and considerations for Collection CMWs πŸ”₯

Authors' Addresses 🌈

  • Henk Birkholz
    • Fraunhofer SIT
    • Email: henk.birkholz@ietf.contact
  • Ned Smith
    • Independent
    • Email: ned.smith.ietf@outlook.com
  • Thomas Fossati
    • Linaro
    • Email: thomas.fossati@linaro.org
  • Hannes Tschofenig
    • University of the Bundeswehr Munich
    • Institute of Distributed Intelligent Systems
    • Werner-Heisenberg-Weg 39
    • 85577 Neubiberg
    • Germany
    • Email: Hannes.Tschofenig@gmx.net

that's the whole spec, bestie!! πŸŒˆπŸ’œβœ¨

πŸ“¦ where this page comes from