Internet Engineering Task Force (IETF) S. Frost
Request for Comments: 10013 Arm
Category: Standards Track T. Fossati
ISSN: 2070-1721 Linaro
H. Tschofenig
UniBw M.
H. Birkholz
Fraunhofer SIT
July 2026
Entity Attestation Token (EAT) Measured Component
Abstract
-
The term "measured component" refers to an object within the attester's target environment whose state can be sampled and typically digested using a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document provides the information model for the measured component and two associated data models. This separation is intentional: The JSON and Concise Binary Object Representation (CBOR) serializations, coupled with the media types and associated Constrained Application Protocol (CoAP) Content- Formats, enable the immediate use of the semantics within the Entity Attestation Token (EAT) framework. Meanwhile, the information model can be reused in future specifications to provide additional serializations, for example, using ASN.1.
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.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10013.
Copyright Notice
-
Copyright © 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, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
-
1. Introduction 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
-
Section 4.2.16 of [RFC9711] 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 allows for different measurement formats, each identified by a different CoAP Content-Format (Section 12.3 of [RFC7252]). Currently, the only specified format is Concise Software Identification (CoSWID) Tags of type "evidence", as per Section 2.9.4 of [RFC9393]. However, CoSWID is not suitable for measurements that cannot be anchored to a file system, such as those in early boot environments. To address this gap, this document introduces a measured component format that can be used with the EAT Measurement claim alongside or instead of CoSWID.
The term "measured component" refers to an object within the attester's target environment whose state can be sampled and typically digested using a cryptographic hash function. For example, this includes the invariant part of a firmware component that is loaded in memory at startup time, a Run-Time Integrity Check (RTIC), a file system object, or a CPU register.
This document provides the information model for the measured component and two associated data models [RFC3444]. This separation is intentional: The JSON and CBOR serializations, coupled with the media types and associated CoAP Content-Formats, enable the immediate use of the semantics within the EAT framework. Meanwhile, the information model can be reused in future specifications to provide additional serializations, for example, using ASN.1. This approach is consistent with 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" 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, Concise Data Definition Language (CDDL) [RFC8610] [RFC9165] [RFC9741] is used to describe the data formats. This specification uses the following 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 presents the information model of a measured component.
A measured component Information Element (IE) includes the component's sampled state (in digested or raw form) along with metadata that helps in identifying the component. Optionally, any entities responsible for signing the installed component can also be specified.
The IEs that constitute a measured component are described in Table 1.
+=============+=====================================+=============+ | 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 implementing this information model SHOULD allow a limited amount of extensibility to accommodate profile-specific semantics.
4. Data Models
-
This section presents coordinated JSON and CBOR data models, each of which implements the information model outlined in Section 3.
The data model is inspired by the "PSA software component" claim (Section 4.4.1 of [RFC9783]), which has been refactored to take into account the recommendations about the design of new EAT claims described in Appendix E of [RFC9711].
CDDL is used to express rules and constraints of the data model for both JSON and CBOR. These rules must be strictly followed when creating or validating measured component data items. When there is variation between CBOR and JSON, the CDDL generic JC<>, defined in Appendix D of [RFC9711], is used.
4.1. Common Types
-
The following three basic types are used at various places within 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 represents the result of a hashing operation together with the hash algorithm used. The type of the digest algorithm identifier can be either int or text and is interpreted according to the "Named Information Hash Algorithm Registry" IANA registry [IANA.named-information]. Specifically, int values are matched against "ID" entries and text values are matched against "Hash Name String" entries. Whenever 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
-
The measured-component data item is as follows:
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>The members of the measured-component CBOR map / JSON object are:
id (index 1):
-
The measured component identifier encoded according to the format described 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. Note that, while the size of the digested form is constrained by the digest function, the size of the raw form can vary greatly depending on what is being measured (it could be a CPU register or an entire configuration blob, for example). Therefore, a decoder implementation may decide to limit the amount of 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 is as follows:
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 provides a human-readable identifier for the component in question. Format and adopted 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.
| Note that 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 typically verified during installation (Section 7 of [RFC9019]) or when the measured component is executed by the boot firmware, operating system, or application launcher, as in the case of Unified Extensible Firmware Interface (UEFI) Secure Boot [UEFI2] and Arm Trusted Board Boot [TBBR-CLIENT]. Another example may be the controlling entity in an app store. Note that this signature is in no way related to the attester's signature on the EAT-formatted evidence. By extension, an authority identifier does not, by itself, indicate the signer of the enclosing EAT-formatted evidence.
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 associated with the signing entity. In some cases, multiple parties may need to sign a component to indicate their endorsement or approval. This could include roles such as a firmware update system, fleet owner, or third-party auditor. The specific purpose of each signature may depend on the deployment, and the order of authorities within the array could indicate meaning.
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 of the entries in the authorities array represents and how to interpret the corresponding authority-id-type.
The authority-id-type is defined as follows:
authority-id-type = eat.JC<bytes-b64u, bytes>
4.3.3. Profile-Specific Flags
-
This optional field can contain up to 64 bits of profile-defined semantics, enabling a profile of this specification to encode additional information and extend the base type. It can be used to carry information in fixed-size chunks, such as a bit mask or a single value within a predetermined set of codepoints. Regardless of its internal structure, the size of this field is exactly 8 bytes.
The flags-type is defined as follows:
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 to add support for measured- components to 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 is extended with two new types: a "homogeneous" representation that is used when measured-component and the EAT have the same serialization (e.g., they are both CBOR) and a "tunnel" representation that is used when the serializations differ.
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 the use of the "homogeneous" and "tunnel" formats from Figure 1 and how the associated CoAP Content-Format is used to describe 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 equivalent 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 is not known to the consumer and one or more measured components within that EAT include authorities and/or profile flags, the consumer MUST reject the EAT.
4.6. Examples
-
The example in Figure 2 is a digested measured component with all the fields populated.
{ / 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 depicted 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.
Note that the array contains only one measured component, but additional 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 illustrates the inclusion of 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
-
The considerations discussed in Sections 9.1 (Claim Trustworthiness), 9.4 (Multiple EAT Consumers), and 9.5 (Detached EAT Bundle Digest Security Considerations) of [RFC9711] apply to this document as well. Note that similar security considerations may apply when the measured component information model is serialized using different data models than the ones specified in this document.
The Component Name and Component Version can give an attacker detailed information about the software running on a device and its configuration settings. This information could offer an attacker valuable insight.
Any textual fields (e.g., Component Name and Component Version) that are stored in a file, inserted into a database, or displayed to humans must be properly sanitized to prevent attacks and undesirable behavior. Further discussion and references on this topic can be found in Section 7 of [RFC9839].
If the component measurement is digested, the digest must be computed using a strong cryptographic hash function.
6. Privacy Considerations
-
The differential encryption considerations discussed in Section 9.4 (Multiple EAT Consumers) of [RFC9711] also apply to this document.
The Component Name and Component Version may reveal private information about a device and its owner.
Additionally, the stability requirement of the Component Name may enable tracking.
7. IANA Considerations
7.1. Media Type Registrations
-
IANA has added the following media types to the "Media Types" registry [IANA.media-types].
+=========================+=========================+===========+ | 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:
+=========================+================+=====+===========+ | 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 contains all the CDDL definitions included in this specification.
=============== 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
-
The authors would like to thank 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 providing comments, reviews, and suggestions that greatly improved this document.
The authors would also like to thank Ken Takayama for providing an implementation of this specification in the veraison/eat package.
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.netHenk Birkholz Fraunhofer SIT Email: henk.birkholz@ietf.contact