RFC 10013

Entity Attestation Token (EAT) Measured Component

📅 published July 2026, from ietf

Entity Attestation Token (EAT) Measured Component 🦋

okay bestie, this is RFC 10013 🎀 It's a Standards Track doc from the IETF (ISSN 2070-1721), dated July 2026. The authors are S. Frost (Arm), T. Fossati (Linaro), H. Tschofenig (UniBw M.), and H. Birkholz (Fraunhofer SIT). The title block doesn't list any RFCs that it obsoletes or updates ✨

Abstract ✨

so the phrase "measured component" means an object inside the attester's target environment whose state can be sampled and usually digested with a cryptographic hash function 🔥 Think firmware in flash, software loaded into memory at start time, data in a file system, or a CPU register 💖 This doc gives you the information model for a measured component plus two data models built on it. The split is intentional 🧚 The JSON and CBOR serializations, along with their media types and CoAP Content-Formats, let you use the semantics straight away in the Entity Attestation Token (EAT) framework. The information model, meanwhile, can be reused later for other serializations, like ASN.1, for example 💅

Status of This Memo 📜

this is an Internet Standards Track document 🎀

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 🌸

for the current status, any errata, and how to send feedback, look at https://www.rfc-editor.org/info/rfc10013 ✨

Copyright Notice ⭐

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this doc must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License 🫶

Table of Contents 🗂️

   1.  Introduction
   2.  Conventions and Definitions
   3.  Information Model
   4.  Data Models
     4.1.  Common Types
     4.2.  The digest Type
     4.3.  The measured-component Data Item
       4.3.1.  Component Identifier
       4.3.2.  Authority Identifier
       4.3.3.  Profile-Specific Flags
     4.4.  EAT measurements-format Extensions
       4.4.1.  measurements-format for CBOR EAT
       4.4.2.  measurements-format for JSON EAT
     4.5.  EAT Profiles and Measured Components
     4.6.  Examples
   5.  Security Considerations
   6.  Privacy Considerations
   7.  IANA Considerations
     7.1.  Media Type Registrations
       7.1.1.  application/measured-component+cbor
       7.1.2.  application/measured-component+json
     7.2.  Measured Component Content-Format Registrations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Appendix A.  Collated CDDL
   Acknowledgments
   Authors' Addresses

1. Introduction 🌈

okay so [RFC9711] Section 4.2.16 defines a Measurement claim that:

[c]ontains descriptions, lists, evidence, or measurements of the software that exists on the entity or on any other measurable subsystem of the entity

this claim can carry different measurement formats, and each one gets its own CoAP Content-Format (Section 12.3 of [RFC7252]) ✨ Right now, the only format that's been specified is Concise Software Identification (CoSWID) Tags of type "evidence", per Section 2.9.4 of [RFC9393] 💅 Here's the catch: CoSWID isn't a good fit for measurements that can't be anchored to a file system, like the ones in early boot environments 🙈 So this doc brings in a measured component format that works with the EAT Measurement claim, either alongside CoSWID or instead of it 🔥

the term "measured component" refers to an object inside the attester's target environment whose state can be sampled and usually digested with a cryptographic hash function. For example, that could be the invariant part of a firmware component loaded into memory at startup, a Run-Time Integrity Check (RTIC), a file system object, or a CPU register 🧚

this doc gives you the information model for the measured component and two associated data models [RFC3444]. The split is on purpose 💖 The JSON and CBOR serializations, together with their media types and CoAP Content-Formats, let you use the semantics right away in the EAT framework. The information model can be reused in future specs for other serializations, like ASN.1 for example. This approach matches the guidance in Section 5.2 of [OPS-MGMT] 🎀

2. Conventions and Definitions 📖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like here 🫶

in this doc, the Concise Data Definition Language (CDDL) [RFC8610] [RFC9165] [RFC9741] describes the data formats 🧚 It uses these CDDL control operators: .b64u, defined in Section 2.1 of [RFC9741]; .json, defined in Section 2.4 of [RFC9741]; and .cbor, defined in Section 3.8.4 of [RFC8610] 💜

examples are folded following the conventions in [RFC8792] ✨

3. Information Model 🍓

this section lays out the information model of a measured component 💅

a measured component Information Element (IE) holds the component's sampled state, either digested or raw, plus metadata that helps identify the component 🌸 Optionally, you can also list any entities responsible for signing the installed component 🦋

Table 1 lists the IEs that make up a measured component:

    +=============+=====================================+=============+
    | IE          | Description                         | Requirement |
    |             |                                     | Level       |
    +=============+=====================================+=============+
    | Component   | The name given to the measured      | REQUIRED    |
    | Name        | component.  It is important that    |             |
    |             | this name remains consistent across |             |
    |             | different releases to allow for     |             |
    |             | better tracking of the same         |             |
    |             | measured item across updates.  When |             |
    |             | combined with a consistent          |             |
    |             | versioning scheme, it enables       |             |
    |             | better signaling from the appraisal |             |
    |             | procedure to the relying parties.   |             |
    +-------------+-------------------------------------+-------------+
    | Component   | A value representing the specific   | OPTIONAL    |
    | Version     | release or development version of   |             |
    |             | the measured component.  Using      |             |
    |             | Semantic Versioning [SEMVER] is     |             |
    |             | RECOMMENDED.                        |             |
    +-------------+-------------------------------------+-------------+
    | Digested or | Either the raw value or the         | REQUIRED    |
    | Raw Value   | digested value of the measured      |             |
    |             | component.                          |             |
    +-------------+-------------------------------------+-------------+
    | Digest      | Hash algorithm used to compute the  | REQUIRED    |
    | Algorithm   | Digest Value.                       | only if the |
    |             |                                     | value is in |
    |             |                                     | the         |
    |             |                                     | digested    |
    |             |                                     | form        |
    +-------------+-------------------------------------+-------------+
    | Authorities | One or more entities that can       | OPTIONAL    |
    |             | authoritatively identify the        |             |
    |             | component being measured.           |             |
    +-------------+-------------------------------------+-------------+

              Table 1: Measured Component Information Elements

a data model that implements this information model SHOULD allow a limited amount of extensibility, so profiles can add their own semantics 🧚

4. Data Models 💖

this section presents coordinated JSON and CBOR data models, and both implement the information model from Section 3 ✨

the data model takes its inspiration from the "PSA software component" claim (Section 4.4.1 of [RFC9783]). That claim got refactored to follow the recommendations for designing new EAT claims in Appendix E of [RFC9711] 🎀

CDDL expresses the rules and constraints of the data model for both JSON and CBOR. These rules must be strictly followed when you create or validate measured component data items 🔥 When JSON and CBOR differ, the CDDL generic JC<>, defined in Appendix D of [RFC9711], is used 🫶

4.1. Common Types 🧸

three basic types show up all over the measured component data model 🌸

bytes-b64u = text .b64u bytes
bytes8 = bytes .size 8
bytes8-b64u = text .b64u bytes8

4.2. The digest Type 🔐

a digest is the result of a hashing operation, bundled with the hash algorithm that made it 🦋 The digest algorithm identifier can be either an int or a text, and it's read according to the "Named Information Hash Algorithm Registry" IANA registry [IANA.named-information]. Specifically, int values match against "ID" entries, and text values match against "Hash Name String" entries 💅 Whenever it's possible, using the int encoding is RECOMMENDED 💜

digest = [
  alg: (int / text)
  val: digest-value-type
]

digest-value-type = eat.JC<bytes-b64u, bytes>

4.3. The measured-component Data Item ✨

okay so this is the main character 👑 the measured-component data item is the whole package for ONE measured thing (a bootloader, a config blob, even a CPU register 🧠). here's the shape, bestie 💅

measured-component = {
  component-id-label => component-id
  measurement
  ? authorities-label => [ + authority-id-type ]
  ? flags-label => flags-type
}

measurement //= ( digested-measurement-label => digest )
measurement //= ( raw-measurement-label => bytes )

authority-id-type = eat.JC<bytes-b64u, bytes>
flags-type = eat.JC<bytes8-b64u, bytes8>

component-id-label = eat.JC<"id", 1>
digested-measurement-label = eat.JC<"digested-measurement", 2>
raw-measurement-label = eat.JC<"raw-measurement", 5>
authorities-label = eat.JC<"authorities", 3>
flags-label = eat.JC<"flags", 4>

so the members of the measured-component CBOR map / JSON object are:

id (index 1): the measured component identifier, encoded according to the format in Section 4.3.1 🎀
measurements: either a digest value and digest algorithm (index 2), encoded using the digest format (Section 4.2), or the "raw" measurement (index 5), encoded as a byte string. ngl the digested form has a fixed size because the digest function sets it, but the raw form can be wildly different sizes depending on what you're measuring (a CPU register, or a whole configuration blob, for example) 🙈 so a decoder implementation may decide to limit how much memory it allocates to this specific field.
authorities (index 3): one or more authorities, see Section 4.3.2 🔐
flags (index 4): a 64-bit field with profile-defined semantics, see Section 4.3.3 🦋

4.3.1. Component Identifier 🧩

the component-id data item looks like this:

component-id = [
  name:      text
  ? version: version
]

;# import coswid.$version-scheme from rfc9393 as coswid

version = [
  val:      text
  ? scheme: coswid.$version-scheme
]

name: a string that gives a human-readable identifier for the component. the format and conventions depend on the component type 💖
version: a compound version data item that reuses the encoding and semantics of sw-version-type from [RFC9711], extending it to non-software components ✨

the complete definition of sw-version-type depends on the $version-scheme CDDL socket defined in Section 2.2 of [RFC9393]. 👀

4.3.2. Authority Identifier 🔏

an authority is an entity that can authoritatively identify a given component by digitally signing it 💅. this signature is usually checked during installation (Section 7 of [RFC9019]), or when the measured component gets executed by the boot firmware, operating system, or application launcher. like, that's how it works with UEFI Secure Boot [UEFI2] and Arm Trusted Board Boot [TBBR-CLIENT]. another example could be the controlling entity in an app store 🛍️

ok but this part is SO important: this signature has nothing to do with the attester's signature on the EAT-formatted evidence 🙅‍♀️. so an authority identifier doesn't, by itself, tell you who signed the enclosing EAT-formatted evidence. not me mixing those two up 😭

an authority is identified by its signing public key. it could be an X.509 certificate, a raw public key, a public key thumbprint, or some other identifier that can be uniquely tied to the signing entity 🗝️. sometimes multiple parties need to sign a component to show they endorse or approve it 🫶. that could include roles like a firmware update system, a fleet owner, or a third-party auditor. what each signature means can depend on the deployment, and the order of the authorities in the array could carry meaning too 🌈

if an EAT profile (Section 6 of [RFC9711]) uses measured components, it MUST specify whether the authorities field is used. if it is used, the profile MUST also specify what each entry in the authorities array represents and how to interpret the corresponding authority-id-type. no skipping this one, periodt 💀

the authority-id-type is defined like this:

authority-id-type = eat.JC<bytes-b64u, bytes>

4.3.3. Profile-Specific Flags 🚩

this field is optional 🎟️ and it can hold up to 64 bits of profile-defined semantics. that lets a profile of this specification pack in extra info and extend the base type. it's great for fixed-size chunks, like a bit mask or one value picked from a predetermined set of codepoints 🍓. no matter what the internal structure looks like, this field is always exactly 8 bytes, so iconic 🙌

the flags-type is defined like this:

flags-type = eat.JC<bytes8-b64u, bytes8>

if an EAT profile (Section 6 of [RFC9711]) uses measured components, it MUST specify whether the flags field is used. if it is used, the profile MUST also specify how to interpret the 64 bits 🔢

4.4. EAT measurements-format Extensions 🎀

the CDDL in Figure 1 extends the $measurements-body-cbor and $measurements-body-json EAT sockets so measured-components can show up in the Measurement claim 🧚

mc-cbor = bytes .cbor measured-component
mc-json = text .json measured-component

; EAT CBOR (`.feature "cbor"`)
$measurements-body-cbor /= mc-cbor ; homogeneous
$measurements-body-cbor /= mc-json ; tunnel

; EAT JSON (`.feature "json"`)
$measurements-body-json /= mc-json            ; homogeneous
$measurements-body-json /= text .b64u mc-cbor ; tunnel

Figure 1: EAT measurements-format Extensions

each socket gets two new types ✨. the "homogeneous" one is used when the measured-component and the EAT have the same serialization (like, they're both CBOR). the "tunnel" one is used when the serializations are different 🦋

4.4.1. measurements-format for CBOR EAT 💜

the entries in Table 2 are the allowed content-type/content-format pairs when the measured-component is carried in a CBOR EAT 📦

note how the "homogeneous" and "tunnel" formats from Figure 1 get used, and how the matching CoAP Content-Format describes the original serialization 🫶

      +=====================================+================+
      | content-type (CoAP C-F equivalent)  | content-format |
      +=====================================+================+
      | application/measured-component+cbor | mc-cbor        |
      +-------------------------------------+----------------+
      | application/measured-component+json | mc-json        |
      +-------------------------------------+----------------+

Table 2: measurements-format for EAT CBOR Web Token (CWT)

4.4.2. measurements-format for JSON EAT 🌸

Table 3 is the JSON version of Table 2, for JSON-serialized EAT 💖

    +=====================================+====================+
    | content-type (CoAP C-F equivalent)  | content-format     |
    +=====================================+====================+
    | application/measured-component+json | mc-json            |
    +-------------------------------------+--------------------+
    | application/measured-component+cbor | tstr .b64u mc-cbor |
    +-------------------------------------+--------------------+

Table 3: measurements-format for EAT JSON Web Token (JWT)

4.5. EAT Profiles and Measured Components 👑

the semantics of the authorities and profile flags fields are defined by the applicable EAT profile, i.e., the profile of the wrapping EAT 🎁

if the profile of the EAT isn't known to the consumer, and one or more measured components inside that EAT include authorities and/or profile flags, the consumer MUST reject the EAT. no exceptions, no cap 🚫

4.6. Examples 🧁

the example in Figure 2 is a digested measured component with every field filled in 🥰

{
  / id / 1: [
    / name / "boot loader X",
    / version / [
      "1.2.3rc2",
      16384 / semver /
    ]
  ],
  / measurement / 2: [
    / alg / "sha-256",
    / val / h'3996003d486fb91ffb056f7d03f2b2992b215b31dbe7af4b37
              3431fc7d319da3'
  ],
  / authorities / 3: [
    h'492e9b676c21f6012b1ceeb9032feb4141a880797355f6675015ec59c5
      1ca1ec',
    h'4277bb97ba7b51577a0d38151d3e08b40bdf946753f5b5bdeb814d6ff5
      7a8a5e'
  ],
  / flags / 4: h'0000000000000101'
}

Figure 2: Complete Measured Component

the example in Figure 3 is the same measured component as above, but used as the format of a Measurement claim in an EAT claims-set 🧚‍♀️

this example uses 295 as the content-type value of the measurements-format entry 🔢

the array only has one measured component here, but more entries could be added if the measured Trusted Computing Base (TCB) is made of multiple individually measured components 🧩

{
  273: [
    [
      295, / measured-component+cbor /
      <<
        {
          / id / 1: [
            / name / "boot loader X",
            / version / [
              "1.2.3rc2",
              16384 / semver /
            ]
          ],
          / measurement / 2: [
            / alg / "sha-256",
            / val / h'3996003d486fb91ffb056f7d03f2b2992b215b31db
                      e7af4b373431fc7d319da3'
          ],
          / authorities / 3: [
            h'492e9b676c21f6012b1ceeb9032feb4141a880797355f66750
              15ec59c51ca1ec',
            h'4277bb97ba7b51577a0d38151d3e08b40bdf946753f5b5bdeb
              814d6ff57a8a5e'
          ]
        }
      >>
    ]
  ]
}

Figure 3: EAT Measurements Claim Using a Measured Component (CBOR)

the example in Figure 4 shows a JSON measured component inside a JSON EAT 🌈

this example uses 296 as the content-type value of the measurements-format entry 💜

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

{
  "measurements": [
    [
      296,
      "{ \"id\": [ \"boot loader X\", [ \"1.2.3rc2\", 16384 ] ], \"\
digested-measurement\": [ \"sha-256\", \"\
OZYAPUhvuR_7BW99A_KymSshWzHb569LNzQx_H0xnaM\" ], \"authorities\": [ \
\"SS6bZ2wh9gErHO65Ay_rQUGogHlzVfZnUBXsWcUcoew\", \"\
                   Qne7l7p7UVd6DTgVHT4ItAvflGdT9bW964FNb_V6il4\" ] }"
    ]
  ]
}

Figure 4: EAT Measurements Claim Using a Measured Component (JSON)

the example shown in Figure 5 is a measured component representing a boot loader, identified by its path name 🗂️

{
  / id / 1: [
    / name / "/boot/loader.bin"
  ],
  / measurement / 2: [
    / alg / "sha-384",
    / val / h'66ec2fb4e02d8c8b3eee320e750d9389d66c52c51db11cc6
              9cc5e410816283ed60ba573795f5fcc85e513af57b3f6def'
  ],
  / flags / 4: h'0000000000000101'
}

Figure 5: Digested Measured Component Using a File Path as an Identifier

the example in Figure 6 is a raw measured component 🌟

{
  / id / 1: [
    / name / "hardware-config"
  ],
  / measurement / 5: h'4f6d616861'
}

Figure 6: Raw Measured Component

5. Security Considerations 🔐

okay bestie, big reminder: the security stuff in Sections 9.1 (Claim Trustworthiness), 9.4 (Multiple EAT Consumers), and 9.5 (Detached EAT Bundle Digest Security Considerations) of [RFC9711] applies here too, no cap. ngl, if you serialize the measured component information model with a data model that isn't one of the ones in this doc, similar security considerations may apply, so don't assume you're off the hook 👀

The Component Name and Component Version can literally hand an attacker detailed info about the software running on a device AND its configuration settings 😭 that's juicy intel for a bad actor.

Any textual fields (e.g., Component Name and Component Version) that get stored in a file, inserted into a database, or displayed to humans must be properly sanitized to prevent attacks and undesirable behavior. More discussion and references on this topic are in Section 7 of [RFC9839] 📚

If the component measurement is digested, the digest must be computed using a strong cryptographic hash function. Strong hashing or bust, periodt 🔥

6. Privacy Considerations 🎀

The differential encryption considerations discussed in Section 9.4 (Multiple EAT Consumers) of [RFC9711] also apply to this document. It's giving careful with who gets to see what 🦋

The Component Name and Component Version may reveal private information about a device and its owner. Private info alert! 🙈

Additionally, the stability requirement of the Component Name may enable tracking. Stable names are cute until they become a tracking beacon 💀

7. IANA Considerations 🌸

7.1. Media Type Registrations

IANA has added the following media types to the "Media Types" registry [IANA.media-types]. Two new looks for our measured component data, both registered and ready to slay ✨

+=========================+=========================+===========+
| Name                    | Template                | Reference |
+=========================+=========================+===========+
| measured-component+cbor | application/measured-   | RFC 10013 |
|                         | component+cbor          |           |
+-------------------------+-------------------------+-----------+
| measured-component+json | application/measured-   | RFC 10013 |
|                         | component+json          |           |
+-------------------------+-------------------------+-----------+

                  Table 4: Measured Component Media Types

7.1.1. application/measured-component+cbor

Type name:  application

Subtype name:  measured-component+cbor

Required parameters:  N/A

Optional parameters:  N/A

Encoding considerations:  binary (CBOR)

Security considerations:  Section 5 of RFC 10013

Interoperability considerations:  N/A

Published specification:  RFC 10013

Applications that use this media type:  Attesters, Verifiers, and
   Relying Parties

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

7.1.2. application/measured-component+json

Type name:  application

Subtype name:  measured-component+json

Required parameters:  N/A

Optional parameters:  N/A

Encoding considerations:  binary (JSON is UTF-8-encoded text)

Security considerations:  Section 5 of RFC 10013

Interoperability considerations:  N/A

Published specification:  RFC 10013

Applications that use this media type:  Attesters, Verifiers, and
   Relying Parties

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

7.2. Measured Component Content-Format Registrations

IANA has registered these two Content-Format numbers in the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group [IANA.core-parameters] as follows. CoAP folks, these IDs are yours now 🧚

   +=========================+================+=====+===========+
   | Content Type            | Content Coding | ID  | Reference |
   +=========================+================+=====+===========+
   | application/measured-   | -              | 295 | RFC 10013 |
   | component+cbor          |                |     |           |
   +-------------------------+----------------+-----+-----------+
   | application/measured-   | -              | 296 | RFC 10013 |
   | component+json          |                |     |           |
   +-------------------------+----------------+-----+-----------+

            Table 5: Content-Format Number Registrations

8. References 📚

8.1. Normative References

[IANA.named-information]
           IANA, "Named Information Hash Algorithm Registry",
           <https://www.iana.org/assignments/named-information>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
           Application Protocol (CoAP)", RFC 7252,
           DOI 10.17487/RFC7252, June 2014,
           <https://www.rfc-editor.org/info/rfc7252>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
           Definition Language (CDDL): A Notational Convention to
           Express Concise Binary Object Representation (CBOR) and
           JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
           June 2019, <https://www.rfc-editor.org/info/rfc8610>.

[RFC8792]  Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
           "Handling Long Lines in Content of Internet-Drafts and
           RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
           <https://www.rfc-editor.org/info/rfc8792>.

[RFC9165]  Bormann, C., "Additional Control Operators for the Concise
           Data Definition Language (CDDL)", RFC 9165,
           DOI 10.17487/RFC9165, December 2021,
           <https://www.rfc-editor.org/info/rfc9165>.

[RFC9393]  Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
           Waltermire, "Concise Software Identification Tags",
           RFC 9393, DOI 10.17487/RFC9393, June 2023,
           <https://www.rfc-editor.org/info/rfc9393>.

[RFC9711]  Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
           Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
           DOI 10.17487/RFC9711, April 2025,
           <https://www.rfc-editor.org/info/rfc9711>.

[RFC9741]  Bormann, C., "Concise Data Definition Language (CDDL):
           Additional Control Operators for the Conversion and
           Processing of Text", RFC 9741, DOI 10.17487/RFC9741, March
           2025, <https://www.rfc-editor.org/info/rfc9741>.

[SEMVER]   "Semantic Versioning 2.0.0",
           <https://semver.org/spec/v2.0.0.html>.

8.2. Informative References

[IANA.core-parameters]
           IANA, "Constrained RESTful Environments (CoRE)
           Parameters",
           <https://www.iana.org/assignments/core-parameters>.

[IANA.media-types]
           IANA, "Media Types",
           <https://www.iana.org/assignments/media-types>.

[OPS-MGMT] Claise, B., Clarke, J., Farrel, A., Barguil, S.,
           Pignataro, C., and R. Chen, "Guidelines for Considering
           Operations and Management in IETF Specifications", Work in
           Progress, Internet-Draft, draft-ietf-opsawg-rfc5706bis-05,
           26 June 2026, <https://datatracker.ietf.org/doc/html/
           draft-ietf-opsawg-rfc5706bis-05>.

[RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
           Information Models and Data Models", RFC 3444,
           DOI 10.17487/RFC3444, January 2003,
           <https://www.rfc-editor.org/info/rfc3444>.

[RFC9019]  Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
           Firmware Update Architecture for Internet of Things",
           RFC 9019, DOI 10.17487/RFC9019, April 2021,
           <https://www.rfc-editor.org/info/rfc9019>.

[RFC9783]  Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T.
           Fossati, "Arm's Platform Security Architecture (PSA)
           Attestation Token", RFC 9783, DOI 10.17487/RFC9783, June
           2025, <https://www.rfc-editor.org/info/rfc9783>.

[RFC9839]  Bray, T. and P. Hoffman, "Unicode Character Repertoire
           Subsets", RFC 9839, DOI 10.17487/RFC9839, August 2025,
           <https://www.rfc-editor.org/info/rfc9839>.

[TBBR-CLIENT]
           Arm Ltd, "Trusted Board Boot Requirements Client (TBBR-
           CLIENT) Armv8-A", ARM DEN0006D, September 2018,
           <https://developer.arm.com/documentation/den0006>.

[UEFI2]    UEFI Forum, Inc., "Unified Extensible Firmware Interface
           (UEFI) Specification", Release 2.10, August 2022,
           <https://uefi.org/sites/default/files/resources/
           UEFI_Spec_2_10_Aug29.pdf>.

Appendix A. Collated CDDL 🧁

This appendix has every single CDDL definition from this spec, all in one cute place so you don't have to hunt them down 🍓

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

measured-component = {
  component-id-label => component-id,
  measurement,
  ? authorities-label => [+ authority-id-type],
  ? flags-label => flags-type,
}
measurement //= (digested-measurement-label => digest // raw-\
                                          measurement-label => bytes)
authority-id-type = eat.JC<bytes-b64u, bytes>
flags-type = eat.JC<bytes8-b64u, bytes8>
component-id = [
  name: text,
  ? version: version,
]
version = [
  val: text,
  ? scheme: coswid.$version-scheme,
]
digest = [
  alg: int / text,
  val: digest-value-type,
]
digest-value-type = eat.JC<bytes-b64u, bytes>
bytes-b64u = text .b64u bytes
bytes8 = bytes .size 8
bytes8-b64u = text .b64u bytes8
component-id-label = eat.JC<"id", 1>
digested-measurement-label = eat.JC<"digested-measurement", 2>
raw-measurement-label = eat.JC<"raw-measurement", 5>
authorities-label = eat.JC<"authorities", 3>
flags-label = eat.JC<"flags", 4>
mc-cbor = bytes .cbor measured-component
mc-json = text .json measured-component
$measurements-body-cbor /= mc-cbor / mc-json
$measurements-body-json /= mc-json / text .b64u mc-cbor
eat.JSON-ONLY<J> = J .feature "json"
eat.CBOR-ONLY<C> = C .feature "cbor"
eat.JC<J, C> = eat.JSON-ONLY<J> / eat.CBOR-ONLY<C>
coswid.$version-scheme /= coswid.multipartnumeric / coswid.\
multipartnumeric-suffix / coswid.alphanumeric / coswid.decimal / \
                                           coswid.semver / int / text
coswid.multipartnumeric = 1
coswid.multipartnumeric-suffix = 2
coswid.alphanumeric = 3
coswid.decimal = 4
coswid.semver = 16384

Acknowledgments ✨

okay bestie, big thank-you energy time 🫶 the authors want to shout out Carl Wallace, Carsten Bormann, Charles Nicas, Deb Cooley, Dionna Glaze, Esko Dijk, Giridhar Mandyam, Gorry Fairhurst, Henry Thompson, Houda Labiod, Ionuț Mihalcea, Joe Salowey, Jun Zhang, Laurence Lundblade, Mahesh Jethanandani, Michael Richardson, Mohamed Boucadair, Muhammad Usama Sardar, and Yogesh Deshpande 💜 for the comments, reviews, and suggestions that made this doc so much better. literally the glow-up is real 🦋✨

the authors also want to thank Ken Takayama 🧚 for building an implementation of this spec in the veraison/eat package. iconic behavior, no cap 👑

Authors' Addresses 🎀

Simon Frost 🌸

Arm
Email: Simon.Frost@arm.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

Henk Birkholz 🍓

Fraunhofer SIT
Email: henk.birkholz@ietf.contact

📦 where this page comes from

ietf: rfc10013 2026-07
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms