[要約] RFC 10013は、アテスターの対象環境内で状態を採取し、暗号学的ハッシュ関数で要約できるオブジェクトである測定対象コンポーネントの情報モデルと、2つのデータモデルを定義します。測定対象コンポーネントには、フラッシュメモリ上のファームウェア、起動時にメモリへ読み込まれるソフトウェア、ファイルシステム上のデータ、CPUレジスタの値などが含まれます。JSONとCBORの直列化形式、メディアタイプ、CoAPのContent-Formatを規定してEntity Attestation Token (EAT)の枠組みで直ちに利用できるようにし、情報モデルはASN.1など将来の別の直列化形式にも再利用できます。
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
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.
「測定されたコンポーネント」という用語は、認証者のターゲット環境内のオブジェクトを指し、その状態はサンプリングされ、通常は暗号化ハッシュ関数を使用してダイジェストされます。測定されるコンポーネントの例には、フラッシュ メモリに格納されているファームウェア、開始時にメモリにロードされるソフトウェア、ファイル システムに格納されているデータ、または CPU レジスタの値が含まれます。この文書は、測定されたコンポーネントの情報モデルと 2 つの関連データ モデルを提供します。この分離は意図的なものです。JSON および Concise Binary Object Representation (CBOR) シリアル化と、メディア タイプおよび関連する Constrained Application Protocol (CoAP) コンテンツ形式との組み合わせにより、Entity Attestation Token (EAT) フレームワーク内でセマンティクスを即座に使用できるようになります。一方、情報モデルは、たとえば ASN.1 を使用して追加のシリアル化を提供するために将来の仕様で再利用できます。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
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.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10013 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
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
Section 4.2.16 of [RFC9711] defines a Measurement claim that:
[RFC9711] のセクション 4.2.16 では、測定クレームを次のように定義しています。
[c]ontains descriptions, lists, evidence, or measurements of the software that exists on the entity or on any other measurable subsystem of the entity
[c]エンティティまたはエンティティのその他の測定可能なサブシステムに存在するソフトウェアの説明、リスト、証拠、または測定値が含まれます
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.
この主張は、異なる CoAP コンテンツ形式 ([RFC7252] のセクション 12.3) によってそれぞれ識別される、異なる測定形式を許可します。現在、指定されている形式は、[RFC9393] のセクション 2.9.4 に従って、「証拠」タイプの Concise Software Identification (CoSWID) タグのみです。ただし、CoSWID は、初期ブート環境など、ファイル システムに固定できない測定には適していません。このギャップに対処するために、このドキュメントでは、CoSWID と並行して、または CoSWID の代わりに EAT Measurement クレームで使用できる測定コンポーネント形式を導入します。
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.
「測定されたコンポーネント」という用語は、認証者のターゲット環境内のオブジェクトを指し、その状態はサンプリングされ、通常は暗号化ハッシュ関数を使用してダイジェストされます。たとえば、これには、起動時にメモリにロードされるファームウェア コンポーネントの不変部分、ランタイム整合性チェック (RTIC)、ファイル システム オブジェクト、または CPU レジスタが含まれます。
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 つの関連データ モデル [RFC3444] を提供します。この分離は意図的です。JSON および CBOR シリアル化とメディア タイプおよび関連する CoAP コンテンツ形式を組み合わせることで、EAT フレームワーク内でセマンティクスを即座に使用できるようになります。一方、情報モデルは、たとえば ASN.1 を使用して追加のシリアル化を提供するために将来の仕様で再利用できます。このアプローチは、[OPS-MGMT] のセクション 5.2 のガイダンスと一致しています。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
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].
この文書では、データ形式の記述に Concise Data Definition Language (CDDL) [RFC8610] [RFC9165] [RFC9741] を使用します。この仕様は、次の CDDL 制御演算子を使用します: [RFC9741] のセクション 2.1 で定義された .b64u、[RFC9741] のセクション 2.4 で定義された .json、および [RFC8610] のセクション 3.8.4 で定義された .cbor。
Examples are folded following the conventions in [RFC8792].
例は [RFC8792] の規則に従って折りたたまれています。
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.
測定されたコンポーネントの情報要素 (IE) には、コンポーネントのサンプリングされた状態 (ダイジェストまたは生の形式) と、コンポーネントの識別に役立つメタデータが含まれます。オプションで、インストールされたコンポーネントの署名を担当するエンティティも指定できます。
The IEs that constitute a measured component are described in Table 1.
測定コンポーネントを構成する IE を表 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
表 1: 測定されたコンポーネントの情報要素
A data model implementing this information model SHOULD allow a limited amount of extensibility to accommodate profile-specific semantics.
この情報モデルを実装するデータ モデルは、プロファイル固有のセマンティクスに対応するために、限られた量の拡張性を許可する必要があります (SHOULD)。
This section presents coordinated JSON and CBOR data models, each of which implements the information model outlined in Section 3.
このセクションでは、調整された JSON および CBOR データ モデルを示します。各データ モデルは、セクション 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].
このデータモデルは、「PSA ソフトウェアコンポーネント」クレーム ([RFC9783] のセクション 4.4.1) からインスピレーションを得ており、[RFC9711] の付録 E に記載されている新しい EAT クレームの設計に関する推奨事項を考慮するためにリファクタリングされています。
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.
CDDL は、JSON と CBOR の両方のデータ モデルのルールと制約を表現するために使用されます。測定コンポーネント データ項目を作成または検証する場合は、これらのルールに厳密に従う必要があります。CBOR と JSON の間に差異がある場合、[RFC9711] の付録 D で定義されている CDDL 汎用 JC<> が使用されます。
The following three basic types are used at various places within the measured component data model:
次の 3 つの基本タイプは、測定コンポーネント データ モデル内のさまざまな場所で使用されます。
bytes-b64u = text .b64u bytes
bytes8 = bytes .size 8
bytes8-b64u = text .b64u bytes8
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.
ダイジェストは、使用されたハッシュ アルゴリズムとともにハッシュ操作の結果を表します。ダイジェスト アルゴリズム識別子のタイプは int または text のいずれかで、「Named Information Hash Algorithm Registry」IANA レジストリ [IANA.named-information] に従って解釈されます。具体的には、int 値は「ID」エントリと照合され、テキスト値は「ハッシュ名文字列」エントリと照合されます。可能な限り、int エンコーディングを使用することが推奨されます。
digest = [
alg: (int / text)
val: digest-value-type
]
digest-value-type = eat.JC<bytes-b64u, bytes>
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:
測定されたコンポーネントの CBOR マップ/JSON オブジェクトのメンバーは次のとおりです。
id (index 1):
ID (インデックス 1):
The measured component identifier encoded according to the format described in Section 4.3.1.
セクション 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.
ダイジェスト形式 (セクション 4.2) を使用してエンコードされたダイジェスト値およびダイジェスト アルゴリズム (インデックス 2)、またはバイト文字列としてエンコードされた「生の」測定値 (インデックス 5) のいずれか。ダイジェストされたフォームのサイズはダイジェスト関数によって制限されますが、生のフォームのサイズは測定対象に応じて大きく異なる可能性があることに注意してください (たとえば、CPU レジスタまたは構成 BLOB 全体など)。したがって、デコーダの実装は、この特定のフィールドに割り当てるメモリの量を制限することを決定する場合があります。
authorities (index 3):
当局 (インデックス 3):
One or more authorities, see Section 4.3.2.
1 つ以上の当局。セクション 4.3.2 を参照。
flags (index 4):
フラグ (インデックス 4):
A 64-bit field with profile-defined semantics, see Section 4.3.3.
プロファイル定義のセマンティクスを持つ 64 ビット フィールド。セクション 4.3.3 を参照。
The component-id data item is as follows:
コンポーネント ID データ項目は次のとおりです。
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.
[RFC9711] の sw-version-type のエンコーディングとセマンティクスを再利用し、非ソフトウェア コンポーネントに拡張する複合バージョン データ項目。
Note that the complete definition of sw-version-type depends on the $version-scheme CDDL socket defined in Section 2.2 of [RFC9393].
sw-version-type の完全な定義は、[RFC9393] のセクション 2.2 で定義されている $version-scheme CDDL ソケットに依存することに注意してください。
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.
オーソリティとは、デジタル署名することで特定のコンポーネントを権威的に識別できるエンティティです。この署名は通常、インストール中 ([RFC9019] のセクション 7)、または Unified Extensible Firmware Interface (UEFI) セキュア ブート [UEFI2] や Arm Trusted Board Boot [TBBR-CLIENT] の場合のように、ブート ファームウェア、オペレーティング システム、またはアプリケーション ランチャーによって測定されたコンポーネントが実行されるときに検証されます。別の例としては、アプリ ストアの制御エンティティが挙げられます。この署名は、EAT 形式の証拠に対する認証者の署名とはまったく関係がないことに注意してください。さらに言えば、典拠識別子は、それ自体では、同封されている EAT 形式の証拠の署名者を示すものではありません。
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.
認証局は、その署名公開鍵によって識別されます。これは、X.509 証明書、生の公開キー、公開キーの拇印、または署名エンティティに一意に関連付けることができるその他の識別子である可能性があります。場合によっては、複数の当事者が承認または承認を示すためにコンポーネントに署名する必要がある場合があります。これには、ファームウェア更新システム、フリート所有者、サードパーティ監査人などの役割が含まれる場合があります。各署名の具体的な目的は展開によって異なる場合があり、配列内の権限の順序が意味を示す場合があります。
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.
EAT プロファイル ([RFC9711] のセクション 6) が測定されたコンポーネントを使用する場合、権限フィールドが使用されるかどうかを指定しなければなりません (MUST)。これを使用する場合、プロファイルは、authority 配列の各エントリが何を表すか、および対応する authoritative-id-type を解釈する方法も指定しなければなりません (MUST)。
The authority-id-type is defined as follows:
権限 ID タイプは次のように定義されます。
authority-id-type = eat.JC<bytes-b64u, bytes>
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.
このオプションのフィールドには、最大 64 ビットのプロファイル定義セマンティクスを含めることができ、この仕様のプロファイルで追加情報をエンコードし、基本タイプを拡張できるようになります。これは、ビット マスクや、所定のコードポイント セット内の単一の値などの情報を固定サイズのチャンクで運ぶために使用できます。内部構造に関係なく、このフィールドのサイズはちょうど 8 バイトです。
The flags-type is defined as follows:
flags-type は次のように定義されます。
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.
EAT プロファイル ([RFC9711] のセクション 6) が測定されたコンポーネントを使用する場合、フラグフィールドが使用されるかどうかを指定しなければなりません (MUST)。使用する場合は、プロファイルで 64 ビットの解釈方法も指定しなければなりません。
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.
図 1 の CDDL は、$measurements-body-cbor および $measurements-body-json EAT ソケットを拡張して、Measurement クレームに測定されたコンポーネントのサポートを追加します。
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
図 1: EAT 測定形式の拡張子
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.
各ソケットは 2 つの新しいタイプで拡張されています。1 つは、測定コンポーネントと EAT が同じシリアル化を持つ場合 (たとえば、両方とも CBOR である場合) に使用される「同種」表現で、もう 1 つはシリアル化が異なる場合に使用される「トンネル」表現です。
The entries in Table 2 are the allowed content-type/content-format pairs when the measured-component is carried in a CBOR EAT.
表 2 のエントリは、測定されたコンポーネントが 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.
図 1 の「同種」形式と「トンネル」形式の使用と、関連する CoAP コンテンツ形式が元のシリアル化を記述するためにどのように使用されているかに注目してください。
+=====================================+================+
| 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)
表 2: EAT CBOR Web トークン (CWT) の測定形式
Table 3 is the equivalent of Table 2 for JSON-serialized EAT.
表 3 は、JSON シリアル化された EAT の表 2 に相当します。
+=====================================+====================+
| 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)
表 3: EAT JSON Web トークン (JWT) の測定形式
The semantics of the authorities and profile flags fields are defined by the applicable EAT profile, i.e., the profile of the wrapping EAT.
権限およびプロファイル フラグ フィールドのセマンティクスは、該当する EAT プロファイル、つまりラッピング 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.
EAT のプロファイルが消費者に知られておらず、その EAT 内の 1 つ以上の測定されたコンポーネントに権限やプロファイル フラグが含まれている場合、消費者は EAT を拒否しなければなりません (MUST)。
The example in Figure 2 is a digested measured component with all the fields populated.
図 2 の例は、すべてのフィールドに値が入力されたダイジェストされた測定コンポーネントです。
{
/ 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
図 2: 完全な測定コンポーネント
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.
図 3 に示す例は、上記と同じ測定コンポーネントですが、EAT クレーム セット内の測定クレームの形式として使用されます。
This example uses 295 as the content-type value of the measurements-format entry.
この例では、measurement-format エントリの content-type 値として 295 を使用します。
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.
配列には測定されたコンポーネントが 1 つだけ含まれていますが、測定されたトラステッド コンピューティング ベース (TCB) が複数の個別に測定されたコンポーネントで構成されている場合は、追加のエントリが追加される可能性があることに注意してください。
{
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)
図 3: 測定されたコンポーネント (CBOR) を使用した EAT 測定クレーム
The example in Figure 4 illustrates the inclusion of a JSON measured component inside a JSON EAT.
図 4 の例は、JSON EAT 内に JSON 測定コンポーネントを含めることを示しています。
This example uses 296 as the content-type value of the measurements-format entry.
この例では、measurement-format エントリの content-type 値として 296 を使用します。
=============== 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)
図 4: 測定されたコンポーネント (JSON) を使用した EAT 測定クレーム
The example shown in Figure 5 is a measured component representing a boot loader identified by its path name:
図 5 に示す例は、パス名で識別されるブート ローダーを表す測定されたコンポーネントです。
{
/ 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
図 5: ファイル パスを識別子として使用してダイジェストされた測定コンポーネント
The example in Figure 6 is a raw measured component.
図 6 の例は、生の測定コンポーネントです。
{
/ id / 1: [
/ name / "hardware-config"
],
/ measurement / 5: h'4f6d616861'
}
Figure 6: Raw Measured Component
図 6: 生の測定成分
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.
[RFC9711] のセクション 9.1 (信頼性の主張)、9.4 (複数の EAT コンシューマ)、および 9.5 (分離された EAT バンドル ダイジェストのセキュリティに関する考慮事項) で説明されている考慮事項は、この文書にも適用されます。測定されたコンポーネント情報モデルが、この文書で指定されているものとは異なるデータ モデルを使用してシリアル化される場合にも、同様のセキュリティ上の考慮事項が適用される可能性があることに注意してください。
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].
ファイルに保存されたり、データベースに挿入されたり、人間に表示されたりするテキストフィールド (コンポーネント名やコンポーネントバージョンなど) は、攻撃や望ましくない動作を防ぐために適切にサニタイズする必要があります。このトピックに関するさらなる議論と参考文献は、[RFC9839] のセクション 7 にあります。
If the component measurement is digested, the digest must be computed using a strong cryptographic hash function.
コンポーネントの測定値がダイジェストされている場合は、強力な暗号化ハッシュ関数を使用してダイジェストを計算する必要があります。
The differential encryption considerations discussed in Section 9.4 (Multiple EAT Consumers) of [RFC9711] also apply to this document.
[RFC9711] のセクション 9.4 (複数の EAT コンシューマ) で説明されている差分暗号化に関する考慮事項も、この文書に適用されます。
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 has added the following media types to the "Media Types" registry [IANA.media-types].
IANA は、次のメディア タイプを「メディア タイプ」レジストリ [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
表 4: 測定されたコンポーネント メディア タイプ
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
measured-component+cbor
測定成分+cbor
Required parameters:
必須パラメータ:
N/A
該当なし
Optional parameters:
オプションのパラメータ:
N/A
該当なし
Encoding considerations:
エンコーディングに関する考慮事項:
binary (CBOR)
バイナリ (CBOR)
Security considerations:
セキュリティに関する考慮事項:
Section 5 of RFC 10013
RFC 10013 のセクション 5
Interoperability considerations:
相互運用性に関する考慮事項:
N/A
該当なし
Published specification:
公開された仕様:
RFC 10013
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".)
フラグメント識別子の構文とセマンティクスは、「application/cbor」で指定されているとおりです。(現在、「application/cbor」に対してフラグメント識別構文は定義されていません。)
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
RATS WG mailing list (rats@ietf.org)
RATS WG メーリング リスト (rats@ietf.org)
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
none
なし
Author/Change controller:
作成者/変更コントローラー:
IETF
IETF
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
measured-component+json
測定されたコンポーネント+json
Required parameters:
必須パラメータ:
N/A
該当なし
Optional parameters:
オプションのパラメータ:
N/A
該当なし
Encoding considerations:
エンコーディングに関する考慮事項:
binary (JSON is UTF-8-encoded text)
バイナリ (JSON は UTF-8 でエンコードされたテキスト)
Security considerations:
セキュリティに関する考慮事項:
Section 5 of RFC 10013
RFC 10013 のセクション 5
Interoperability considerations:
相互運用性に関する考慮事項:
N/A
該当なし
Published specification:
公開された仕様:
RFC 10013
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".)
フラグメント識別子の構文とセマンティクスは、「application/json」で指定されているとおりです。(現在、「application/json」に対してフラグメント識別構文は定義されていません。)
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
RATS WG mailing list (rats@ietf.org)
RATS WG メーリング リスト (rats@ietf.org)
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
none
なし
Author/Change controller:
作成者/変更コントローラー:
IETF
IETF
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:
IANA は、次のように、これら 2 つの Content-Format 番号を「Constrained RESTful Environments (CoRE) Parameters」レジストリ グループ [IANA.core-parameters] 内の「CoAP Content-Formats」レジストリに登録しました。
+=========================+================+=====+===========+
| 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
表 5: コンテンツ形式番号の登録
[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>.
[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>.
This appendix contains all the CDDL definitions included in this specification.
この付録には、この仕様に含まれるすべての CDDL 定義が含まれています。
=============== 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
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.
著者らは、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 に感謝します。このドキュメントを大幅に改善するためのコメント、レビュー、提案を提供してくださった Uyama Sardar と Yogesh Deshpande 。
The authors would also like to thank Ken Takayama for providing an implementation of this specification in the veraison/eat package.
また、著者らは、veraison/eat パッケージでこの仕様の実装を提供してくれた Ken Takayama に感謝したいと思います。
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