Entity Attestation Token (EAT) Measured Component Arm
Simon.Frost@arm.com
Linaro
Thomas.Fossati@linaro.org
University of the Bundeswehr Munich
Werner-Heisenberg-Weg 39 Institute of Distributed Intelligent Systems Neubiberg 85577 Germany Hannes.Tschofenig@gmx.net
Fraunhofer SIT
henk.birkholz@ietf.contact
SEC rats EAT measurements claim measured component 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 .
Copyright Notice 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 () 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
  • .  Introduction
  • .  Conventions and Definitions
  • .  Information Model
  • .  Data Models
    • .  Common Types
    • .  The digest Type
    • .  The measured-component Data Item
      • .  Component Identifier
      • .  Authority Identifier
      • .  Profile-Specific Flags
    • .  EAT measurements-format Extensions
      • .  measurements-format for CBOR EAT
      • .  measurements-format for JSON EAT
    • .  EAT Profiles and Measured Components
    • .  Examples
  • .  Security Considerations
  • .  Privacy Considerations
  • .  IANA Considerations
    • .  Media Type Registrations
      • .  application/measured-component+cbor
      • .  application/measured-component+json
    • .  Measured Component Content-Format Registrations
  • .  References
    • .  Normative References
    • .  Informative References
  • .  Collated CDDL
  • Acknowledgments
  • Authors' Addresses
Introduction 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 (). Currently, the only specified format is Concise Software Identification (CoSWID) Tags of type "evidence", as per . 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 . 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 .
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 when, and only when, they appear in all capitals, as shown here. In this document, Concise Data Definition Language (CDDL) is used to describe the data formats. This specification uses the following CDDL control operators: .b64u defined in , .json defined in , and .cbor defined in . Examples are folded following the conventions in .
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 . Measured Component Information Elements
IE Description Requirement Level
Component Name The name given to the measured 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. REQUIRED
Component Version A value representing the specific release or development version of the measured component. Using Semantic Versioning is RECOMMENDED. OPTIONAL
Digested or Raw Value Either the raw value or the digested value of the measured component. REQUIRED
Digest Algorithm Hash algorithm used to compute the Digest Value. REQUIRED only if the value is in the digested form
Authorities One or more entities that can authoritatively identify the component being measured. OPTIONAL
A data model implementing this information model SHOULD allow a limited amount of extensibility to accommodate profile-specific semantics.
Data Models This section presents coordinated JSON and CBOR data models, each of which implements the information model outlined in . The data model is inspired by the "PSA software component" claim (), which has been refactored to take into account the recommendations about the design of new EAT claims described in . 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 , is used.
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
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 . 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>
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 .
measurements:
Either a digest value and digest algorithm (index 2), encoded using the digest format (), 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 .
flags (index 4):
A 64-bit field with profile-defined semantics, see .
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 , extending it to non-software components.
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 () 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 and Arm Trusted Board Boot . 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 () 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>
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 () 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.
EAT measurements-format Extensions The CDDL in extends the $measurements-body-cbor and $measurements-body-json EAT sockets to add support for measured-components to the Measurement claim.
EAT measurements-format Extensions 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
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.
measurements-format for CBOR EAT The entries in 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 and how the associated CoAP Content-Format is used to describe the original serialization. measurements-format for EAT CBOR Web Token (CWT)
content-type (CoAP C-F equivalent) content-format
application/measured-component+cbor mc-cbor
application/measured-component+json mc-json
measurements-format for JSON EAT is the equivalent of for JSON-serialized EAT. measurements-format for EAT JSON Web Token (JWT)
content-type (CoAP C-F equivalent) content-format
application/measured-component+json mc-json
application/measured-component+cbor tstr .b64u mc-cbor
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.
Examples The example in is a digested measured component with all the fields populated.
Complete Measured Component { / 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' }
The example depicted in 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.
EAT Measurements Claim Using a Measured Component (CBOR) { 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' ] } >> ] ] }
The example in 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.
EAT Measurements Claim Using a Measured Component (JSON) =============== 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\" ] }" ] ] }
The example shown in is a measured component representing a boot loader identified by its path name:
Digested Measured Component Using a File Path as an Identifier { / id / 1: [ / name / "/boot/loader.bin" ], / measurement / 2: [ / alg / "sha-384", / val / h'66ec2fb4e02d8c8b3eee320e750d9389d66c52c51db11cc6 9cc5e410816283ed60ba573795f5fcc85e513af57b3f6def' ], / flags / 4: h'0000000000000101' }
The example in is a raw measured component.
Raw Measured Component { / id / 1: [ / name / "hardware-config" ], / measurement / 5: h'4f6d616861' }
Security Considerations The considerations discussed in Sections Claim Trustworthiness, Multiple EAT Consumers, and Detached EAT Bundle Digest Security Considerations of 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 . If the component measurement is digested, the digest must be computed using a strong cryptographic hash function.
Privacy Considerations The differential encryption considerations discussed in Section Multiple EAT Consumers of 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.
IANA Considerations
Media Type Registrations IANA has added the following media types to the "Media Types" registry . Measured Component Media Types
Name Template Reference
measured-component+cbor application/measured-component+cbor RFC 10013
measured-component+json application/measured-component+json RFC 10013
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:
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
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:
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
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 as follows: Content-Format Number Registrations
Content Type Content Coding ID Reference
application/measured-component+cbor - 295 RFC 10013
application/measured-component+json - 296 RFC 10013
References Normative References Named Information Hash Algorithm Registry IANA Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Constrained Application Protocol (CoAP) The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Handling Long Lines in Content of Internet-Drafts and RFCs This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. Additional Control Operators for the Concise Data Definition Language (CDDL) The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed:.plus,.cat, and.det for the construction of constants;.abnf/.abnfb for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and.feature for indicating the use of a non-basic feature in an instance. Concise Software Identification Tags ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. The Entity Attestation Token (EAT) An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point in both an application-specific and a more general way. The present document defines a number of additional generally applicable control operators for text conversion (bytes, integers, printf-style formatting, and JSON) and for an operation on text. Semantic Versioning 2.0.0 Informative References Constrained RESTful Environments (CoRE) Parameters IANA Media Types IANA Guidelines for Considering Operations and Management in IETF Specifications Everything OPS Cisco Old Dog Consulting Nokia Blue Fern Consulting ZTE New Protocols and Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage them. Retrofitting operations and management considerations is suboptimal. The purpose of this document is to provide guidance to authors and reviewers on what operational and management aspects should be addressed when writing documents in the IETF Stream that document a specification for New Protocols or Protocol Extensions or describe their use. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also updates RFC 2360 to obsolete mandatory MIB creation. Finally, it introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream that define New Protocols or Protocol Extensions or describe their use (including relevant YANG Models), while providing an escape clause if no new considerations are identified. Work in Progress On the Difference between Information Models and Data Models There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community. A Firmware Update Architecture for Internet of Things Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality. In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates. Arm's Platform Security Architecture (PSA) Attestation Token Arm's Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, along with open-source reference implementations, aimed at helping device makers and chip manufacturers integrate best-practice security into their products. Devices that comply with PSA can generate attestation tokens as described in this document, which serve as the foundation for various protocols, including secure provisioning and network access control. This document specifies the structure and semantics of the PSA attestation token. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes the claims used in an attestation token generated by PSA-compliant systems, how these claims are serialized for transmission, and how they are cryptographically protected. This Informational document is published as an Independent Submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. Unicode Character Repertoire Subsets This document discusses subsets of the Unicode character repertoire for use in protocols and data formats and specifies three subsets recommended for use in IETF specifications. Trusted Board Boot Requirements Client (TBBR-CLIENT) Armv8-A Arm Ltd Unified Extensible Firmware Interface (UEFI) Specification UEFI Forum, Inc. Release 2.10
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 , , , , , , , , , , , , , , , , , , and for providing comments, reviews, and suggestions that greatly improved this document. The authors would also like to thank for providing an implementation of this specification in the veraison/eat package.
Authors' Addresses Arm
Simon.Frost@arm.com
Linaro
Thomas.Fossati@linaro.org
University of the Bundeswehr Munich
Werner-Heisenberg-Weg 39 Institute of Distributed Intelligent Systems Neubiberg 85577 Germany Hannes.Tschofenig@gmx.net
Fraunhofer SIT
henk.birkholz@ietf.contact