Internet Engineering Task Force (IETF) L. Lundblade
Request for Comments: 9711 Security Theory LLC
Category: Standards Track G. Mandyam
ISSN: 2070-1721
J. O'Donoghue
Qualcomm Technologies Inc.
C. Wallace
Red Hound Software, Inc.
April 2025
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.
エンティティの証明トークン（EAT）は、エンティティの状態と特性、スマートフォン、モノのインターネット（IoT）デバイス、ネットワーク機器などのデバイスを説明する証明されたクレームセットを提供します。このクレームセットは、依存している当事者、サーバー、またはサービスによって使用され、エンティティに配置された信頼の種類と程度を決定します。
An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims.
EATは、CBOR Webトークン（CWT）またはAtestation指向の主張を伴うJSON Webトークン（JWT）のいずれかです。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc9711.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9711で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Entity Overview
1.2. EAT as a Framework
1.3. Operating Model and RATS Architecture
1.3.1. Relationship between Evidence and Attestation Results
2. Terminology
3. Top-Level Token Definition
4. The Claims
4.1. eat_nonce (EAT Nonce) Claim
4.2. Claims Describing the Entity
4.2.1. ueid (Universal Entity ID) Claim
4.2.1.1. Rules for Creating UEIDs
4.2.1.2. Rules for Consuming UEIDs
4.2.2. sueids (Semipermanent UEIDs) Claim
4.2.3. oemid (Hardware OEM ID) Claim
4.2.3.1. Random Number-Based OEM ID
4.2.3.2. IEEE-Based OEM ID
4.2.3.3. IANA Private Enterprise Number-Based OEM ID
4.2.4. hwmodel (Hardware Model) Claim
4.2.5. hwversion (Hardware Version) Claim
4.2.6. swname (Software Name) Claim
4.2.7. swversion (Software Version) Claim
4.2.8. oemboot (OEM Authorized Boot) Claim
4.2.9. dbgstat (Debug Status) Claim
4.2.9.1. Enabled
4.2.9.2. Disabled
4.2.9.3. Disabled Since Boot
4.2.9.4. Disabled Permanently
4.2.9.5. Disabled Fully and Permanently
4.2.10. location (Location) Claim
4.2.11. uptime (Uptime) Claim
4.2.12. bootcount (Boot Count) Claim
4.2.13. bootseed (Boot Seed) Claim
4.2.14. dloas (Digital Letters of Approval) Claim
4.2.15. manifests (Software Manifests) Claim
4.2.16. measurements (Measurements) Claim
4.2.17. measres (Software Measurement Results) Claim
4.2.18. submods (Submodules) Claim
4.2.18.1. Submodule Claims-Set
4.2.18.2. Detached Submodule Digest
4.2.18.3. Nested Tokens
4.3. Claims Describing the Token
4.3.1. iat (Timestamp) Claim
4.3.2. eat_profile (EAT Profile) Claim
4.3.3. intuse (Intended Use) Claim
5. Detached EAT Bundles
6. Profiles
6.1. Format of a Profile Document
6.2. Full and Partial Profiles
6.3. List of Profile Issues
6.3.1. Use of JSON, CBOR, or Both
6.3.2. CBOR Map and Array Encoding
6.3.3. CBOR String Encoding
6.3.4. CBOR Preferred Serialization
6.3.5. CBOR Tags
6.3.6. COSE/JOSE Protection
6.3.7. COSE/JOSE Algorithms
6.3.8. Detached EAT Bundle Support
6.3.9. Key Identification
6.3.10. Endorsement Identification
6.3.11. Freshness
6.3.12. Claims Requirements
6.4. The Constrained Device Standard Profile
7. Encoding and Collected CDDL
7.1. Claims-Set and CDDL for CWT and JWT
7.2. Encoding Data Types
7.2.1. Common Data Types
7.2.2. JSON Interoperability
7.2.3. Labels
7.2.4. CBOR Interoperability
7.3. Collected CDDL
7.3.1. Payload CDDL
7.3.2. CBOR-Specific CDDL
7.3.3. JSON-Specific CDDL
8. Privacy Considerations
8.1. UEID and SUEID Privacy Considerations
8.2. Location Privacy Considerations
8.3. Boot Seed Privacy Considerations
8.4. Replay Protection and Privacy
9. Security Considerations
9.1. Claim Trustworthiness
9.2. Key Provisioning
9.2.1. Transmission of Key Material
9.3. Freshness
9.4. Multiple EAT Consumers
9.5. Detached EAT Bundle Digest Security Considerations
9.6. Verification Keys
10. IANA Considerations
10.1. Reuse of CBOR and JSON Web Token (CWT and JWT) Claims
Registries
10.2. CWT and JWT Claims Registered by This Document
10.3. UEID URNs Registered by This Document
10.4. CBOR Tag for Detached EAT Bundle Registered by This
Document
10.5. Intended Use Registry
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Examples
A.1. Claims Set Examples
A.1.1. Simple TEE Attestation
A.1.2. Submodules for Board and Device
A.1.3. EAT Produced by an Attestation Hardware Block
A.1.4. Key / Key Store Attestation
A.1.5. Software Measurements of an IoT Device
A.1.6. Attestation Results in JSON
A.1.7. JSON-Encoded Token with Submodules
A.2. Signed Token Examples
A.2.1. Basic CWT Example
A.2.2. CBOR-Encoded Detached EAT Bundle
A.2.3. JSON-Encoded Detached EAT Bundle
Appendix B. UEID Design Rationale
B.1. Collision Probability
B.2. No Use of UUID
Appendix C. EAT Relation to IEEE.802.1AR Secure Device Identity
(DevID)
C.1. DevID Used with EAT
C.2. How EAT Provides an Equivalent Secure Device Identity
C.3. An X.509 Format EAT
C.4. Device Identifier Permanence
Appendix D. CDDL for CWT and JWT
Appendix E. New Claim Design Considerations
E.1. Interoperability and Relying Party Orientation
E.2. Operating System and Technology Neutral
E.3. Security Level Neutral
E.4. Reuse of Extant Data Formats
E.5. Proprietary Claims
Appendix F. Endorsements and Verification Keys
F.1. Identification Methods
F.1.1. COSE/JWS Key ID
F.1.2. JWS and COSE X.509 Header Parameters
F.1.3. CBOR Certificate COSE Header Parameters
F.1.4. Claim-Based Key Identification
Contributors
Authors' Addresses
An Entity Attestation Token (EAT) is a message made up of claims about an entity. An entity may be a device, some hardware, or some software. The claims are ultimately used by a relying party who decides if and how it will interact with the entity. The relying party may choose to trust, not trust, or partially trust the entity. For example, partial trust may be allowing a monetary transaction only up to a limit.
エンティティの証明トークン（EAT）は、エンティティに関する主張で構成されるメッセージです。エンティティは、デバイス、一部のハードウェア、または一部のソフトウェアである場合があります。請求は、最終的に、エンティティと対話するかどうか、どのように相互作用するかを決定する頼る当事者によって使用されます。頼る当事者は、実体を信頼したり、信頼したり、部分的に信頼することを選択することができます。たとえば、部分的な信頼は、制限までのみ金融取引を許可する可能性があります。
The security model and goal for attestation are unique and are not the same as those for other security standards such as server authentication, user authentication, and secured messaging. To give an example of one aspect of the difference, consider the association and life cycle of key material. For authentication, keys are associated with a user or service and are set up by actions performed by a user or an operator of a service. For attestation, the keys are associated with specific devices and are configured by device manufacturers. Since the reader is assumed to be familiar with the goals and security model for attestation as described in "Remote ATtestation procedureS (RATS) Architecture" [RFC9334], they are not repeated here.
証明のセキュリティモデルと目標は一意であり、サーバー認証、ユーザー認証、セキュアされたメッセージングなど、他のセキュリティ標準の目標と同じではありません。違いの1つの側面の例を示すには、重要な資料の関連性とライフサイクルを考慮してください。認証のために、キーはユーザーまたはサービスに関連付けられ、ユーザーまたはサービスのオペレーターによって実行されるアクションによって設定されます。証明のために、キーは特定のデバイスに関連付けられており、デバイスメーカーによって構成されています。読者は、「リモート証明手順（RAT）アーキテクチャ」[RFC9334]で説明されているように、証明の目標とセキュリティモデルに精通していると想定されているため、ここでは繰り返されません。
This document defines some common claims that are potentially of broad use. EAT additionally allows proprietary claims and for further claims to be standardized. Here are some examples:
このドキュメントは、潜在的に広範な使用されているいくつかの一般的な主張を定義しています。さらに食べることで、独自のクレームを許可し、さらなる請求を標準化することができます。ここにいくつかの例があります：
* Make and model of manufactured consumer device
* 製造された消費者デバイスの作成とモデル
* Make and model of a chip or processor, particularly for a security-oriented chip
* 特にセキュリティ指向チップ用のチップまたはプロセッサの作成とモデル
* Identification and measurement of the software running on a device
* デバイスで実行されているソフトウェアの識別と測定
* Configuration and state of a device
* デバイスの構成と状態
* Environmental characteristics of a device such as its Global Positioning System (GPS) location
* グローバルポジショニングシステム（GPS）の場所などのデバイスの環境特性
* Formal certifications received
* 受け取った正式な認定
EAT is constructed to support a wide range of use cases.
EATは、幅広いユースケースをサポートするために構築されています。
No single set of claims can accommodate all use cases, so EAT is constructed as a framework for defining specific attestation tokens for specific use cases. In particular, EAT provides a profile mechanism to be able to clearly specify the claims needed, the cryptographic algorithms that should be used, and other characteristics for a particular token and use case. Section 6 describes profile contents and provides a profile that is suitable for constrained device use cases.
すべてのユースケースに対応できる一連のクレームはないため、EATは、特定のユースケースの特定の証明トークンを定義するためのフレームワークとして構築されています。特に、EATは、必要なクレーム、使用すべき暗号化アルゴリズム、および特定のトークンおよびユースケースのその他の特性を明確に指定できるプロファイルメカニズムを提供します。セクション6では、プロファイルの内容について説明し、制約されたデバイスユースケースに適したプロファイルを提供します。
The entity's EAT implementation generates the claims and typically signs them with an attestation key. It is responsible for protecting the attestation key. Some EAT implementations will use components with very high resistance to attack such as Trusted Platform Modules or Secure Elements. Others may rely solely on simple software defenses.
エンティティのEAT実装はクレームを生成し、通常、証明キーで署名します。証明キーを保護する責任があります。一部の食事実装では、信頼できるプラットフォームモジュールや安全な要素など、攻撃に対して非常に高い抵抗性のあるコンポーネントを使用します。その他は、単純なソフトウェア防御のみに依存する場合があります。
Nesting of tokens and claims sets is accommodated for composite devices that have multiple subsystems.
トークンとクレームセットのネストは、複数のサブシステムを持つ複合デバイスに対応しています。
An EAT may be encoded in either JavaScript Object Notation (JSON) [RFC8259] or Concise Binary Object Representation (CBOR) [RFC8949] as needed for each use case. EAT is built on the CBOR Web Token (CWT) [RFC8392] and JSON Web Token (JWT) [RFC7519] and inherits all their characteristics and their security mechanisms. Like CWT and JWT, EAT does not imply any message flow.
EATは、各ユースケースの必要に応じて、JavaScriptオブジェクト表記（JSON）[RFC8259]または簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]にエンコードされる場合があります。EATは、CBOR Webトークン（CWT）[RFC8392]およびJSON Webトークン（JWT）[RFC7519]に基づいて構築され、すべての特性とセキュリティメカニズムを継承しています。CWTやJWTのように、EATはメッセージの流れを意味するものではありません。
The following is a very simple example. It is presented in JSON format for easy reading, but it could also be CBOR. Only the Claims-Set, the payload for the JWT, is shown.
以下は非常に簡単な例です。簡単に読むためにJSON形式で提示されていますが、CBORである可能性もあります。JWTのペイロードであるクレームセットのみが表示されます。
{
"eat_nonce": "MIDBNH28iioisjPy",
"ueid": "AgAEizrK3Q",
"oemid": 76543,
"swname": "Acme IoT OS",
"swversion": "3.1.4"
}
This example has a nonce for freshness. This nonce is the base64url encoding of a 12-byte random binary byte string. The ueid (Universal Entity ID) is effectively a serial number uniquely identifying the device. This ueid is the base64url encoding of a 48-bit Media Access Control (MAC) address preceded by the type byte 0x02. The oemid (Hardware OEM ID) identifies the manufacturer using a Private Enterprise Number (PEN) [PEN]. The software is identified by a simple string name and version. It could be identified by a full manifest, but this is a minimal example.
この例には、新鮮さのための非CEがあります。この非CEは、12バイトのランダムバイナリバイト文字列のbase64urlエンコードです。UEID（Universal Entity ID）は、事実上デバイスを一意に識別するシリアル番号です。このUEIDは、タイプバイト0x02が先行する48ビットメディアアクセスコントロール（MAC）アドレスのbase64urlエンコードです。OEMID（ハードウェアOEM ID）は、プライベートエンタープライズ番号（PEN）[PEN]を使用してメーカーを識別します。ソフトウェアは、単純な文字列名とバージョンで識別されます。完全なマニフェストで識別できますが、これは最小限の例です。
This document uses the term "entity" to refer to the target of an EAT. Most of the claims defined in this document are claims about an entity. An entity is equivalent to a target environment in an attester as defined in [RFC9334].
このドキュメントでは、「エンティティ」という用語を使用して、食事のターゲットを指します。このドキュメントで定義されている請求のほとんどは、エンティティに関するクレームです。[RFC9334]で定義されているように、エンティティはターゲット環境と同等です。
Layered attestation and composite devices, as described in [RFC9334], are supported by a submodule mechanism (see Section 4.2.18). Submodules allow nesting of EATs and of Claims-Sets so that such hierarchies can be modeled.
[RFC9334]に記載されているように、階層化された認証と複合デバイスは、サブモジュールメカニズムによってサポートされています（セクション4.2.18を参照）。サブモジュールは、そのような階層をモデル化できるように、食事やクレームセットのネスティングを可能にします。
An entity is the same as a "system component", as defined in the Internet Security Glossary [RFC4949].
インターネットセキュリティ用語集[RFC4949]で定義されているように、エンティティは「システムコンポーネント」と同じです。
Note that [RFC4949] defines "entity" and "system entity" as synonyms, and that they may be a person or organization in addition to being a system component. In the EAT context, "entity" never refers to a person or organization. The hardware and software that implement a website server or service may be an entity in the EAT sense, but the organization that operates, maintains, or hosts the website is not an entity.
[RFC4949]は、「エンティティ」と「システムエンティティ」を同義語として定義し、システムコンポーネントであることに加えて個人または組織である可能性があることに注意してください。EATの文脈では、「エンティティ」とは決して人や組織を指すことはありません。ウェブサイトサーバーまたはサービスを実装するハードウェアとソフトウェアは、Eatの意味でエンティティである可能性がありますが、Webサイトを運営、維持、またはホストする組織はエンティティではありません。
Some examples of entities:
エンティティのいくつかの例：
* A Secure Element
* 安全な要素
* A Trusted Execution Environment (TEE)
* 信頼できる実行環境（TEE）
* A network card in a router
* ルーターのネットワークカード
* A router, perhaps with each network card in the router being a submodule
* ルーター、おそらくルーターの各ネットワークカードがサブモジュールであるルーター
* An IoT device
* IoTデバイス
* An individual process
* 個別のプロセス
* An app on a smartphone
* スマートフォンのアプリ
* A smartphone with many submodules for its many subsystems
* 多くのサブシステム用の多くのサブモジュールを備えたスマートフォン
* A subsystem in a smartphone such as the modem or the camera
* モデムやカメラなどのスマートフォンのサブシステム
An entity may have strong security defenses against hardware-invasive attacks. It may also have low security, i.e., having no special security defenses. There is no minimum security requirement to be an entity.
エンティティは、ハードウェア侵入攻撃に対する強力なセキュリティ防御を持っている可能性があります。また、セキュリティが低い場合もあります。つまり、特別なセキュリティ防御はありません。エンティティになるための最小限のセキュリティ要件はありません。
EAT is a framework that is used for defining attestation tokens for specific use cases; it is not used for specific token definition. While EAT is based on and compatible with CWT and JWT, it can also be described as:
EATは、特定のユースケースの証明トークンを定義するために使用されるフレームワークです。特定のトークン定義には使用されません。EatはCWTおよびJWTに基づいており、互換性がありますが、次のように説明することもできます。
* An identification and type system for claims in Claims-Sets
* 請求セットの請求の識別とタイプシステム
* Definitions of common attestation-oriented claims
* 一般的な証明指向の主張の定義
* Claims defined in Concise Data Definition Language (CDDL) and serialized using CBOR or JSON
* 簡潔なデータ定義言語（CDDL）で定義され、CBORまたはJSONを使用してシリアル化されたクレーム
* Security envelopes based on CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE)
* CBORオブジェクトの署名と暗号化（COSE）およびJSONオブジェクトの署名と暗号化（Jose）に基づくセキュリティエンベロープ
* The nesting of claims sets and tokens to represent complex and compound devices
* 請求セットとトークンのネストは、複雑な化合物デバイスを表すためのトークン
* A profile mechanism for specifying and identifying specific tokens for specific use cases
* 特定のユースケースに特定のトークンを指定および識別するためのプロファイルメカニズム
EAT uses name/value pairs to identify individual claims the same way as CWT and JWT. Section 4 defines common attestation-oriented claims that have been added to the "CBOR Web Token (CWT) Claims" and "JSON Web Token Claims" IANA registries. As with CWT and JWT, no claims are mandatory and claims not recognized should be ignored.
EATは、名前/値のペアを使用して、CWTやJWTと同じ方法で個々のクレームを識別します。セクション4では、「CBOR Webトークン（CWT）クレーム」および「JSON Webトークンクレーム」IANAレジストリに追加された一般的な証明指向のクレームを定義します。CWTやJWTと同様に、請求は必須ではなく、認識されていない請求は無視されるべきです。
Unlike (but compatible with) CWT and JWT, EAT defines claims using CDDL [RFC8610]. In most cases, the same CDDL definition is used for both the CBOR/CWT serialization and the JSON/JWT serialization.
CWTやJWTとは異なり（ただし）、EATはCDDL [RFC8610]を使用して主張を定義します。ほとんどの場合、CBOR/CWTシリアル化とJSON/JWTシリアル化の両方に同じCDDL定義が使用されます。
Like CWT and JWT, EAT uses COSE and JOSE to provide authenticity, integrity, and optionally confidentiality. EAT places no new restrictions on cryptographic algorithms, retaining all the cryptographic flexibility of CWT, COSE, JWT, and JOSE.
CWTやJWTと同様に、EATはCOSEとJOSEを使用して、信頼性、誠実さ、およびオプションの機密性を提供します。CWT、COSE、JWT、およびJoseのすべての暗号化柔軟性を保持している暗号化アルゴリズムに新しい制限がありません。
EAT defines a means for nesting tokens and claims sets to accommodate composite devices that have multiple subsystems and multiple attesters. Tokens with security envelopes or bare claims sets may be embedded in an enclosing token. The nested token and the enclosing token do not have to use the same encoding (e.g., a CWT may be enclosed in a JWT).
EATは、複数のサブシステムと複数のアテスタントを備えた複合デバイスに対応するためのトークンとクレームセットをネストする手段を定義します。セキュリティ封筒または裸のクレームセットを備えたトークンは、囲まれたトークンに埋め込まれる場合があります。ネストされたトークンと囲まれたトークンは、同じエンコードを使用する必要はありません（たとえば、CWTがJWTに囲まれている場合があります）。
EAT adds the ability to detach claims sets and send them separately from a security-enveloped EAT that contains a digest of the detached claims set.
EATは、クレームセットを切り離し、独立したクレームセットのダイジェストを含むセキュリティエンベロープのEATとは別に送信する能力を追加します。
This document registers no media or content types for the identification of the EAT type, serialization encoding, or security envelope. The definition and registration of EAT media types are addressed in [EAT.media-types].
このドキュメントは、EATタイプ、シリアル化エンコーディング、またはセキュリティエンベロープの識別のためにメディアやコンテンツタイプを登録しません。EATメディアタイプの定義と登録は、[eat.media-types]で対処されています。
Finally, this document introduces the notion of an EAT profile that facilitates the creation of narrowed definitions of EATs for specific use cases in subsequent documents. One basic profile for constrained devices is normatively defined.
最後に、このドキュメントでは、後続のドキュメントで特定のユースケースのEATの狭められた定義の作成を促進するEATプロファイルの概念を紹介します。制約されたデバイスの1つの基本的なプロファイルは、規範的に定義されています。
EAT follows the operational model described in Figure 1 of RATS Architecture (Section 3 of [RFC9334]). To summarize, an attester generates evidence in the form of a claims set describing various characteristics of an entity. Evidence is usually signed by a key that proves the attester and the evidence it produces are authentic. The claims set either includes a received nonce or uses some other means to assure freshness.
EATは、RATSアーキテクチャの図1（[RFC9334]のセクション3）に記載されている運用モデルに従います。要約すると、Attesterは、エンティティのさまざまな特性を説明するクレームセットの形で証拠を生成します。証拠は通常、攻撃を証明する鍵によって署名され、それが生み出す証拠は本物であることを証明しています。セットされたクレームには、受信したノンセが含まれるか、新鮮さを保証するために他の手段を使用します。
A verifier confirms an EAT is valid by verifying the signature and may vet some claims using reference values. The verifier then produces attestation results, which may also be represented as an EAT. The attestation results are provided to the relying party, which is the ultimate consumer of the Remote Attestation Procedure. The relying party uses the attestation results as needed for its use case, perhaps allowing an entity to access a network, a financial transaction, or such. In some cases, the verifier and relying party are not distinct entities.
検証剤は、署名を確認することにより食事が有効であることを確認し、参照値を使用していくつかのクレームを審査することができます。その後、検証剤は証明の結果を生成します。これは食事として表される場合があります。証明の結果は、頼りになる当事者に提供されます。これは、リモート証明手順の究極の消費者です。頼る当事者は、そのユースケースに必要に応じて証明の結果を使用し、おそらくエンティティがネットワーク、金融取引などにアクセスできるようにするでしょう。場合によっては、検証者と依存者は異なるエンティティではありません。
Any claim defined in this document or in the IANA "CBOR Web Token (CWT) Claims" or "JSON Web Token Claims" registries may be used in evidence or attestation results. The relationship of claims in attestation results to evidence is fundamentally governed by the verifier and the verifier's policy.
このドキュメントまたはIANAの「Cbor Webトークン（CWT）クレーム」または「JSON Webトークンクレーム」レジストリで定義された請求は、証拠または証明の結果で使用される場合があります。証拠との証明結果における請求との関係は、検証者と検証者のポリシーによって根本的に支配されています。
A common use case is for the verifier and its policy to perform checks, calculations, and processing with evidence as the input to produce a summary result in attestation results that indicates the overall health and status of the entity. For example, measurements in evidence may be compared to reference values, the results of which are represented as a simple pass/fail in attestation results.
一般的なユースケースは、要約を作成するための入力として証拠を使用してチェック、計算、および処理を実行するための検証とそのポリシーが、エンティティの全体的な健康と状態を示す証明の結果をもたらします。たとえば、証拠の測定は参照値と比較される場合があり、その結果は証明結果の単純なパス/失敗として表されます。
It is also possible that some claims in the evidence will be forwarded unmodified to the relying party in attestation results. This forwarding is subject to the verifier's implementation and policy. The relying party should be aware of the verifier's policy to know what checks it has performed on claims it forwards.
証拠の一部の請求は、認証の結果で頼る当事者に変更されずに転送される可能性もあります。この転送は、Verifierの実装とポリシーの対象となります。頼る当事者は、それが前向きに実行したチェックを知るために、検証者のポリシーを認識する必要があります。
The verifier may modify claims it forwards, for example, to implement a privacy preservation functionality. It is also possible the verifier will put claims in the attestation results that give details about the entity that it has computed or looked up in a database. For example, the verifier may be able to put an "oemid" claim in the attestation results by performing a lookup based on a "ueid" claim (e.g., serial number) it received in evidence.
Verifierは、たとえばプライバシー保存機能を実装するために、それを転送するクレームを変更する場合があります。また、Verifierが、データベースで計算または検索したエンティティに関する詳細を提供する証明結果にクレームを掲載する可能性もあります。たとえば、検証剤は、証拠で受け取った「UEID」クレーム（シリアル番号など）に基づいて検索を実行することにより、証明の結果に「OEMID」クレームを配置できる場合があります。
This specification does not establish any normative rules for the verifier to follow, as these are a matter of local policy. It is up to each relying party to understand the processing rules of each verifier to know how to interpret claims in attestation results.
この仕様は、現地のポリシーの問題であるため、検証者が従うべき規範的規則を確立するものではありません。各検証者の処理ルールを理解して、認証結果の主張を解釈する方法を知るのは、各頼りの当事者次第です。
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, the structure of data is specified in CDDL [RFC8610] [RFC9165].
このドキュメントでは、データの構造はCDDL [RFC8610] [RFC9165]で指定されています。
The examples in Appendix A use CBOR diagnostic notation defined in Section 8 of [RFC8949] and Appendix G of [RFC8610].
付録Aの例は、[RFC8949]のセクション8および[RFC8610]の付録Gで定義されているCBOR診断表記法を使用します。
This document reuses terminology from JWT [RFC7519] and CWT [RFC8392]:
この文書は、JWT [RFC7519]およびCWT [RFC8392]からの用語を再利用します。
base64url encoding:
base64urlエンコード：
base64 encoding using the URL- and filename-safe character set defined in Section 5 of [RFC4648], with all trailing '=' characters omitted and without the inclusion of any line breaks, whitespace, or other additional characters [RFC7515].
[RFC4648]のセクション5で定義されているURLおよびファイルセーフ文字セットを使用したBase64エンコード。
Claim:
請求：
A piece of information asserted about a subject. A claim is represented as a value and either a name or a key to identify it.
主題について主張された情報。クレームは、値と名前または鍵を識別する鍵として表されます。
Claim Name:
クレーム名：
A unique text string that identifies the claim. It is used as the claim name for JSON encoding.
クレームを識別する一意のテキスト文字列。JSONエンコーディングの請求名として使用されます。
Claim Key:
主張キー：
The CBOR map key used to identify a claim. (The term "Claim Key" comes from CWT. This document, like COSE [RFC9052], uses the term "label" to refer to CBOR map keys to avoid confusion with cryptographic keys.)
CBORマップキーは、クレームを識別するために使用されました。（「クレームキー」という用語は、CWTからのものです。このドキュメントは、COSE [RFC9052]のように、「ラベル」という用語を使用してCborマップキーを参照して、暗号化キーとの混乱を避けます。）
Claim Value:
請求値：
The value portion of the claim. A claim value can be any CBOR data item or JSON value.
クレームの値部分。請求値は、任意のCBORデータ項目またはJSON値です。
Claims Set:
クレームセット：
The CBOR map or JSON object that contains the claims conveyed by the CWT or JWT.
CWTまたはJWTによって伝えられたクレームを含むCBORマップまたはJSONオブジェクト。
This document reuses terminology from RATS Architecture [RFC9334]; note that EAT does not capitalize RATS terms like "evidence" for easier readability:
この文書は、RATSアーキテクチャ[RFC9334]から用語を再利用します。EATは、読みやすさのための「証拠」のようなラットの用語を大文字化しないことに注意してください。
Attester:
アテスター：
A role performed by an entity (typically a device) whose evidence must be appraised in order to infer the extent to which the attester is considered trustworthy, such as when deciding whether it is authorized to perform some operation.
エンティティ（通常はデバイス）によって実行される役割は、操作を実行することを許可されているかどうかを決定するときなど、アテスターが信頼できると見なされる程度を推測するために証拠を評価する必要があります。
Verifier:
Verifier：
A role that appraises the validity of evidence about an attester and produces attestation results to be used by a relying party.
Attesterに関する証拠の妥当性を評価し、頼りになる当事者が使用する証明の結果を生み出す役割。
Relying Party:
頼るパーティー：
A role performed by an entity that depends on the validity of information about an attester for purposes of reliably applying application-specific actions. Compare: relying party [RFC4949].
アプリケーション固有のアクションを確実に適用する目的で、アテスターに関する情報の有効性に依存するエンティティによって実行される役割。比較：頼る当事者[RFC4949]。
Evidence:
証拠：
A set of claims generated by an attester to be appraised by a verifier. Evidence may include configuration data, measurements, telemetry, or inferences.
Verifierによって評価されるために、Attesterによって生成された一連のクレーム。証拠には、構成データ、測定、テレメトリ、または推論が含まれる場合があります。
Attestation Results:
証明の結果：
The output generated by a verifier, typically including information about an attester, where the verifier vouches for the validity of the results.
通常、検証者に関する情報を含む検証者によって生成される出力。結果の有効性を検証者が保証します。
Reference Values:
参照値：
A set of values against which values of claims can be compared as part of applying an appraisal policy for evidence. Reference values are sometimes referred to in other documents as "known-good values", "golden measurements", or "nominal values". These terms typically assume comparison for equality, whereas here, reference values might be more general and be used in any sort of comparison.
証拠のために評価ポリシーを適用することの一部として、クレームの値を比較できる価値のセット。参照値は、他のドキュメントで「既知の良い値」、「黄金測定」、または「名目値」と呼ばれることがあります。これらの用語は通常、平等の比較を想定していますが、ここでは参照値がより一般的であり、あらゆる種類の比較で使用される場合があります。
Endorsement:
承認：
A secure statement that an endorser vouches for the integrity of an attester's various capabilities such as claims collection and evidence signing.
承認者が、請求の収集や証拠の署名など、攻撃者のさまざまな機能の整合性を保証する安全な声明。
This document reuses terminology from CDDL [RFC8610]:
このドキュメントは、CDDL [RFC8610]から用語を再利用します。
Group Socket:
グループソケット：
The mechanism by which a CDDL definition is extended, as described in [RFC8610] and [RFC9165].
[RFC8610]および[RFC9165]で説明されているように、CDDL定義が拡張されるメカニズム。
An "EAT" is an encoded (serialized) message, the purpose of which is to transfer a Claims-Set between two parties. An EAT MUST contain a Claims-Set. In this document, an EAT is always a CWT or JWT.
「Eat」はエンコードされた（シリアル化された）メッセージであり、その目的は、2つの当事者間で請求セットを転送することです。食事にはクレームセットが含まれている必要があります。この文書では、食事は常にCWTまたはJWTです。
An EAT MUST have authenticity and integrity protection. CWT and JWT provide that in this document.
食事には、真正性と整合性の保護が必要です。CWTとJWTは、このドキュメントでそれを提供します。
Further documents may define other encodings and security mechanisms for EAT.
さらなる文書は、食事のための他のエンコーディングとセキュリティメカニズムを定義する場合があります。
The identification of a protocol element as an EAT follows the general conventions used for CWTs and JWTs. Identification depends on the protocol carrying the EAT. In some cases, it may be by media type (e.g., in an HTTP Content-Type field). In other cases, it may be through use of CBOR tags. There is no fixed mechanism across all use cases.
EATとしてのプロトコル要素の識別は、CWTSおよびJWTSに使用される一般規則に従います。識別は、食事を運ぶプロトコルに依存します。場合によっては、メディアタイプ（HTTPコンテンツタイプのフィールドなど）によるものかもしれません。それ以外の場合は、CBORタグの使用を介した場合があります。すべてのユースケースに固定メカニズムはありません。
This document also defines another message, the detached EAT bundle (see Section 5), which holds a collection of detached claims sets and an EAT that provides integrity and authenticity protection for them. Detached EAT bundles can be either CBOR or JSON encoded.
このドキュメントでは、別のメッセージ、Detached Eat Bundle（セクション5を参照）も定義します。分離した食事束は、CBORまたはJSONエンコードのいずれかです。
The following CDDL defines the top-level $CBOR-Tagged-Token, $EAT-CBOR-Untagged-Token, and $EAT-JSON-Token-Formats sockets (see Section 3.9 of [RFC8610]), enabling future token formats to be defined. Any new format that plugs into one or more of these sockets MUST be defined by an IETF Standards Action [RFC8126]. Of particular use may be a token type that provides no direct authenticity or integrity protection for use with transport mechanisms that do provide the necessary security services [UCCS].
次のCDDLは、トップレベルの$ cborタグ付きトークン、$ eat-cbor-untagged-token、$ eat-json-tokenフォーマットソケット（[RFC8610]のセクション3.9を参照）を定義し、将来のトークン形式を定義できるようにします。これらのソケットの1つ以上にプラグインする新しい形式は、IETF標準アクション[RFC8126]によって定義する必要があります。特定の使用は、必要なセキュリティサービスを提供する輸送メカニズムで使用するための直接的な信頼性または整合性の保護を提供しないトークンタイプである可能性があります[UCCS]。
Nesting of EATs is allowed and defined in Section 4.2.18.3. This includes the nesting of an EAT that is in a different format than the enclosing EAT, i.e., the nested EAT may be encoded using CBOR and the enclosing EAT encoded using JSON or vice versa. The definition of Nested-Token references the CDDL defined in this section. When new token formats are defined, the means for identification in a nested token MUST also be defined.
食事の営巣は許可され、セクション4.2.18.3で定義されています。これには、囲まれた食事とは異なる形式である食事のネストが含まれます。つまり、ネストされた食事はCBORを使用してエンコードされ、JSONを使用してエンコードされた囲まれたEATまたはその逆も含まれます。ネストされたトークンの定義は、このセクションで定義されているCDDLを参照しています。新しいトークン形式が定義されている場合、ネストされたトークンの識別手段も定義する必要があります。
The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and for JSON-encoded EATs is EAT-JSON-Token (while CDDL and CDDL tools provide enough support for shared definitions of most items in this document, they do not provide enough support for this sharing at the top level).
CborエンコードETSのトップレベルのCDDLタイプはEat-Cor-Tokenであり、JSONエンコードETSの場合はEat-Json-Tokenです（CDDLおよびCDDLツールは、このドキュメントのほとんどのアイテムの共有定義に十分なサポートを提供しますが、この共有に十分なサポートを提供しません）。
EAT-CBOR-Token = $CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
$CBOR-Tagged-Token /= CWT-Tagged-Message
$CBOR-Tagged-Token /= BUNDLE-Tagged-Message
$EAT-CBOR-Untagged-Token /= CWT-Untagged-Message
$EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message
EAT-JSON-Token = $EAT-JSON-Token-Formats
$EAT-JSON-Token-Formats /= JWT-Message
$EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message
This section describes new claims defined for attestation that have been added to the IANA "CBOR Web Token (CWT) Claims" [IANA.CWT.Claims] and "JSON Web Token Claims" [IANA.JWT.Claims] registries.
このセクションでは、IANAに追加されたために定義された新しいクレームについて説明します。
All definitions, requirements, creation and validation procedures, security considerations, IANA registrations, and so on from CWT and JWT carry over to EAT.
すべての定義、要件、作成および検証手順、セキュリティ上の考慮事項、IANA登録など、CWTとJWTからのすべての食事を引き継ぎます。
This section also describes how several extant CWT and JWT claims apply in EAT.
このセクションでは、いくつかの現存するCWTとJWTの主張がEATにどのように適用されるかについても説明します。
The set of claims that an EAT must contain to be considered valid is context dependent and is outside the scope of this specification. Specific applications of EATs will require implementations to understand and process some claims in particular ways. However, in the absence of such requirements, all claims that are not understood by implementations MUST be ignored.
食事が有効であると見なされるために封じ込められなければならないという主張のセットは、コンテキストに依存し、この仕様の範囲外です。eatsの特定のアプリケーションでは、特定の方法でいくつかの主張を理解し、処理するための実装が必要です。ただし、そのような要件がない場合、実装によって理解されていないすべてのクレームは無視する必要があります。
CDDL, along with a text description, is used to define each claim independent of encoding. Each claim is defined as a CDDL group. In "Encoding and Collected CDDL" (Section 7), the CDDL groups turn into CBOR map entries and JSON name/value pairs.
CDDLは、テキストの説明とともに、エンコードとは無関係に各クレームを定義するために使用されます。各クレームはCDDLグループとして定義されます。「CDDLのエンコードと収集」（セクション7）では、CDDLグループはCBORマップエントリとJSON名/値ペアに変わります。
Each claim defined in this document is added to the $$Claims-Set-Claims group socket. Claims defined by other specifications MUST also be added to the $$Claims-Set-Claims group socket.
このドキュメントで定義されている各クレームは、$$クレームセットクレームグループソケットに追加されます。他の仕様によって定義されたクレームは、$$クレームセットクレームグループソケットにも追加する必要があります。
All claims in an EAT MUST use the same encoding except where otherwise explicitly stated (e.g., in a CBOR-encoded token, all claims must be encoded with CBOR).
EATのすべての請求は、明示的に述べられている場合を除き、同じエンコードを使用する必要があります（たとえば、Cborエンコードされたトークンでは、すべてのクレームはCBORでエンコードする必要があります）。
This specification provides a CDDL definition for most of the elements defined in [RFC7519] and [RFC8392]. These definitions are in Appendix D and are not normative.
この仕様は、[RFC7519]および[RFC8392]で定義されているほとんどの要素のCDDL定義を提供します。これらの定義は付録Dにあり、規範的ではありません。
Each claim described has a unique text string and integer that identifies it. CBOR-encoded tokens MUST only use the integer for claim keys. JSON-encoded tokens MUST only use the text string for claim names.
記載されている各クレームには、それを識別する一意のテキスト文字列と整数があります。CBORエンコードトークンは、クレームキーにのみ整数を使用する必要があります。JSONエンコードトークンは、クレーム名にテキスト文字列のみを使用する必要があります。
In JSON, an EAT nonce is either a text string or an array of text strings. In CBOR, an EAT nonce is either a byte string or an array of byte strings. The array option supports multistage EAT verification and consumption.
JSONでは、Eat Nonceはテキスト文字列またはテキスト文字列の配列のいずれかです。Cborでは、Eat Nonceはバイト文字列またはバイト文字列の配列のいずれかです。配列オプションは、多段階のEAT検証と消費をサポートします。
A claim named "nonce" was defined for JWT and registered with IANA in the "JSON Web Token Claims" registry, but it MUST NOT be used because it does not support multiple nonces. No previous "nonce" claim was defined for CWT. To distinguish from the previously defined JWT "nonce" claim, this claim is named "eat_nonce" in JSON-encoded EATs. The CWT nonce defined here is intended for general purpose use and retains the "Nonce" claim name instead of an EAT-specific name.
「nonce」という名前のクレームはJWTに対して定義され、「JSON Webトークンクレーム」レジストリでIANAに登録されましたが、複数のNoncesをサポートしていないため使用してはなりません。CWTについては、以前の「NonCe」クレームは定義されていません。以前に定義されたJWT「ノンセ」の主張と区別するために、この主張はJSONエンコードEATSで「EAT_NONCE」と名付けられています。ここで定義されているCWT Nonceは、汎用の使用を目的としており、EAT固有の名前ではなく「NonCe」クレーム名を保持します。
An EAT nonce MUST have at least 64 bits of entropy. A maximum EAT nonce size is set to limit the memory required for an implementation. All receivers MUST be able to accommodate the maximum size.
Eat Nonceには、少なくとも64ビットのエントロピーが必要です。実装に必要なメモリを制限するように、最大EATノンセサイズが設定されています。すべてのレシーバーは、最大サイズに対応できる必要があります。
In CBOR, an EAT nonce is a byte string between 8 and 64 bytes in length. In JSON, an EAT nonce is a text string between 8 and 88 bytes in length.
Cborでは、Eat Nonceは長さ8〜64バイトのバイト文字列です。JSONでは、Eat Nonceは長さ8〜88バイトのテキスト文字列です。
$$Claims-Set-Claims //=
(nonce-label => nonce-type / [ 2* nonce-type ])
nonce-type = JC< tstr .size (8..88), bstr .size (8..64)>
The claims in this section describe the entity itself. They describe the entity whether they occur in evidence or occur in attestation results. See Section 1.3.1 for discussion on how attestation results relate to evidence.
このセクションの主張は、エンティティ自体について説明しています。彼らは、それらが証拠で発生するか、認証結果で発生するかどうかを実体に説明します。証拠の結果が証拠にどのように関連するかについての議論については、セクション1.3.1を参照してください。
The "ueid" claim conveys a UEID, which identifies an individual manufactured entity such as a mobile phone, water meter, Bluetooth speaker, or networked security camera. It may identify the entire entity or a submodule. It does not identify types, models, or classes of entities. It is akin to a serial number, though it does not have to be sequential.
「UEID」クレームは、携帯電話、水道メーター、Bluetoothスピーカー、ネットワークセキュリティカメラなどの個々の製造されたエンティティを識別するUEIDを伝えます。エンティティ全体またはサブモジュールを識別する場合があります。エンティティの種類、モデル、またはクラスを識別しません。シーリアル番号に似ていますが、シーケンシャルである必要はありません。
UEIDs MUST be universally and globally unique across manufacturers and countries, as described in Section 4.2.1.1. UEIDs MUST also be unique across protocols and systems, as tokens are intended to be embedded in many different protocols and systems. No two products anywhere, even in completely different industries made by two different manufacturers in two different countries, should have the same UEID (if they are not global and universal in this way, then relying parties receiving them will have to track other characteristics of the entity to keep entities distinct between manufacturers).
UEIDは、セクション4.2.1.1で説明されているように、製造業者と国全体で普遍的およびグローバルにユニークでなければなりません。トークンは多くの異なるプロトコルとシステムに組み込まれることを目的としているため、UEIDはプロトコルとシステム全体で一意でなければなりません。2つの異なる国の2つの異なるメーカーによって作成された完全に異なる業界でさえ、2つの製品は同じUEIDを持つ必要があります（このようにグローバルで普遍的ではない場合、それらを受け取る当事者に依存して、エンティティの他の特性を追跡する必要があります）。
UEIDs are not designed for direct use by humans (e.g., printing on the case of a device), so no such representation is defined.
UEIDは、人間が直接使用するように設計されていません（例：デバイスの場合に印刷）ため、そのような表現は定義されていません。
There are privacy considerations for UEIDs. See Section 8.1.
UEIDSにはプライバシーに関する考慮事項があります。セクション8.1を参照してください。
A Device Identifier (DevID) URN is registered for UEIDs. See Section 10.3.
デバイス識別子（devid）urnがueidsに登録されています。セクション10.3を参照してください。
$$Claims-Set-Claims //= (ueid-label => ueid-type)
ueid-type = JC<base64-url-text .size (10..44) , bstr .size (7..33)>
These rules are solely for the creation of UEIDs. The EAT consumer need not have any awareness of them.
これらのルールは、UEIDSの作成専用です。Eat Consumerは、それらの意識を持っている必要はありません。
A UEID is constructed of a single type byte followed by the unique bytes for that type. The type byte assures global uniqueness of a UEID even if the unique bytes for different types are accidentally the same.
UEIDは、単一のタイプバイトで構成され、その後、そのタイプの一意のバイトが続きます。タイプバイトは、異なるタイプの一意のバイトが誤って同じであっても、UEIDのグローバルな一意性を保証します。
UEIDS are of variable length to accommodate the types defined here as well as future-defined types.
UEIDは、ここで定義されているタイプと将来定義されたタイプに対応するためのさまざまな長さです。
UEIDs SHOULD NOT be longer than 33 bytes. If they are longer, there is no guarantee that a receiver will be able to accept them. See Appendix B.
ueidsは33バイトを超えてはなりません。それらが長い場合、レシーバーがそれらを受け入れることができるという保証はありません。付録Bを参照してください
A UEID is permanent. It MUST NOT change for a given entity.
UEIDは永続的です。特定のエンティティに対して変更してはなりません。
The different types of UEIDs 1) accommodate different manufacturing processes, 2) accommodate small UEIDs, and 3) provide an option that does not require registration fees and central administration.
さまざまな種類のUEID 1）さまざまな製造プロセスに対応し、2）小さなUEIDに対応し、3）登録料と中央管理を必要としないオプションを提供します。
In the unlikely event that a new UEID type is needed, it MUST be defined in an update to this document on the Standards Track.
新しいUEIDタイプが必要である可能性が低い場合、標準トラックのこのドキュメントの更新で定義する必要があります。
A manufacturer of entities MAY use different types for different products. They MAY also change from one type to another for a given product or use one type for some items of a given product and another type for others.
エンティティのメーカーは、異なる製品に異なるタイプを使用する場合があります。また、特定の製品に対して1つのタイプから別のタイプに変更するか、特定の製品の一部のアイテムに1つのタイプを使用し、他の製品のために別のタイプを使用する場合があります。
+======+======+====================================================+
| Type | Type | Specification |
| Byte | Name | |
+======+======+====================================================+
| 0x01 | RAND | This is a 128-, 192-, or 256-bit random number |
| | | generated once and stored in the entity. This may |
| | | be constructed by concatenating enough identifiers |
| | | to make up an equivalent number of random bits and |
| | | then feeding the concatenation through a |
| | | cryptographic hash function. It may also be a |
| | | cryptographic quality random number generated once |
| | | at the beginning of the life of the entity and |
| | | stored. It MUST NOT be smaller than 128 bits. |
| | | See the length analysis in Appendix B. |
+------+------+----------------------------------------------------+
| 0x02 | IEEE | This makes use of the device identification scheme |
| | EUI | operated by the IEEE. An Extended Unique |
| | | Identifier (EUI) can be an EUI-48, EUI-60, or |
| | | EUI-64 and consists of two parts. The first part |
| | | is a registered company identifier, an |
| | | Organizationally Unique Identifier (OUI), an OUI- |
| | | 36, or a Company ID (CID). The second part |
| | | ensures uniqueness within the registered company. |
| | | EUIs are often the same as or similar to MAC |
| | | addresses. This type includes MAC-48, an obsolete |
| | | name for EUI-48. (Note that while entities with |
| | | multiple network interfaces may have multiple MAC |
| | | addresses, there is only one UEID for an entity; |
| | | changeable MAC addresses that do not meet the |
| | | permanence requirements in this document MUST NOT |
| | | be used for the UEID or Semipermanent UEID |
| | | (SUEID).) See [IEEE.802-2014] and [OUI.Guide]. |
+------+------+----------------------------------------------------+
| 0x03 | IMEI | This makes use of the International Mobile |
| | | Equipment Identity (IMEI) scheme operated by the |
| | | Global System for Mobile Communications |
| | | Association (GSMA). This is a 14-digit identifier |
| | | consisting of an 8-digit Type Allocation Code |
| | | (TAC) and a 6-digit serial number allocated by the |
| | | manufacturer, which SHALL be encoded as a byte |
| | | string of length 14 with each byte as the digit's |
| | | value (not the ASCII encoding of the digit; the |
| | | digit 3 encodes as 0x03, not 0x33). The IMEI |
| | | encoded value SHALL NOT include the Luhn checksum |
| | | or Software Version Number (SVN) information. See |
| | | [ThreeGPP.IMEI]. |
+------+------+----------------------------------------------------+
Table 1: UEID Composition Types
表1：UEID組成タイプ
For the consumer, a UEID is solely a globally unique opaque identifier. The consumer does not and should not have any awareness of the rules and structure used to achieve global uniqueness.
消費者にとって、UEIDは単にグローバルにユニークな不透明な識別子です。消費者は、グローバルな独自性を達成するために使用されるルールと構造を認識しておらず、そうすべきではありません。
All implementations MUST be able to receive UEIDs up to 33 bytes long. 33 bytes is the longest defined in this document and gives necessary entropy for probabilistic uniqueness.
すべての実装は、最大33バイトのUEIDを受信できる必要があります。33バイトは、このドキュメントで最も長く定義されており、確率的な独自性に必要なエントロピーを提供します。
The consumer of a UEID MUST treat it as a completely opaque string of bytes and MUST NOT make any use of its internal structure. The reasons for this are:
UEIDの消費者は、それを完全に不透明なバイトのストリングとして扱う必要があり、その内部構造を使用してはなりません。これの理由は次のとおりです。
* UEID types vary freely from one manufacturer to the next.
* UEIDタイプは、メーカーによって自由に異なります。
* New types of UEIDs may be defined.
* 新しいタイプのUEIDが定義される場合があります。
* The manufacturer of an entity is allowed to change from one type of UEID to another anytime they want.
* エンティティの製造業者は、いつでもueidのタイプから別のタイプのタイプに変更することができます。
For example, when the consumer receives a type 0x02 UEID, they should not use the OUI part to identify the manufacturer of the device because there is no guarantee all UEIDs will be type 0x02. Different manufacturers may use different types. A manufacturer may make some of their product with one type and others with a different type or even change to a different type for newer versions of their product. Instead, the consumer should use the "oemid" claim.
たとえば、消費者がタイプ0x02 UEIDを受け取った場合、すべてのUEIDがタイプ0x02になる保証がないため、Deviceのメーカーを識別するためにOUIパーツを使用しないでください。さまざまなメーカーが異なるタイプを使用する場合があります。メーカーは、1つのタイプで製品の一部を作成し、他の製品を異なるタイプのあるものや、製品の新しいバージョンの場合は異なるタイプに変更することさえできます。代わりに、消費者は「OEMID」クレームを使用する必要があります。
The "sueids" claim conveys one or more semipermanent UEIDs (SUEIDs). An SUEID has the same format, characteristics, and requirements as a UEID but MAY change to a different value on entity life-cycle events. An entity MAY have both a UEID and SUEIDs, neither, or one or the other.
「Sueids」の主張は、1つまたは複数のセミパーマネントUeids（Sueids）を伝えます。Sueidは、UEIDと同じ形式、特性、および要件を持っていますが、エンティティライフサイクルイベントで異なる価値に変更される場合があります。エンティティには、ueidとsueidsの両方があり、どちらか、どちらか、どちらかを持っている場合があります。
Examples of life-cycle events are change of ownership, factory reset, and onboarding into an IoT device management system. It is beyond the scope of this document to specify particular types of SUEIDs and the life-cycle events that trigger their change. An EAT profile MAY provide this specification.
ライフサイクルイベントの例は、所有権の変更、工場のリセット、およびIoTデバイス管理システムへのオンボーディングです。このドキュメントの範囲を超えて、特定のタイプのスイイドと、変更を引き起こすライフサイクルイベントを指定することです。EATプロファイルは、この仕様を提供する場合があります。
There MAY be multiple SUEIDs. Each has a text string label, the purpose of which is to distinguish it from others. The label MAY name the purpose, application, or type of the SUEID. For example, the label for the SUEID used by the XYZ Onboarding Protocol could thus be "XYZ". It is beyond the scope of this document to specify any SUEID labeling schemes. They are use case specific and MAY be specified in an EAT profile.
複数のスイイドがあるかもしれません。それぞれにテキスト文字列ラベルがあり、その目的はそれを他と区別することです。ラベルには、Sueidの目的、アプリケーション、またはタイプに名前を付けることができます。たとえば、XYZオンボーディングプロトコルで使用されるスイイドのラベルは、「XYZ」である可能性があります。このドキュメントの範囲を超えて、Sueidラベル付けスキームを指定します。それらはユースケース固有であり、EATプロフィールで指定される場合があります。
If there is only one SUEID, the claim remains a map and there still MUST be a label.
Sueidが1つしかない場合、クレームはマップのままであり、まだラベルが必要です。
An SUEID provides functionality similar to an IEEE Local Device Identifier (LDevID) [IEEE.802.1AR].
Sueidは、IEEEローカルデバイス識別子（LDEVID）[IEEE.802.1AR]と同様の機能を提供します。
There are privacy considerations for SUEIDs; see Section 8.1.
Sueidsにはプライバシーに関する考慮事項があります。セクション8.1を参照してください。
A DevID URN is registered for SUEIDs; see Section 10.3.
Devid URNはSueidsに登録されています。セクション10.3を参照してください。
$$Claims-Set-Claims //= (sueids-label => sueids-type)
sueids-type = {
+ tstr => ueid-type
}
The "oemid" claim identifies the Original Equipment Manufacturer (OEM) of the hardware. Any of the three forms described below MAY be used at the convenience of the claim sender. The receiver of this claim MUST be able to handle all three forms.
「OEMID」クレームは、ハードウェアの元の機器メーカー（OEM）を識別します。以下に説明する3つのフォームのいずれかは、クレーム送信者の都合で使用できます。このクレームの受信者は、3つのフォームすべてを処理できる必要があります。
Note that the "hwmodel" claim in Section 4.2.4, the "oemboot" claim in Section 4.2.8, and the "dbgstat" claim in Section 4.2.9 depend on this claim.
セクション4.2.4の「HWModel」請求、セクション4.2.8の「OEMBoot」請求、およびセクション4.2.9の「DBGSTAT」請求は、このクレームに依存することに注意してください。
Sometimes one manufacturer will acquire or merge with another. Depending on the situation and use case, newly manufactured devices may continue to use the old OEM ID or switch to a new one. This is left to the discretion of the manufacturers, but they should consider how it affects the above-mentioned claims and the attestation ecosystem for their devices. The considerations are the same for all three forms of this claim.
あるメーカーは、別のメーカーと取得またはマージすることがあります。状況とユースケースに応じて、新しく製造されたデバイスは引き続き古いOEM IDを使用するか、新しいデバイスを新しいものに切り替えることができます。これはメーカーの裁量に任されていますが、彼らはそれが上記の請求とデバイスの証明エコシステムにどのように影響するかを考慮する必要があります。考慮事項は、この主張の3つの形式すべてで同じです。
The random number-based OEM ID MUST be 16 bytes (128 bits) long.
乱数ベースのOEM IDは、16バイト（128ビット）の長さでなければなりません。
The OEM may create their own ID by using a cryptographic-quality random number generator. They would perform this only once in the life of the company to generate the single ID for said company. They would use that same ID in every entity they make. This uniquely identifies the OEM on a statistical basis and is large enough should there be ten billion companies.
OEMは、暗号化品質の乱数ジェネレーターを使用して、独自のIDを作成する場合があります。彼らはこれを会社の寿命で一度だけ実行して、上記の会社の単一のIDを生成しました。彼らは、彼らが作るすべてのエンティティで同じIDを使用します。これは、OEMを統計的にユニークに識別し、100億社が存在する場合は十分に大きくなります。
In JSON-encoded tokens, this MUST be base64url encoded.
JSONエンコードトークンでは、これはbase64urlエンコードされている必要があります。
The IEEE operates a global registry for MAC addresses and company IDs. This claim uses that database to identify OEMs. The contents of the claim may be either an IEEE MA-L, MA-M, MA-S, or CID [IEEE-RA]. An MA-L (formerly known as an OUI) is a 24-bit value used as the first half of a MAC address. Similarly, MA-M is a 28-bit value used as the first part of a MAC address, and MA-S (formerly known as OUI-36) is a 36-bit value. Many companies have already obtained an OEM ID from the IEEE registry. A CID is also a 24-bit value from the same space as an MA-L but is not for use as a MAC address. IEEE has published Guidelines for Use of EUI, OUI, and CID [OUI.Guide] and provides a lookup service [OUI.Lookup].
IEEEは、Macアドレスと会社IDのグローバルレジストリを運営しています。このクレームは、そのデータベースを使用してOEMを識別します。クレームの内容は、IEEE MA-L、MA-M、MA-S、またはCID [IEEE-RA]のいずれかです。MA-L（以前はOUIとして知られていました）は、MACアドレスの前半として使用される24ビット値です。同様に、MA-MはMACアドレスの最初の部分として使用される28ビット値であり、MA-S（以前はOUI-36として知られていました）は36ビット値です。多くの企業は、すでにIEEEレジストリからOEM IDを取得しています。CIDは、MA-Lと同じスペースからの24ビット値でもありますが、MACアドレスとして使用するためではありません。IEEEは、EUI、OUI、およびCID [oui.guide]を使用するためのガイドラインを公開し、ルックアップサービス[oui.lookup]を提供しています。
Companies that have more than one of these IDs or MAC address blocks SHOULD select one as preferred and use that for all their entities.
これらのIDまたはMACアドレスブロックを複数持っている企業は、1つを選択し、すべてのエンティティにそれを使用する必要があります。
Commonly, these are expressed in "hexadecimal representation" as described in [IEEE.802-2014]. When this claim is encoded, the order of bytes in the bstr is the same as the order in the "hexadecimal representation". For example, an MA-L like "AC-DE-48" would be encoded in 3 bytes with values 0xAC, 0xDE, and 0x48.
一般的に、これらは[IEEE.802-2014]に記載されているように、「六分位表現」で表されます。このクレームがエンコードされると、BSTRのバイトの順序は、「六分位表現」の順序と同じです。たとえば、「AC-DE-48」のようなMA-Lは、値0xAC、0xDE、および0x48の3バイトでエンコードされます。
This format is always 3 bytes in size in CBOR.
この形式は、CBORのサイズが常に3バイトです。
In JSON-encoded tokens, this MUST be base64url encoded and always 4 bytes.
JSONエンコードトークンでは、これはbase64urlエンコードされ、常に4バイトである必要があります。
IANA maintains a registry for Private Enterprise Numbers [PEN]. A PEN is an integer that identifies an enterprise, and it may be used to construct an object identifier (OID) relative to the following OID arc that is managed by IANA: iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1).
IANAは、プライベートエンタープライズ番号[PEN]のレジストリを維持しています。ペンは企業を識別する整数であり、IANAによって管理される次のOIDアークに関連するオブジェクト識別子（OID）を構築するために使用される場合があります。
For EAT purposes, only the integer value assigned by IANA as the PEN is relevant, not the full OID value.
EATの目的では、ペンとしてIANAによって割り当てられた整数値のみが関連性があり、完全なOID値ではありません。
In CBOR, this value MUST be encoded as a major type 0 integer and is typically 3 bytes. In JSON, this value MUST be encoded as a number.
CBORでは、この値は主要なタイプ0整数としてエンコードする必要があり、通常は3バイトです。JSONでは、この値は数としてエンコードする必要があります。
$$Claims-Set-Claims //= (
oemid-label => oemid-type
)
oemid-type => oemid-pen / oemid-ieee / oemid-random
oemid-pen = int
oemid-ieee = JC<oemid-ieee-json, oemid-ieee-cbor>
oemid-ieee-cbor = bstr .size 3
oemid-ieee-json = base64-url-text .size 4
oemid-random = JC<oemid-random-json, oemid-random-cbor>
oemid-random-cbor = bstr .size 16
oemid-random-json = base64-url-text .size 24
The "hwmodel" claim differentiates hardware models, products, and variants manufactured by a particular OEM, namely the one identified by the OEM ID in Section 4.2.3. It MUST be unique within a given OEM ID. The concatenation of the OEM ID and "hwmodel" gives a global identifier of a particular product. The "hwmodel" claim MUST only be present if an "oemid" claim described in Section 4.2.3 is present.
「HWModel」クレームは、特定のOEMによって製造されたハードウェアモデル、製品、およびバリアント、つまりセクション4.2.3のOEM IDで識別されたものを区別します。特定のOEM ID内で一意でなければなりません。OEM IDと「HWModel」の連結は、特定の製品のグローバル識別子を提供します。「hwmodel」クレームは、セクション4.2.3に記載されている「OEMID」クレームが存在する場合にのみ存在する必要があります。
The granularity of the model identification is for each OEM to decide. It may be very granular, perhaps including some version information. It may be very general, perhaps only indicating top-level products.
モデル識別の粒度は、各OEMが決定することです。おそらくいくつかのバージョン情報を含む非常に粒状かもしれません。それは非常に一般的であり、おそらくトップレベルの製品のみを示しているかもしれません。
The "hwmodel" claim is for use in protocols and not for human consumption. The format and encoding of this claim should not be human readable to discourage use other than in protocols. If this claim is to be derived from an already-in-use human-readable identifier, it can be run through a hash function.
「hwmodel」クレームは、人間の消費ではなく、プロトコルで使用するためのものです。このクレームの形式とエンコードは、プロトコル以外の使用を阻止するために人間が読みやすいはずです。この主張が、すでに使用されている人間の読み取り可能な識別子から導き出される場合、ハッシュ関数を介して実行できます。
There is no minimum length so that an OEM with a very small number of models can use a one-byte encoding. The maximum length is 32 bytes. All receivers of this claim MUST be able to receive this maximum size.
最小の長さはありませんので、非常に少数のモデルを備えたOEMが1バイトのエンコードを使用できます。最大長は32バイトです。このクレームのすべての受信機は、この最大サイズを受信できる必要があります。
The receiver of this claim MUST treat it as a completely opaque string of bytes, even if there is some apparent naming or structure. The OEM is free to alter the internal structure of these bytes as long as the claim continues to uniquely identify its models.
このクレームの受信者は、明白な命名または構造がある場合でも、完全に不透明なバイトの文字列として扱わなければなりません。OEMは、クレームがモデルを一意に識別し続けている限り、これらのバイトの内部構造を自由に変更できます。
$$Claims-Set-Claims //= (
hardware-model-label => hardware-model-type
)
hardware-model-type = JC<base64-url-text .size (4..44),
bytes .size (1..32)>
The "hwversion" claim is a text string, of which the format is set by each manufacturer. The structure and sorting order of this text string can be specified using the version-scheme item from Concise Software Identification (CoSWID) [RFC9393]. It is useful to know how to sort versions so the newer ones can be distinguished from the older ones. A "hwversion" claim MUST only be present if a "hwmodel" claim, as described in Section 4.2.4, is present.
「Hwversion」クレームはテキスト文字列であり、その形式は各メーカーによって設定されています。このテキスト文字列の構造と並べ替え順序は、簡潔なソフトウェア識別（CoSWID）[RFC9393]のバージョンスキームアイテムを使用して指定できます。新しいバージョンを古いものと区別できるように、バージョンを並べ替える方法を知ることは便利です。セクション4.2.4で説明されているように、「HWModel」クレームが存在する場合にのみ、「Hwversion」クレームが存在する必要があります。
$$Claims-Set-Claims //= (
hardware-version-label => hardware-version-type
)
hardware-version-type = [
version: tstr,
? scheme: $version-scheme
]
The "swname" claim contains a very simple free-form text value for naming the software used by the entity. Intentionally, no general rules or structure are set. This will make it unsuitable for use cases that wish precise naming.
「swname」クレームには、エンティティが使用するソフトウェアに名前を付けるための非常にシンプルな自由形式のテキスト値が含まれています。意図的に、一般的なルールや構造は設定されていません。これにより、正確な命名を希望するユースケースには不適切になります。
If precise and rigorous naming of the software for the entity is needed, the "manifests" claim, as described in Section 4.2.15, may be used instead.
エンティティ用のソフトウェアの正確かつ厳密な命名が必要な場合、セクション4.2.15で説明されているように、「マニフェスト」クレームを代わりに使用できます。
$$Claims-Set-Claims //= ( sw-name-label => tstr )
The "swversion" claim makes use of the CoSWID version-scheme defined in [RFC9393] to give a simple version for the software. A "swversion" claim MUST only be present if a "swname" claim, as described in Section 4.2.6, is present.
「swversion」クレームは、[rfc9393]で定義されているコスウィッドバージョンのシェムを使用して、ソフトウェアに簡単なバージョンを提供します。セクション4.2.6に記載されているように、「Swversion」クレームが存在する場合にのみ存在する必要があります。
The "manifests" claim (Section 4.2.15) may be used instead if this is too simple.
これが単純すぎる場合、代わりに「マニフェスト」クレーム（セクション4.2.15）を使用できます。
$$Claims-Set-Claims //= (sw-version-label => sw-version-type)
sw-version-type = [
version: tstr
? scheme: $version-scheme
]
An "oemboot" claim with a value of "true" indicates that the entity booted with software authorized by the manufacturer of the entity as indicated by the "oemid" claim described in Section 4.2.3. It indicates that the firmware and operating system are fully under control of the OEM and may not be replaced by the end user or even the enterprise that owns the device. The means of control may be by cryptographic authentication of the software, the software being in Read-Only Memory (ROM), a combination of the two, or other. If this claim is present, the "oemid" claim MUST be present.
「真」の値を持つ「oEmboot」クレームは、セクション4.2.3で説明されている「OEMID」請求で示されているように、エンティティの製造業者によって承認されたソフトウェアで起動されたエンティティが起動したことを示しています。これは、ファームウェアとオペレーティングシステムがOEMを完全に制御しており、エンドユーザーやデバイスを所有しているエンタープライズに置き換えられない可能性があることを示しています。制御の手段は、ソフトウェアの暗号化の認証、ソフトウェアが読み取り専用メモリ（ROM）、2つの組み合わせなどのものです。この主張が存在する場合、「OEMID」クレームが存在する必要があります。
$$Claims-Set-Claims //= (oem-boot-label => bool)
The "dbgstat" claim applies to entity-wide or submodule-wide debug facilities of the entity like [JTAG] and diagnostic hardware built into chips. It applies to any software debug facilities related to privileged software that allows system-wide memory inspection, tracing, or modification of non-system software like user-mode applications.
「DBGSTAT」クレームは、[JTAG]やチップに組み込まれた診断ハードウェアなどのエンティティ全体またはサブモジュール全体のデバッグ機能に適用されます。これは、ユーザーモードアプリケーションなどの非システムソフトウェアのシステム全体のメモリ検査、トレース、または変更を可能にする特権ソフトウェアに関連するソフトウェアデバッグ機能に適用されます。
This characterization assumes that debug facilities can be enabled and disabled in a dynamic way or be disabled in some permanent way, such that no enabling is possible. An example of dynamic enabling is one where some authentication is required to enable debugging. An example of permanent disabling is blowing a hardware fuse in a chip. The specific type of the mechanism is not taken into account. For example, it does not matter if authentication is by a global password or by per-entity public keys.
この特性評価は、デバッグファシリティを動的な方法で有効にして無効にするか、ある程度の永続的な方法で無効にすることができるため、有効化が不可能であることを前提としています。動的有効化の例は、デバッグを有効にするために何らかの認証が必要な場合です。永続的な無効化の例は、チップにハードウェアヒューズを吹き付けることです。特定のタイプのメカニズムは考慮されていません。たとえば、認証がグローバルパスワードによるものであるか、エンティティごとのパブリックキーによるものであるかは関係ありません。
As with all claims, the absence of the "dbgstat" claim means it is not reported.
すべての主張と同様に、「dbgstat」クレームがないことは、それが報告されていないことを意味します。
This claim is not extensible so as to provide a common interoperable description of debug status. If a particular implementation considers this claim to be inadequate, it can define its own proprietary claim. It may consider including both this claim as a coarse indication of debug status and its own proprietary claim as a refined indication.
このクレームは、デバッグステータスの一般的な相互運用可能な説明を提供するために拡張できません。特定の実装がこの主張が不十分であると考える場合、独自の主張を定義できます。この主張の両方を、デバッグステータスの粗い兆候と洗練された兆候として独自の主張を含めることを検討することができます。
The higher levels of debug disabling require that all debug disabling of the levels below it be in effect. Since the lowest level requires that all of the target's debug be currently disabled, all other levels require that too.
デバッグ無効化のより高いレベルでは、その下のレベルのすべてのデバッグ無効化が有効である必要があります。最も低いレベルでは、ターゲットのすべてのデバッグが現在無効になることを要求するため、他のすべてのレベルもそれを必要とします。
There is no inheritance of claims from a submodule to a superior module or vice versa. There is no assumption, requirement, or guarantee that the target of a superior module encompasses the targets of submodules. Thus, every submodule must explicitly describe its own debug state. The receiver of an EAT MUST NOT assume that debug is turned off in a submodule because there is a claim indicating it is turned off in a superior module.
サブモジュールから優れたモジュール、またはその逆への請求の継承はありません。優れたモジュールのターゲットがサブモジュールのターゲットを網羅するという仮定、要件、または保証はありません。したがって、すべてのサブモジュールは、独自のデバッグ状態を明示的に説明する必要があります。食事の受信者は、優れたモジュールでオフになっていることを示すクレームがあるため、デバッグがサブモジュールでオフになっていると想定してはなりません。
An entity may have multiple debug facilities. The use of plural in the description of the states refers to that, not to any aggregation or inheritance.
エンティティには複数のデバッグ機能がある場合があります。州の説明における複数形の使用は、それを指し、集約や相続財産ではありません。
The architecture of some chips or devices may be such that a debug facility operates for the whole chip or device. If the EAT for such a chip includes submodules, then each submodule should independently report the status of the whole-chip or whole-device debug facility. This is the only way the receiver can know the debug status of the submodules since there is no inheritance.
一部のチップまたはデバイスのアーキテクチャは、デバッグ機能がチップまたはデバイス全体で動作するようなものである可能性があります。そのようなチップの食事にサブモジュールが含まれている場合、各サブモジュールは、チップ全体または全デバイスデバッグ機能のステータスを独立して報告する必要があります。これは、継承がないため、受信者がサブモジュールのデバッグステータスを知ることができる唯一の方法です。
If any debug facility, even manufacturer hardware diagnostics, is currently enabled, then this level must be indicated.
現在、メーカーのハードウェア診断が有効になっているデバッグ機能、さらには、このレベルを示す必要があります。
This level indicates all debug facilities are currently disabled. It may be possible to enable them in the future. It may also be that they were enabled in the past but are currently disabled.
このレベルは、すべてのデバッグ機能が現在無効になっていることを示しています。将来それらを有効にすることが可能かもしれません。また、それらは過去に有効になっていたが、現在無効になっている可能性があります。
This level indicates all debug facilities are currently disabled and have been so since the entity booted/started.
このレベルは、すべてのデバッグ機能が現在無効になっており、エンティティが起動/開始されてからそうなっていることを示しています。
This level indicates all non-manufacturer facilities are permanently disabled such that no end user or developer can enable them. Only the manufacturer indicated in the "oemid" claim can enable them. This also indicates that all debug facilities are currently disabled and have been so since boot/start. If this debug state is reported, the "oemid" claim MUST be present.
このレベルは、すべての非製造施設が永久に無効になっているため、エンドユーザーや開発者がそれらを有効にすることができないことを示しています。「OEMID」クレームに示されたメーカーのみがそれらを有効にすることができます。これはまた、すべてのデバッグ機能が現在無効になっており、起動/起動以来そのようになっていることを示しています。このデバッグ状態が報告されている場合、「OEMID」クレームが存在する必要があります。
This level indicates that all debug facilities for the entity are permanently disabled.
このレベルは、エンティティのすべてのデバッグ機能が永久に無効になっていることを示しています。
$$Claims-Set-Claims //= ( debug-status-label => debug-status-type )
debug-status-type = ds-enabled /
disabled /
disabled-since-boot /
disabled-permanently /
disabled-fully-and-permanently
ds-enabled = JC< "enabled", 0 >
disabled = JC< "disabled", 1 >
disabled-since-boot = JC< "disabled-since-boot", 2 >
disabled-permanently = JC< "disabled-permanently", 3 >
disabled-fully-and-permanently =
JC< "disabled-fully-and-permanently", 4 >
The "location" claim gives the geographic position of the entity from which the attestation originates. Latitude, longitude, altitude, accuracy, altitude-accuracy, heading, and speed MUST be as defined in the W3C Geolocation API [W3C.GeoLoc] (which, in turn, is based on [WGS84]). If the entity is stationary, the heading is 'null'. Latitude and longitude MUST be provided. If any other of these values are unknown, they are omitted.
「場所」クレームは、証明が始まるエンティティの地理的位置を与えます。緯度、経度、高度、精度、高度acccuracy、見出し、および速度は、W3C Geolocation API [w3c.geoloc]で定義されている必要があります（これは[WGS84]に基づいています）。エンティティが静止している場合、見出しは「ヌル」です。緯度と経度を提供する必要があります。これらの値の他のいずれかが不明な場合、それらは省略されています。
The location may have been cached for a period of time before token creation. For example, it might have been minutes, hours, or more since the last contact with a satellite in the Global Navigation Satellite System (GNSS). Either the timestamp or the age data item can be used to quantify the cached period. The timestamp data item is preferred as it is a non-relative time. If the entity has no clock or the clock is unset but has a means to measure the time interval between the acquisition of the location and the token creation, the age may be reported instead. The age is in seconds.
場所は、トークン作成の前にしばらくキャッシュされていた可能性があります。たとえば、グローバルナビゲーション衛星システム（GNSS）の衛星との最後の接触から数分、時間、またはそれ以上であった可能性があります。タイムスタンプまたは年齢データ項目を使用して、キャッシュ期間を定量化できます。タイムスタンプのデータ項目は、非関連時間であるため好まれます。エンティティにクロックがないか、クロックが設定されていないが、場所の取得とトークン作成の間の時間間隔を測定する手段がある場合、代わりに年齢を報告することができます。年齢は数秒です。
See location-related privacy considerations in Section 8.2.
セクション8.2の場所関連のプライバシーに関する考慮事項を参照してください。
$$Claims-Set-Claims //= (location-label => location-type)
location-type = {
latitude => number,
longitude => number,
? altitude => number,
? accuracy => number,
? altitude-accuracy => number,
? heading => number / null,
? speed => number,
? timestamp => ~time-int,
? age => uint
}
latitude = JC< "latitude", 1 >
longitude = JC< "longitude", 2 >
altitude = JC< "altitude", 3 >
accuracy = JC< "accuracy", 4 >
altitude-accuracy = JC< "altitude-accuracy", 5 >
heading = JC< "heading", 6 >
speed = JC< "speed", 7 >
timestamp = JC< "timestamp", 8 >
age = JC< "age", 9 >
The "uptime" claim contains the number of seconds that have elapsed since the entity or submodule was last booted.
「アップタイム」クレームには、エンティティまたはサブモジュールが最後に起動されてから経過した秒数が含まれています。
$$Claims-Set-Claims //= (uptime-label => uint)
The "bootcount" claim contains a count of the number of times the entity or submodule has been booted. Support for this claim requires a persistent storage on the device.
「BootCount」クレームには、エンティティまたはサブモジュールが起動した回数の数が含まれています。このクレームのサポートには、デバイス上の永続的なストレージが必要です。
$$Claims-Set-Claims //= (boot-count-label => uint)
The "bootseed" claim contains a value created at system boot time that allows differentiation of attestation reports from different boot sessions of a particular entity (e.g., a certain UEID).
「ブートシード」クレームには、特定のエンティティのさまざまなブートセッション（特定のUEIDなど）からの証明レポートの区別を可能にするシステムブート時間に作成された値が含まれています。
This value is usually public. It is not a secret and MUST NOT be used for any purpose where a secret seed is needed, such as seeding a random number generator.
この値は通常公開されます。それは秘密ではなく、乱数ジェネレーターのシードなど、秘密の種が必要な目的に使用してはなりません。
There are privacy considerations for this claim; see Section 8.3.
この主張にはプライバシーに関する考慮事項があります。セクション8.3を参照してください。
$$Claims-Set-Claims //= (boot-seed-label => binary-data)
The "dloas" claim conveys one or more Digital Letters of Approval (DLOAs). A DLOA [DLOA] is a document that describes a certification that an entity has received. Examples of certifications represented by a DLOA include those issued by GlobalPlatform [GP-Example] and those based on Common Criteria [CC-Example]. The DLOA is unspecific to any particular certification type or those issued by any particular organization.
「Dloas」クレームは、1つ以上のデジタルレターの承認文字（DLOA）を伝えます。DLOA [DLOA]は、エンティティが受け取った認証を説明する文書です。DLOAで表される認定の例には、GlobalPlatform [GP-Example]によって発行されたものと、共通基準[CC-Example]に基づくものが含まれます。DLOAは、特定の認定タイプまたは特定の組織が発行したタイプには非特異的です。
This claim is typically issued by a verifier, not an attester. Verifiers MUST NOT issue this claim unless the entity has received the certification indicated by the DLOA.
このクレームは通常、弁護士によって発行されます。Verifiersは、エンティティがDLOAによって示された認証を受け取っていない限り、この請求を発行してはなりません。
This claim MAY contain more than one DLOA. If multiple DLOAs are present, verifiers MUST NOT issue this claim unless the entity has received all of the certifications.
このクレームには複数のDLOAが含まれている場合があります。複数のDLOAが存在する場合、事業体がすべての認定を受け取っていない限り、検証者はこの請求を発行してはなりません。
DLOA documents are always fetched from a registrar that stores them. This claim contains several data items used to construct a Uniform Resource Locator (URL) for fetching the DLOA from the particular registrar.
DLOAドキュメントは、それらを保存するレジストラから常に取得されます。このクレームには、特定のレジストラからDLOAを取得するためのユニフォームリソースロケーター（URL）を構築するために使用されるいくつかのデータ項目が含まれています。
This claim MUST be encoded as an array with either two or three elements. The first element MUST be the URL for the registrar. The second element MUST be a platform label indicating which platform was certified. If the DLOA applies to an application, then the third element is added, which MUST be an application label. The method of constructing the registrar URL, platform label, and possibly application label is specified in [DLOA].
このクレームは、2つまたは3つの要素を持つ配列としてエンコードする必要があります。最初の要素は、レジストラのURLでなければなりません。2番目の要素は、どのプラットフォームが認定されたかを示すプラットフォームラベルでなければなりません。DLOAがアプリケーションに適用される場合、3番目の要素が追加されます。これはアプリケーションラベルでなければなりません。レジストラURL、プラットフォームラベル、および場合によってはアプリケーションラベルを構築する方法は、[DLOA]で指定されています。
The retriever of a DLOA MUST follow the recommendation in [DLOA] and use Transport Layer Security (TLS) or some other means to be sure the DLOA registrar they are accessing is authentic. The platform and application labels in the claim indicate the correct DLOA for the entity.
DLOAの取得者は、[DLOA]の推奨に従い、輸送層のセキュリティ（TLS）またはその他の手段を使用して、アクセスしているDLOAレジストラが本物であることを確認する必要があります。クレームのプラットフォームとアプリケーションのラベルは、エンティティの正しいDLOAを示しています。
$$Claims-Set-Claims //= (
dloas-label => [ + dloa-type ]
)
dloa-type = [
dloa_registrar: general-uri
dloa_platform_label: text
? dloa_application_label: text
]
The "manifests" claim contains descriptions of software present on the entity. These manifests are installed on the entity when the software is installed or are created as part of the installation process. Installation is anything that adds software to the entity, possibly factory installation, the user installing elective applications, and so on. The defining characteristic of a manifest is that it is created by the software manufacturer. The purpose of this claim is to relay unmodified manifests to the verifier and possibly to the relying party.
「マニフェスト」クレームには、エンティティに存在するソフトウェアの説明が含まれています。これらのマニフェストは、ソフトウェアがインストールされている場合、またはインストールプロセスの一部として作成されるときにエンティティにインストールされます。インストールは、エンティティにソフトウェアを追加するもの、場合によっては工場のインストール、ユーザーが選択的アプリケーションをインストールするなどのものです。マニフェストの特徴は、ソフトウェアメーカーによって作成されていることです。この主張の目的は、変更されていないマニフェストを検証者に、そして場合によっては頼る当事者に伝えることです。
Some manifests are signed by their software manufacturer independently, and some are not because either they do not support signing or the manufacturer chose not to sign them. For example, a CoSWID might be signed independently before it is included in an EAT. When signed manifests are put into an EAT, the manufacturer's signature SHOULD be included even though an EAT's signature will also cover the manifest. This allows the receiver to directly verify the manufacturer-originated manifest.
いくつかのマニフェストは、ソフトウェアメーカーによって独立して署名されていますが、一部のマニフェストは、署名をサポートしていないか、メーカーが署名しないことを選択したからではありません。たとえば、Coswidは、食事に含まれる前に独立して署名される場合があります。署名されたマニフェストが食事に入れられる場合、食事の署名もマニフェストをカバーしているにもかかわらず、メーカーの署名を含める必要があります。これにより、受信者はメーカーによって発生したマニフェストを直接検証できます。
This claim allows multiple manifest formats. For example, the manifest may be a CBOR-encoded CoSWID, an XML-encoded Software Identification (SWID) tag, or other. Identification of the type of manifest is always by a Constrained Application Protocol (CoAP) Content-Format identifier [RFC7252]. If there is no CoAP identifier registered for a manifest format, one MUST be registered.
このクレームは、複数のマニフェスト形式を許可します。たとえば、マニフェストは、Cborエンコードコスウィッド、XMLエンコードソフトウェア識別（SWID）タグ、またはその他である場合があります。マニフェストのタイプの識別は、常に制約付きアプリケーションプロトコル（COAP）コンテンツフォーマット識別子[RFC7252]によるものです。マニフェスト形式に登録されているCOAP識別子がない場合は、登録する必要があります。
This claim MUST be an array of one or more manifests. Each manifest in the claim MUST be an array of two. The first item in the array of two MUST be a CoAP Content-Format identifier. The second item is MUST be the actual manifest.
この主張は、1つ以上のマニフェストの配列でなければなりません。クレームの各マニフェストは、2つの配列でなければなりません。2つの配列の最初の項目は、COAPコンテンツフォーマット識別子でなければなりません。2番目の項目は、実際のマニフェストである必要があります。
In JSON-encoded tokens, the manifest, whatever encoding it is, MUST be placed in a text string. When a non-text encoded manifest such as a CBOR-encoded CoSWID is put in a JSON-encoded token, the manifest MUST be base64 encoded.
JSONエンコードトークンでは、マニフェストは、それが何であれ、テキスト文字列に配置する必要があります。cborエンコードされたコスウィッドなどの非テキストエンコードされたマニフェストがJSONエンコードされたトークンに入れられる場合、マニフェストはbase64エンコードする必要があります。
This claim allows for multiple manifests in one token since multiple software packages are likely to be present. The multiple manifests MAY be of different encodings. In some cases, EAT submodules may be used instead of the array structure in this claim for multiple manifests.
複数のソフトウェアパッケージが存在する可能性が高いため、この主張は1つのトークンに複数のマニフェストを許可します。複数のマニフェストは、異なるエンコーディングのものである可能性があります。場合によっては、複数のマニフェストのこのクレームの配列構造の代わりに、食事サブモジュールを使用することがあります。
A CoSWID manifest MUST be a payload CoSWID, not an evidence CoSWID. These are defined in [RFC9393].
Coswidマニフェストは、証拠コスウィッドではなく、ペイロードコスウィッドでなければなりません。これらは[RFC9393]で定義されています。
This claim is extensible for use of manifest formats beyond those mentioned in this document. No particular manifest format is preferred. For manifest interoperability, an EAT profile, as defined in Section 6, should be used to specify which manifest format(s) is allowed.
この主張は、このドキュメントに記載されているものを超えたマニフェスト形式の使用に拡張可能です。特定のマニフェスト形式は推奨されません。マニフェストの相互運用性の場合、セクション6で定義されているEATプロファイルを使用して、どのマニフェスト形式が許可されているかを指定する必要があります。
$$Claims-Set-Claims //= (
manifests-label => manifests-type
)
manifests-type = [+ manifest-format]
manifest-format = [
content-type: coap-content-format,
content-format: JC< $manifest-body-json,
$manifest-body-cbor >
]
$manifest-body-cbor /= bytes .cbor untagged-coswid
$manifest-body-json /= base64-url-text
The "measurements" claim contains descriptions, lists, evidence, or measurements of the software that exists on the entity or on any other measurable subsystem of the entity (e.g., hash of sections of a file system or non-volatile memory). The defining characteristic of this claim is that its contents are created by processes on the entity that inventory, measure, or otherwise characterize the software on the entity. The contents of this claim do not originate from the manufacturer of the measurable subsystem (e.g., developer of a software library).
「測定」クレームには、エンティティまたはエンティティのその他の測定可能なサブシステム（ファイルシステムまたは非揮発性メモリのセクションのハッシュ）に存在するソフトウェアの説明、リスト、証拠、または測定が含まれています。この主張の特徴は、その内容が、エンティティ上のソフトウェアを在庫、測定、または特徴づけるエンティティ上のプロセスによって作成されるということです。このクレームの内容は、測定可能なサブシステムの製造業者（たとえば、ソフトウェアライブラリの開発者）に由来するものではありません。
This claim can be a CoSWID [RFC9393]. When the CoSWID format is used, it MUST be an evidence CoSWID, not a payload CoSWID.
この主張はコスウィッド[RFC9393]になる可能性があります。Coswid形式を使用する場合、それはペイロードCoswidではなく、Coswidの証拠でなければなりません。
Formats other than CoSWID MAY be used. The format is identified by a CoAP Content-Format identifier, which is the same for the "manifests" claim in Section 4.2.15.
Coswid以外の形式を使用できます。この形式は、COAPコンテンツフォーマット識別子によって識別されます。これは、セクション4.2.15の「マニフェスト」請求で同じです。
$$Claims-Set-Claims //= (
measurements-label => measurements-type
)
measurements-type = [+ measurements-format]
measurements-format = [
content-type: coap-content-format,
content-format: JC< $measurements-body-json,
$measurements-body-cbor >
]
$measurements-body-cbor /= bytes .cbor untagged-coswid
$measurements-body-json /= base64-url-text
The "measres" claim is a general-purpose structure for reporting the comparison of measurements to expected reference values. This claim provides a simple standard way to report the result of a comparison as a success, a failure, not run, or absent.
「測定」クレームは、測定値と予想される参照値を比較することを報告するための汎用構造です。このクレームは、比較の結果を成功、失敗、実行しない、または欠席として報告する簡単な標準的な方法を提供します。
It is the nature of measurement systems to be specific to the operating system, software, and hardware of the entity that is being measured. It is not possible to standardize what is measured and how it is measured across platforms, OSes, software, and hardware. The recipient must obtain the information about what was measured and what it indicates for the characterization of the security of the entity from the provider of the measurement system. What this claim provides is a standard way to report basic success or failure of the measurement. In some use cases, it is valuable to know if measurements succeeded or failed in a general way even if the details of what was measured are not characterized.
測定されているエンティティのオペレーティングシステム、ソフトウェア、およびハードウェアに固有の測定システムの性質です。測定された内容と、プラットフォーム、OSE、ソフトウェア、ハードウェア間でそれがどのように測定されるかを標準化することはできません。受信者は、測定されたものと、測定システムのプロバイダーからのエンティティのセキュリティの特性評価のために何を示すかについての情報を取得する必要があります。この主張が提供するのは、測定の基本的な成功または失敗を報告する標準的な方法です。一部のユースケースでは、測定が特徴付けられていない場合でも、測定が成功または一般的な方法で成功または失敗したかどうかを知ることは価値があります。
This claim MAY be generated by the verifier and sent to the relying party. For example, it could be the results of the verifier comparing the contents of the "measurements" claim (Section 4.2.16) to reference values.
このクレームは、検証者によって生成され、頼りになる当事者に送られる場合があります。たとえば、「測定」クレーム（セクション4.2.16）の内容を参照値と比較する検証者の結果である可能性があります。
This claim MAY also be generated on the entity if the entity has the ability for one subsystem to measure and evaluate another subsystem. For example, a TEE might have the ability to measure the software of the rich OS and may have the reference values for the rich OS.
エンティティが1つのサブシステムが別のサブシステムを測定および評価する能力を持っている場合、このクレームはエンティティで生成される場合があります。たとえば、TEEには、リッチOSのソフトウェアを測定する機能があり、リッチOSの参照値がある場合があります。
Within an entity, attestation target, or submodule, multiple results can be reported. For example, it may be desirable to report the results for measurements of the file system, chip configuration, installed software, running software, and so on.
エンティティ、証明ターゲット、またはサブモジュール内で、複数の結果を報告できます。たとえば、ファイルシステム、チップ構成、インストールされたソフトウェア、ランニングソフトウェアなどの測定の結果を報告することが望ましい場合があります。
Note that this claim is not for reporting the overall result of a verifier. It is solely for reporting the result of comparison to reference values.
この主張は、検証剤の全体的な結果を報告するためではないことに注意してください。これは、参照値との比較の結果を報告するためだけです。
An individual measurement result (individual-result) is an array consisting of two elements, an identifier of the measurement (result-id), and an enumerated type of the result (result). Different measurement systems will measure different things and perhaps measure the same thing in different ways. It is up to each measurement system to define identifiers (result-id) for the measurements it reports.
個々の測定結果（個体反応）は、2つの要素、測定の識別子（結果-ID）と列挙されたタイプの結果（結果）で構成される配列です。異なる測定システムは、さまざまなものを測定し、おそらく同じことをさまざまな方法で測定します。報告する測定の識別子（結果-ID）を定義するのは、各測定システム次第です。
Each individual measurement result is part of a group that may contain many individual results. Each group has a text string that names it, typically the name of the measurement scheme or system.
個々の測定結果は、多くの個別の結果を含む可能性のあるグループの一部です。各グループには、名前のテキスト文字列、通常は測定スキームまたはシステムの名前です。
The claim itself consists of one or more groups.
クレーム自体は、1つ以上のグループで構成されています。
The values for the results enumerated type are as follows:
列挙型の結果の値は次のとおりです。
1 -- comparison success:
1-比較成功：
The comparison to reference values was successful.
参照値との比較は成功しました。
2 -- comparison failure:
2-比較障害：
The comparison was completed but did not compare correctly to the reference values.
比較は完了しましたが、参照値と正しく比較されませんでした。
3 -- comparison not run:
3-比較は実行されません：
The comparison was not run. This includes error conditions such as running out of memory.
比較は実行されませんでした。これには、メモリの不足などのエラー条件が含まれます。
4 -- measurement absent:
4-測定の欠如：
The particular measurement was not available for comparison.
特定の測定は比較には利用できませんでした。
$$Claims-Set-Claims //= (
measurement-results-label =>
[ + measurement-results-group ] )
measurement-results-group = [
measurement-system: tstr,
measurement-results: [ + individual-result ]
]
individual-result = [
result-id: tstr / binary-data,
result: result-type,
]
result-type = comparison-success /
comparison-fail /
comparison-not-run /
measurement-absent
comparison-success = JC< "success", 1 >
comparison-fail = JC< "fail", 2 >
comparison-not-run = JC< "not-run", 3 >
measurement-absent = JC< "absent", 4 >
Some devices are complex and have many subsystems. A mobile phone is a good example. It may have subsystems for communications (e.g., Wi-Fi and cellular), low-power audio and video playback, and multiple security-oriented subsystems such as a TEE and a Secure Element. The claims for a subsystem can be grouped together in a submodule.
一部のデバイスは複雑で、多くのサブシステムがあります。携帯電話は良い例です。通信用サブシステム（Wi-Fiやセルラーなど）、低電力オーディオおよびビデオ再生、およびティーや安全な要素などの複数のセキュリティ指向サブシステムがある場合があります。サブシステムのクレームは、サブモジュールにグループ化できます。
Submodules may be used in either evidence or attestation results.
サブモジュールは、証拠または証明の結果のいずれかで使用できます。
Because system architecture will vary greatly from use case to use case, there are no set requirements for what a submodule represents either in evidence or in attestation results. Profiles (Section 6) may wish to impose requirements. An attester that outputs evidence with submodules should document the semantics it associates with particular submodules for the verifier. Likewise, a verifier that outputs attestation results with submodules should document the semantics it associates with the submodules for the relying party.
システムアーキテクチャは、ユースケースごとにユースケースまで大きく異なるため、サブモジュールが証拠または証明の結果のいずれかを表すものについて設定された要件はありません。プロファイル（セクション6）は、要件を課したい場合があります。サブモジュールを使用して証拠を出力する指標は、検証剤の特定のサブモジュールに関連するセマンティクスを文書化する必要があります。同様に、サブモジュールを使用して認証結果を出力する検証剤は、依存者のためにサブモジュールに関連するセマンティクスを文書化する必要があります。
A submodule claim is a map that holds some number of submodules. Each submodule is named by its label in the submodule claim map. The value of each entry in a submodule may be a Claims-Set, nested token, or Detached-Submodule-Digest. This allows for the submodule to serve as its own attester or not and allows for claims for each submodule to be represented directly or indirectly, i.e., detached.
サブモジュールのクレームは、いくつかのサブモジュールを保持するマップです。各サブモジュールは、サブモジュールクレームマップのラベルによって名前が付けられています。サブモジュール内の各エントリの値は、クレームセット、ネストされたトークン、またはデタッチドサブモジュールダイジストである場合があります。これにより、サブモジュールが独自の攻撃として機能するかどうかにかかわらず、各サブモジュールの請求を直接または間接的に表現できます。
A submodule may include a submodule, allowing for arbitrary levels of nesting. However, submodules do not inherit anything from the containing token and must explicitly include all claims. Submodules may contain claims that are present in any surrounding token or submodule. For example, the top level of the token may have a UEID, a submodule may have a different UEID, and a further subordinate submodule may also have a UEID.
サブモジュールには、任意のレベルのネストを可能にするサブモジュールが含まれる場合があります。ただし、サブモジュールは、含まれるトークンから何も継承せず、すべてのクレームを明示的に含める必要があります。サブモジュールには、周囲のトークンまたはサブモジュールに存在するクレームが含まれている場合があります。たとえば、トークンのトップレベルにはUEIDがあり、サブモジュールには異なるUEIDがあり、さらに下位サブモジュールにもUEIDがあります。
The following subsections define the three types for representing submodules:
次のサブセクションでは、サブモジュールを表すための3つのタイプを定義します。
* A submodule Claims-Set
* サブモジュールクレームセット
* The digest of a detached Claims-Set
* 分離されたクレームセットのダイジェスト
* A nested token, which can be any EAT
* ネストされたトークン
The Submodule type and Nested-Token type definitions vary with the type of encoding. The definitions for CBOR-encoded EATs are as follows:
サブモジュールタイプとネストされたトークンタイプの定義は、エンコードのタイプによって異なります。cborエンコードの食事の定義は次のとおりです。
Nested-Token = CBOR-Nested-Token
CBOR-Nested-Token =
JSON-Token-Inside-CBOR-Token /
CBOR-Token-Inside-CBOR-Token
CBOR-Token-Inside-CBOR-Token = bstr .cbor $CBOR-Tagged-Token
JSON-Token-Inside-CBOR-Token = tstr
$$Claims-Set-Claims //= (submods-label => { + text => Submodule })
Submodule = Claims-Set / CBOR-Nested-Token /
Detached-Submodule-Digest
The Submodule and Nested-Token definitions for JSON-encoded EATs are as below. The definitions are necessarily different than CBOR because JSON has no tag mechanism and no byte-string type to help indicate that the nested token is CBOR.
JSONエンコードの食事のサブモジュールとネストされたトークンの定義は以下のとおりです。JSONにはタグメカニズムがなく、ネストされたトークンがCBORであることを示すのに役立つバイトストリングタイプがないため、定義は必然的にCBORとは異なります。
Nested-Token = JSON-Selector
JSON-Selector = $JSON-Selector
$JSON-Selector /= [type: "JWT", nested-token: JWT-Message]
$JSON-Selector /= [type: "CBOR", nested-token:
CBOR-Token-Inside-JSON-Token]
$JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle]
$JSON-Selector /= [type: "DIGEST", nested-token:
Detached-Submodule-Digest]
CBOR-Token-Inside-JSON-Token = base64-url-text
$$Claims-Set-Claims //= (submods-label => { + text => Submodule })
Submodule = Claims-Set / JSON-Selector
The Detached-Submodule-Digest type is defined as follows:
分離されたサブモジュールダイジェストタイプは、次のように定義されています。
Detached-Submodule-Digest = [
hash-algorithm : text / int,
digest : binary-data
]
Nested tokens can be one of three types as defined in this document or types that are standardized in subsequent documents (e.g., [UCCS]). Nested tokens are the only mechanism by which JSON can be embedded in CBOR and vice versa.
ネストされたトークンは、このドキュメントで定義されている3つのタイプのいずれかまたは後続のドキュメント（[UCCS]など）で標準化されているタイプの1つです。ネストされたトークンは、JSONをCBORに埋め込み、その逆にできる唯一のメカニズムです。
The addition of further types is accomplished by augmenting the $CBOR-Tagged-Token socket or the $JSON-Selector socket.
さらなるタイプの追加は、$ CBORタグ付きトークンソケットまたは$ JSONセレクターソケットを増強することで実現されます。
When decoding a JSON-encoded EAT, the type of submodule is determined as follows. A JSON object indicates that the submodule is a Claims-Set. In all other cases, it is a JSON-Selector, which is an array of two elements that indicates whether the submodule is a nested token or a Detached-Submodule-Digest. The first element in the array indicates the type present in the second element. If the value is "JWT", "CBOR", "BUNDLE", or future-standardized token types, e.g., see [UCCS], the submodule is a nested token of the indicated type, i.e., JWT-Message, CBOR-Token-Inside-JSON-Token, Detached-EAT-Bundle, or a future type. If the value is "DIGEST", the submodule is a Detached-Submodule-Digest. Any other value indicates a standardized extension to this specification.
JSONエンコードの食事をデコードするとき、サブモジュールのタイプは次のように決定されます。JSONオブジェクトは、サブモジュールがクレームセットであることを示します。他のすべての場合において、それはJSONセレクターであり、サブモジュールがネストされたトークンであるか、分離したサブモジュールの消毒であるかを示す2つの要素の配列です。配列の最初の要素は、2番目の要素に存在する型を示します。値が「jwt」、「cbor」、「bundle」、または将来の標準化されたトークンタイプの場合、たとえば[uccs]を参照する場合、サブモジュールは、示されたタイプのネストされたトークン、すなわち、cbor-token-inside-json-token、depached-eat bundle、またはfuture ypeatsです。値が「ダイジェスト」の場合、サブモジュールは分離したサブモジュールダイジェストです。その他の値は、この仕様の標準化された拡張機能を示しています。
When decoding a CBOR-encoded EAT, the CBOR item type indicates the type of the submodule as follows. A map indicates a CBOR-encoded submodule Claims-Set. An array indicates a CBOR-encoded Detached-Submodule-Digest. A byte string indicates a CBOR-encoded CBOR-Nested-Token. A text string indicates a JSON-encoded JSON-Selector. Where JSON-Selector is used in a CBOR-encoded EAT, the "DIGEST" type and corresponding Detached-Submodule-Digest type MUST NOT be used.
CBORエンコードのEATをデコードするとき、CBORアイテムのタイプは、次のようにサブモジュールのタイプを示します。マップは、Cborエンコードされたサブモジュールクレームセットを示します。配列は、Cborエンコードされた分離型サブモジュールダイジストを示します。バイト文字列は、cborエンコードされたcborネストトークンを示します。テキスト文字列は、JSONエンコードされたJSONセレクターを示します。JSONセレクターがCBORエンコードのEATで使用されている場合、「ダイジェスト」タイプと対応する分離型サブモジュールダイジェストタイプを使用してはなりません。
The type of a CBOR-encoded nested token is always determined by the CBOR tag encountered after the byte string wrapping is removed in a CBOR-encoded enclosing token or after the base64 wrapping is removed in a JSON-encoded enclosing token.
cborエンコードネストされたトークンのタイプは、バイト文字列ラッピングがcborエンコードされた囲まれたトークンで削除された後、またはbase64ラッピングがJSONエンコードされたエンクロードトークンで削除された後に遭遇するCborタグによって常に決定されます。
The type of JSON-encoded nested token is always determined by the string name in JSON-Selector and is always "JWT", "BUNDLE", or a new name standardized outside this document for a further type (e.g., "UCCS"). This string name may also be "CBOR" to indicate the nested token is CBOR encoded.
JSONエンコードされたネストされたトークンのタイプは、常にJSONセレクターの文字列名によって決定され、常に「JWT」、「バンドル」、またはこのドキュメントの外側に標準化された新しい名前（例：「UCCS」）です。この文字列名は、ネストされたトークンがcborエンコードされていることを示す「cbor」でもあります。
"JWT":
「JWT」：
The second array item MUST be a JWT formatted according to [RFC7519].
2番目の配列アイテムは、[RFC7519]に従ってフォーマットされたJWTでなければなりません。
"CBOR":
「Cbor」：
The second array item MUST be some base64url-encoded CBOR that is a tag, typically a CWT or CBOR-encoded detached EAT bundle.
2番目のアレイアイテムは、タグであるBase64UrlエンコードCBOR、通常はCWTまたはCBORエンコードの分離した食事バンドルでなければなりません。
"BUNDLE":
"バンドル"：
The second array item MUST be a JSON-encoded detached EAT bundle as defined in this document.
2番目のアレイアイテムは、このドキュメントで定義されているJSONエンコードデタッチドイートバンドルでなければなりません。
"DIGEST":
"ダイジェスト"：
The second array item MUST be a JSON-encoded Detached-Submodule-Digest as defined in this document.
2番目の配列アイテムは、このドキュメントで定義されているように、JSONエンコードの分離型サブモジュールダイジストでなければなりません。
As noted elsewhere, additional EAT types may be defined by a Standards Action. New type specifications MUST address the integration of the new type into the submodule claim type for submodules.
他の場所で述べているように、追加のEATタイプは、標準アクションによって定義される場合があります。新しいタイプの仕様は、サブモジュールのサブモジュールクレームタイプへの新しいタイプの統合に対処する必要があります。
The Claims-Set type provides a means of representing claims from a submodule that does not have its own attesting environment, i.e., it has no keys distinct from the attester producing the surrounding token. Claims are represented as a Claims-Set. Submodule claims represented in this way are secured by the same mechanism as the enclosing token (e.g., it is signed by the same attestation key).
クレームセットタイプは、独自の証明環境を持たないサブモジュールからのクレームを表す手段を提供します。つまり、周囲のトークンを生成するアテスターとは異なるキーはありません。クレームは、クレームセットとして表されます。この方法で表されるサブモジュールのクレームは、囲まれたトークンと同じメカニズムによって保護されます（たとえば、同じ証明キーによって署名されます）。
The encoding of a submodule Claims-Set MUST be the same as the encoding of the surrounding EAT, e.g., all submodule Claims-Sets in a CBOR-encoded token must be CBOR encoded.
サブモジュールクレームセットのエンコードは、周囲の食事のエンコードと同じでなければなりません。
The Detached-Submodule-Digest type is similar to a submodule Claims-Set, except a digest of the Claims-Set is included in the claim with the Claims-Set contents conveyed separately. The separately conveyed Claims-Set is called a "detached claims set". The input to the digest algorithm is the CBOR or the JSON-encoded Claims-Set for the submodule. There is no byte string wrapping or base64 encoding.
分離されたサブモジュールダイジェストタイプは、クレームセットのダイジェストが個別に伝えられたクレームセットの内容を含むクレームに含まれる場合を除き、サブモジュールクレームセットに似ています。個別に伝えられたクレームセットは、「デタッチされたクレームセット」と呼ばれます。ダイジェストアルゴリズムへの入力は、サブモジュールのCBORまたはJSONエンコードのクレームセットです。バイト文字列ラッピングまたはbase64エンコードはありません。
The data type for this type of submodule is an array consisting of two data items: an algorithm identifier and a byte string containing the digest. The hash algorithm identifier is always from the "COSE Algorithms" registry [IANA.COSE.Algorithms]. Either the integer or string identifier may be used. The hash algorithm identifier is never from any other algorithm registry.
このタイプのサブモジュールのデータ型は、アルゴリズム識別子とダイジェストを含むバイト文字列の2つのデータ項目で構成される配列です。ハッシュアルゴリズム識別子は、常に「COSEアルゴリズム」レジストリ[iana.cose.algorithms]からのものです。整数または文字列識別子のいずれかを使用できます。ハッシュアルゴリズム識別子は、他のアルゴリズムレジストリからのものではありません。
A detached EAT bundle, as described in Section 5, may be used to convey detached claims sets and the EAT containing the corresponding detached digests. However, EAT does not require the use of a detached EAT bundle. Any other protocols may be used to convey detached claims sets and the EAT containing the corresponding detached digests. If detached Claims-Sets are modified in transit, then validation can fail.
セクション5で説明されているように、分離したEATバンドルは、分離したクレームセットと、対応する分離した消化物を含むEATを伝えるために使用できます。ただし、Eatは、剥離したEat Bundleを使用する必要はありません。他のプロトコルを使用して、分離されたクレームセットと、対応する分離された消化物を含むEATを伝えることができます。輸送中に分離されたクレームセットが変更された場合、検証が失敗する可能性があります。
The CBOR-Nested-Token and JSON-Selector types provide a means of representing claims from a submodule that has its own attesting environment, i.e., it has keys distinct from the attester producing the surrounding token. Claims are represented in a signed EAT token.
Cbor-Nested-TokenおよびJSONセレクターのタイプは、独自の証明環境を持つサブモジュールからのクレームを表す手段を提供します。つまり、周囲のトークンを生成するアテスターとは異なるキーがあります。クレームは、署名されたEatトークンに表されます。
Inclusion of a signed EAT as a claim cryptographically binds the EAT to the surrounding token. If it was conveyed in parallel with the surrounding token, there would be no such binding and attackers could substitute a good attestation from another device for the attestation of an errant subsystem.
署名された食事をクレームとして含めることは、暗号化された食事を周囲のトークンに結合します。それが周囲のトークンと並行して伝えられた場合、そのような拘束力のある拘束力はなく、攻撃者は誤ったサブシステムの証明のために別のデバイスから良い証明を代用することができます。
A nested token need not use the same encoding as the enclosing token. This enables composite devices to be built without regards to the encoding used by components. Thus, a CBOR-encoded EAT can have a JSON-encoded EAT as a nested token and vice versa.
ネストされたトークンは、囲まれたトークンと同じエンコードを使用する必要はありません。これにより、コンポーネントが使用するエンコードに関しては、複合デバイスを構築できます。したがって、cborエンコードの食事は、ゼンエンコードされた食事をネストされたトークンとして持つことができ、その逆も同様です。
The claims in this section provide metadata about the token they occur in. They do not describe the entity. They may appear in evidence or attestation results.
このセクションの主張は、それらが発生するトークンに関するメタデータを提供します。彼らはエンティティを説明していません。それらは、証拠または証明の結果に表示される場合があります。
The "iat" claim defined in CWT and JWT is used to indicate the date-of-creation of the token, the time at which the claims are collected and the token is composed and signed.
CWTおよびJWTで定義された「IAT」クレームは、トークンの作成日、クレームが収集され、トークンが構成および署名される時間を示すために使用されます。
The data for some claims may be held or cached for some period of time before the token is created. This period may be long, even days. Examples are measurements taken at boot or a geographic position fix taken the last time a satellite signal was received. There are individual timestamps associated with these claims to indicate their age is older than the "iat" timestamp.
いくつかのクレームのデータは、トークンが作成される前に、しばらくの間保持またはキャッシュされる場合があります。この期間は長い日でもあります。例は、ブーツで撮影された測定または地理的位置修正で、最後に衛星信号を受信したときに撮影されました。これらの主張に関連する個々のタイムスタンプがあり、年齢が「IAT」タイムスタンプよりも古いことを示すことがあります。
CWT allows the use of floating-point for this claim, whereas EAT disallows the use of floating-point. An EAT token MUST NOT contain an "iat" claim in floating-point format. Any recipient of a token with a floating-point format "iat" claim MUST consider it an error.
CWTは、この主張に浮動小数点を使用することを許可しますが、Eatは浮動小数点の使用を許可しません。EATトークンには、浮動小数点形式で「IAT」クレームを含めてはなりません。フローティングポイント形式の「IAT」クレームを持つトークンの受信者は、それをエラーと見なす必要があります。
A 64-bit integer representation of the CBOR epoch-based time [RFC8949] used by this claim can represent a range of +/- 500 billion years, so the only point of a floating-point timestamp is to have precession greater than one second. This is not needed for EAT.
このクレームで使用されるCBORエポックベースの時間[RFC8949]の64ビットの整数表現は、+/- 5000億年の範囲を表すことができるため、浮遊点のタイムスタンプの唯一のポイントは1秒を超える歳差運動をすることです。これは食事には必要ありません。
See Section 6 for the detailed description of an EAT profile.
EATプロフィールの詳細な説明については、セクション6を参照してください。
The "eat_profile" claim identifies an EAT profile by either a Uniform Resource Identifier (URI) or an OID. Typically, the URI will reference a document describing the profile. An OID is just a unique identifier for the profile. It may exist anywhere in the OID tree. There is no requirement that the named document be publicly accessible. The primary purpose of the "eat_profile" claim is to uniquely identify the profile even if it is a private profile.
「EAT_Profile」クレームは、均一なリソース識別子（URI）またはOIDのいずれかによってEATプロファイルを識別します。通常、URIはプロファイルを説明するドキュメントを参照します。OIDは、プロファイルのユニークな識別子です。OIDツリーのどこにでも存在する場合があります。指定されたドキュメントに公開されているという要件はありません。「EAT_Profile」クレームの主な目的は、たとえそれがプライベートプロファイルであっても、プロファイルを一意に識別することです。
The OID is always absolute and never relative.
OIDは常に絶対的であり、決して相対的ではありません。
See Section 7.2.1 for OID and URI encoding.
OIDおよびURIエンコーディングについては、セクション7.2.1を参照してください。
$$Claims-Set-Claims //= (profile-label => general-uri / general-oid)
EATs may be employed in the context of several different applications. The "intuse" claim provides an indication to an EAT consumer about the intended usage of the token. This claim can be used as a way for an application using EAT to internally distinguish between different ways it utilizes EAT. The possible values are in the "Entity Attestation Token (EAT) Intended Uses" registry defined in Section 10.5.
いくつかの異なるアプリケーションのコンテキストでは、食事が採用される場合があります。「intuse」クレームは、トークンの意図した使用について食事消費者に兆候を提供します。このクレームは、EATを使用して、EATを利用するさまざまな方法を内部的に区別するためのアプリケーションの方法として使用できます。考えられる値は、セクション10.5で定義されているレジストリを「エンティティ証明トークン（EAT）使用する」レジストリにあります。
$$Claims-Set-Claims //= ( intended-use-label => intended-use-type )
intended-use-type = JC< text, int>
A detached EAT bundle is a message to convey an EAT plus detached claims sets secured by that EAT. It is a top-level message like a CWT or JWT. It can occur in any place that a CWT or JWT occurs, for example, as a submodule nested token as defined in Section 4.2.18.3.
分離したEATバンドルは、Eatによって保護されたEat Plus Detached Claices Setsを伝えるためのメッセージです。これは、CWTやJWTのようなトップレベルのメッセージです。たとえば、セクション4.2.18.3で定義されているように、サブモジュールネストトークンとして、CWTまたはJWTが発生する場所で発生する可能性があります。
A detached EAT bundle may be either CBOR or JSON encoded.
分離した食事バンドルは、CBORまたはJSONエンコードされている場合があります。
A detached EAT bundle consists of two parts.
分離したEATバンドルは、2つの部分で構成されています。
The first part is an encoded EAT that:
最初の部分は、エンコードされた食事です：
* MUST have at least one submodule that is a detached submodule digest as defined in Section 4.2.18.2
* セクション4.2.18.2で定義されているように、デタッチされたサブモジュールダイジェストである少なくとも1つのサブモジュールが必要です
* MAY be either CBOR or JSON encoded and does not have to be the same as the encoding of the bundle
* CBORまたはJSONエンコードのいずれかである可能性があり、バンドルのエンコードと同じである必要はありません
* MAY be a CWT, JWT, or some future-defined token type, but it MUST NOT be a detached EAT bundle
* CWT、JWT、または将来定義されたトークンタイプである可能性がありますが、戸建ての食事バンドルであってはなりません
* MUST be authenticity and integrity protected
* 真正性と整合性が保護されている必要があります
The same mechanism for distinguishing the type for nested token submodules is employed here.
ここでは、ネストされたトークンサブモジュールのタイプを区別するための同じメカニズムが採用されています。
The second part is a map/object that:
2番目の部分は、次のマップ/オブジェクトです。
* MUST be a Claims-Set
* クレームセットである必要があります
* MUST use the same encoding as the bundle
* バンドルと同じエンコードを使用する必要があります
* MUST be wrapped in a byte string when the encoding is CBOR and be base64url encoded when the encoding is JSON
* エンコーディングがCBORであるときにバイト文字列にラップする必要があり、エンコードがJSONであるときにbase64urlエンコードされる必要があります
For a CBOR-encoded detached EAT bundle, tag 602 can be used to identify it. The standard rules apply for use or non-use of a tag. When it is sent as a submodule, it is always sent as a tag to distinguish it from the other types of nested tokens.
Cborエンコードの分離した食事バンドルの場合、タグ602を使用してそれを識別できます。標準ルールは、タグの使用または不使用に適用されます。サブモジュールとして送信されると、他のタイプのネストされたトークンと区別するために、常にタグとして送信されます。
The digests of the detached claims sets are associated with detached Claims-Sets by label/name. It is up to the constructor of the detached EAT bundle to ensure that the names uniquely identify the detached claims sets. Since the names are used only in the detached EAT bundle, they can be very short, perhaps one byte.
分離されたクレームセットのダイジェストは、ラベル/名前による分離されたクレームセットに関連付けられています。名前が独立したクレームセットを独自に識別することを保証するために、剥離したEat Bundleのコンストラクター次第です。名前は分離したEat Bundleでのみ使用されるため、非常に短く、おそらく1バイトになる可能性があります。
BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message
BUNDLE-Tagged-Message = #6.602(BUNDLE-Untagged-Message)
BUNDLE-Untagged-Message = Detached-EAT-Bundle
Detached-EAT-Bundle = [
main-token : Nested-Token,
detached-claims-sets: {
+ tstr => JC<json-wrapped-claims-set,
cbor-wrapped-claims-set>
}
]
json-wrapped-claims-set = base64-url-text
cbor-wrapped-claims-set = bstr .cbor Claims-Set
EAT makes normative use of CBOR, JSON, COSE, JOSE, CWT, and JWT. Most of these have implementation options to accommodate a range of use cases.
Eatは、CBOR、JSON、COSE、JOSE、CWT、およびJWTを規範的に使用します。これらのほとんどには、さまざまなユースケースに対応するための実装オプションがあります。
For example, COSE does not require a particular set of cryptographic algorithms so as to accommodate different usage scenarios and evolution of algorithms over time. Section 10 of [RFC9052] describes the profiling considerations for COSE.
たとえば、COSEでは、時間の経過とともにアルゴリズムのさまざまな使用シナリオと進化に対応するために、特定の暗号化アルゴリズムのセットを必要としません。[RFC9052]のセクション10では、COSEのプロファイリングに関する考慮事項について説明します。
The use of encryption is optional for both CWT and JWT. Section 8 of [RFC7519] describes implementation requirements and recommendations for JWT.
暗号化の使用は、CWTとJWTの両方でオプションです。[RFC7519]のセクション8では、JWTの実装要件と推奨事項について説明します。
Similarly, CBOR provides indefinite-length encoding, which is not commonly used but is valuable for very constrained devices. For EAT itself, in a particular use case some claims will be used and others will not. Section 4 of [RFC8949] describes serialization considerations for CBOR.
同様に、CBORは無期限の長さのエンコードを提供しますが、これは一般的には使用されていませんが、非常に制約されたデバイスにとって価値があります。それ自体を食べるために、特定のユースケースでは、いくつかの主張が使用され、他の主張は使用されません。[RFC8949]のセクション4では、CBORのシリアル化に関する考慮事項について説明します。
For example, a mobile phone use case may require the device make and model and may prohibit UEID and location for privacy reasons. The general EAT standard retains all this flexibility because it too is aimed to accommodate a broad range of use cases.
たとえば、携帯電話のユースケースでは、デバイスの作成とモデルが必要になる場合があり、プライバシー上の理由でUEIDと場所を禁止する場合があります。General Eat Standardは、幅広いユースケースに対応することも目的としているため、この柔軟性をすべて保持しています。
It is necessary to explicitly narrow these implementation options to guarantee interoperability. EAT chooses one general and explicit mechanism, the profile, to indicate the choices made for these implementation options for all aspects of the token.
相互運用性を保証するために、これらの実装オプションを明示的に絞り込む必要があります。Eatは、トークンのすべての側面のこれらの実装オプションに対して行われた選択を示すために、1つの一般的で明示的なメカニズムであるプロファイルを選択します。
Below is a list of the various issues that should be addressed by a profile.
以下は、プロファイルによって対処されるべきさまざまな問題のリストです。
The "eat_profile" claim in Section 4.3.2 provides a unique identifier for the profile a particular token uses.
セクション4.3.2の「EAT_Profile」請求は、特定のトークンが使用するプロファイルの一意の識別子を提供します。
A profile can apply to evidence, attestation results, or both.
プロファイルは、証拠、証明の結果、またはその両方に適用できます。
A profile document does not have to be in any particular format. It may be simple text, something more formal, or a combination of both.
プロファイルドキュメントは、特定の形式である必要はありません。それは単純なテキスト、よりフォーマルなもの、または両方の組み合わせかもしれません。
A profile may define, and possibly register, one or more new claims if needed. A profile may also reuse one or more already defined claims either as is or with values constrained to a subset or subrange.
必要に応じて、プロファイルが1つ以上の新しいクレームを定義し、登録する場合があります。また、プロファイルは、サブセットまたはサブレンジに制約されている値のいずれかで、すでに定義されている1つ以上の定義されたクレームを再利用する場合があります。
For a "full" profile, the receiver will be able to decode and verify every possible EAT sent when a sender and receiver both adhere to it. For a "partial" profile, there are still some protocol options left undecided.
「完全な」プロファイルの場合、受信者は、送信者と受信機が両方とも接着したときに送信されるすべての食事をデコードして確認できます。「部分的な」プロファイルの場合、未定のプロトコルオプションはまだあります。
For example, a profile that allows the use of signing algorithms by the sender that the receiver is not required to support is a partial profile. The sender might choose a signing algorithm that some receivers do not support.
たとえば、受信者がサポートする必要がないという送信者による署名アルゴリズムの使用を可能にするプロファイルは、部分的なプロファイルです。送信者は、一部の受信者がサポートしていない署名アルゴリズムを選択する場合があります。
Full profiles MUST be complete such that a complying receiver can decode, verify, and check for freshness for every EAT created by a complying sender. Full profiles do not need to require the receiver to fully handle every claim in an EAT from a complying sender. Profile specifications may assume the receiver has access to the necessary verification keys or may go into specific detail on the means to access verification keys.
遵守するレシーバーが、従う送信者によって作成されたすべての食事の新鮮さをデコード、検証、および確認できるように、完全なプロファイルを完全にする必要があります。完全なプロファイルでは、レシーバーが、従う送信者からの食事のすべてのクレームを完全に処理するように要求する必要はありません。プロファイルの仕様では、受信機が必要な検証キーにアクセスできるか、検証キーにアクセスする手段について特定の詳細に移行する場合があります。
The "eat_profile" claim MUST NOT be used to identify partial profiles.
「EAT_Profile」クレームを使用して、部分プロファイルを識別するために使用してはなりません。
While fewer profiles are preferable, sometimes several may be needed for a use case. One approach to handling variation in devices might be to define several full profiles that are variants of each other. It is relatively easy and inexpensive to define profiles as they do not have to be published on the Standards Track and do not have to be registered anywhere. For example, flexibility for post-quantum algorithms can be handled as follows. First, define a full profile for a set of non-post-quantum algorithms for current use. Then, when post-quantum algorithms are settled, define another full profile derived from the first.
より少ないプロファイルは望ましいものですが、ユースケースにはいくつかが必要になる場合があります。デバイスのバリエーションを処理する1つのアプローチは、互いにバリエーションであるいくつかの完全なプロファイルを定義することです。標準のトラックで公開する必要がなく、どこにでも登録する必要がないため、プロファイルを定義するのは比較的簡単で安価です。たとえば、質量後アルゴリズムの柔軟性は、次のように処理できます。最初に、現在使用するための一連の非ポストQuantumアルゴリズムの完全なプロファイルを定義します。次に、ポストカントムアルゴリズムが解決されると、最初から派生した別の完全なプロファイルを定義します。
The following is a list of EAT, CWT, JWT, COSE, JOSE, and CBOR options that a profile should address.
以下は、プロファイルが対処すべきEAT、CWT、JWT、COSE、JOSE、およびCBORオプションのリストです。
A profile should specify whether CBOR, JSON, or both may be sent. A profile should specify that the receiver can accept all encodings that the sender is allowed to send.
プロファイルは、CBOR、JSON、またはその両方を送信できるかどうかを指定する必要があります。プロファイルは、受信者が送信者が送信することを許可されているすべてのエンコーディングを受け入れることができることを指定する必要があります。
This should be specified for the top level and all nested tokens. For example, a profile might require all nested tokens to be of the same encoding of the top-level token.
これは、トップレベルとすべてのネストされたトークンに指定する必要があります。たとえば、プロファイルでは、すべてのネストされたトークンがトップレベルのトークンの同じエンコードであることを要求する場合があります。
A profile should specify whether definite-length arrays/maps, indefinite-length arrays/maps, or both may be sent. A profile should specify that the receiver accepts all length encodings that the sender is allowed to send.
プロファイルは、明確な長さの配列/マップ、無期限の長さの配列/マップ、または両方を送信するかを指定する必要があります。プロファイルは、受信者が送信者が送信することを許可されているすべての長さのエンコーディングを受け入れることを指定する必要があります。
This applies to individual EAT claims, CWT, and COSE parts of the implementation.
これは、個々のEATクレーム、CWT、および実装の一部に適用されます。
For most use cases, specifying that only definite-length arrays/maps may be sent is suitable.
ほとんどのユースケースでは、明確な長さの配列/マップのみが送信される可能性があることを指定することが適切です。
A profile should specify whether definite-length strings, indefinite-length strings, or both may be sent. A profile should specify that the receiver accepts all types of string encodings that the sender is allowed to send.
プロファイルは、明確な長さの文字列、無期限の長さの文字列、または両方を送信するかを指定する必要があります。プロファイルは、受信者が送信者が送信することが許可されているすべてのタイプの文字列エンコーディングを受け入れることを指定する必要があります。
For most use cases, specifying that only definite-length strings may be sent is suitable.
ほとんどのユースケースでは、明確な長さの文字列のみが送信される可能性があることを指定することが適切です。
A profile should specify whether or not CBOR preferred serialization must be sent or not. A profile should specify that the receiver accepts preferred and/or non-preferred serialization, so it will be able to accept anything sent by the sender.
プロファイルは、CBOR優先シリアル化を送信する必要があるかどうかを指定する必要があります。プロファイルは、受信者が優先されたおよび/または非優先シリアル化を受け入れることを指定する必要があるため、送信者から送信されたものを受け入れることができます。
The profile should specify whether the token should be a CWT tag or not.
プロファイルは、トークンがCWTタグであるかどうかを指定する必要があります。
When COSE protection is used, the profile should specify whether COSE tags are used or not. Note that [RFC8392] requires COSE tags be used in a CWT tag.
COSE保護を使用する場合、プロファイルはCOSEタグが使用されているかどうかを指定する必要があります。[RFC8392]は、CWTタグでCOSEタグを使用する必要があることに注意してください。
Often, a tag is unnecessary because the surrounding or carrying protocol identifies the object as an EAT.
多くの場合、周囲または運搬のプロトコルがオブジェクトをEATとして識別するため、タグは不要です。
COSE and JOSE have several options for signed, MACed, and encrypted messages. It may be an Unsecured JWT as described in Section 6 of [RFC7519]. It is possible to implement no protection, sign only, MAC only, sign then encrypt, and so on. All combinations allowed by COSE, JOSE, JWT, and CWT are allowed by EAT.
CoseとJoseには、署名、マケッド、暗号化されたメッセージのオプションがいくつかあります。[RFC7519]のセクション6で説明されているように、それは無担保JWTかもしれません。保護、署名のみ、Macのみ、署名、暗号化などを実装することはできません。COSE、Jose、JWT、およびCWTが許可するすべての組み合わせは、EATによって許可されています。
A profile should specify all signing, encryption, and MAC message formats that may be sent. For example, a profile might allow only COSE_Sign1 to be sent. As another example, a profile might allow COSE_Sign and COSE_Encrypt to be sent to carry multiple signatures for post quantum cryptography and to use encryption to provide confidentiality.
プロファイルは、送信される可能性のあるすべての署名、暗号化、およびMacメッセージ形式を指定する必要があります。たとえば、プロファイルを使用すると、COSE_SIGN1のみを送信できます。別の例として、プロファイルを使用すると、cose_signとcose_encryptを送信して、ポスト量子暗号化のために複数の署名を携帯し、暗号化を使用して機密性を提供することができます。
A profile should specify that the receiver accepts all message formats that are allowed to be sent.
プロファイルは、受信者が送信を許可されているすべてのメッセージ形式を受け入れることを指定する必要があります。
When both signing and encryption are allowed, a profile should specify which is applied first.
署名と暗号化の両方が許可されている場合、プロファイルは最初に適用されるものを指定する必要があります。
See "Application Profiling Considerations" (Section 10 of [RFC9052]) for a discussion on the selection of cryptographic algorithms and related issues.
暗号化アルゴリズムと関連する問題の選択に関する議論については、「アプリケーションプロファイリングに関する考慮事項」（[RFC9052]のセクション10）を参照してください。
The profile MAY require the protocol or system using EAT to provide an algorithm negotiation mechanism.
プロファイルは、アルゴリズムの交渉メカニズムを提供するためにETを使用してプロトコルまたはシステムを必要とする場合があります。
If not, the profile document should list a set of algorithms for each COSE and JOSE message type allowed by the profile per Section 6.3.6. The verifier should implement all of them. The attester may implement any of them it wishes, possibly just one for each message type.
そうでない場合、プロファイルドキュメントには、セクション6.3.6ごとにプロファイルによって許可される各COSEおよびJOSEメッセージタイプのアルゴリズムのセットをリストする必要があります。検証者はそれらすべてを実装する必要があります。Attesterは、それが望むそれらのいずれかを実装する場合があります。おそらく、メッセージタイプごとに1つだけです。
If detached submodule digests are used, the profile should address the determination of the hash algorithm(s) for the digests.
分離されたサブモジュールダイジェストを使用する場合、プロファイルはダイジェストのハッシュアルゴリズムの決定に対処する必要があります。
A profile should specify whether or not a detached EAT bundle (Section 5) can be sent. A profile should specify that a receiver accepts a detached EAT bundle if the sender is allowed to send it.
プロファイルは、分離したEATバンドル（セクション5）を送信できるかどうかを指定する必要があります。プロファイルは、送信者がそれを送信することを許可されている場合、レシーバーが分離したEATバンドルを受け入れることを指定する必要があります。
A profile should specify what must be sent to identify the verification, decryption, or MAC key(s). If multiple methods of key identification may be sent, a profile should require the receiver to support them all.
プロファイルは、検証、復号化、またはMacキーを特定するために送信する必要があるものを指定する必要があります。キー識別の複数の方法が送信される場合がある場合、プロファイルはレシーバーにすべてをサポートする必要があります。
Appendix F describes a number of methods for identifying verification keys. When encryption is used, there are further considerations. In some cases, key identification may be very simple, and in other cases, multiple components may be involved. For example, it may be simple through the use of a COSE key ID, or it may be complex through the use of an X.509 certificate hierarchy.
付録Fでは、検証キーを識別するための多くの方法について説明しています。暗号化を使用すると、さらに考慮されます。場合によっては、キーの識別は非常に単純である場合があり、他の場合には複数のコンポーネントが関与している場合があります。たとえば、COSEキーIDを使用することで簡単な場合もあれば、X.509証明書階層を使用することで複雑になる場合もあります。
While not always possible, a profile should specify, or make reference to, a full end-to-end specification for key identification. For example, a profile should specify in full detail how COSE key IDs are to be created, their life cycle, and such rather than just specifying that a COSE key ID be used. For example, a profile should specify the full details of an X.509 hierarchy including extension processing, algorithms allowed, and so on rather than just saying X.509 certificates are used.
常に可能ではありませんが、プロファイルは、キー識別のための完全なエンドツーエンド仕様を指定するか、参照する必要があります。たとえば、プロファイルは、COSEキーIDを使用するだけでなく、COSEキーIDの作成方法、ライフサイクルなどを詳細に指定する必要があります。たとえば、プロファイルは、X.509証明書を使用するだけでなく、拡張処理、許可されているアルゴリズムなどを含むX.509階層の詳細を指定する必要があります。
Similar to, or perhaps the same as, verification key identification, the profile may wish to specify how endorsements are to be identified. However, note that endorsement identification is optional, whereas key identification is not.
検証キー識別に似ている、またはおそらく同じように、プロファイルは、承認の識別方法を指定したい場合があります。ただし、承認の識別はオプションであるが、キーの識別はオプションではないことに注意してください。
Security considerations (see Section 9.3) require a mechanism to provide freshness. This may be the EAT nonce claim in Section 4.1 or some claim or mechanism defined outside this document. Several options are described in "Freshness" (Section 10 of [RFC9334]). A profile should specify which freshness mechanism or mechanisms can be used.
セキュリティ上の考慮事項（セクション9.3を参照）には、新鮮さを提供するメカニズムが必要です。これは、セクション4.1のEATノンセの請求またはこの文書の外部で定義されたいくつかの請求またはメカニズムである可能性があります。「鮮度」（[RFC9334]のセクション10）でいくつかのオプションが説明されています。プロファイルは、どの鮮度メカニズムまたはメカニズムを使用できるかを指定する必要があります。
If the EAT nonce claim is used, a profile should specify whether multiple nonces may be sent. If a profile allows multiple nonces to be sent, it should require the receiver to process multiple nonces.
EAT NonCeのクレームが使用されている場合、プロファイルは複数の非能力を送信できるかどうかを指定する必要があります。プロファイルで複数の非能力を送信できる場合、レシーバーが複数の非セースを処理する必要があります。
A profile may define new claims that are not defined in this document.
プロファイルは、このドキュメントで定義されていない新しいクレームを定義する場合があります。
This document requires that an EAT receiver must accept tokens with claims it does not understand. A profile for a specific use case may reverse this and allow a receiver to reject tokens with claims it does not understand. A profile for a specific use case may specify that specific claims are prohibited.
このドキュメントでは、EATレシーバーが理解できない主張でトークンを受け入れる必要があります。特定のユースケースのプロファイルはこれを逆転させ、レシーバーが理解できない主張でトークンを拒否できるようにすることができます。特定のユースケースのプロファイルは、特定のクレームが禁止されていることを指定する場合があります。
A profile for a specific use case may modify this and specify that some claims are required.
特定のユースケースのプロファイルはこれを変更し、いくつかのクレームが必要であることを指定する場合があります。
A profile may constrain the definition of claims that are defined in this document or elsewhere. For example, a profile may require the EAT nonce to be a certain length or the "location" claim to always include the altitude.
プロファイルは、このドキュメントまたは他の場所で定義されているクレームの定義を制約する場合があります。たとえば、プロファイルでは、Eat Nonceが特定の長さであるか、「場所」の請求が常に高度を含む必要がある場合があります。
Some claims are "pluggable" in that they allow different formats for their content. The "manifests" claim (Section 4.2.15) and the "measurements" claim (Section 4.2.16) are examples of this, allowing the use of CoSWID and other formats. A profile should specify which formats are allowed to be sent, with the assumption that the corresponding CoAP content types have been registered. A profile should require the receiver to accept all formats that are allowed to be sent.
一部の主張は、コンテンツに異なる形式を許可するという点で「プラグ可能」です。「マニフェスト」クレーム（セクション4.2.15）と「測定」クレーム（セクション4.2.16）は、CosWidおよびその他の形式の使用を可能にするこの例です。プロファイルは、対応するCOAPコンテンツタイプが登録されているという仮定で、送信される形式を指定する必要があります。プロファイルでは、受信者が送信を許可されているすべての形式を受け入れる必要があります。
Further, if there is variation within a format that is allowed, the profile should specify which variations can be sent. For example, there are variations in the CoSWID format. A profile might require the receiver to accept all variations that are allowed to be sent.
さらに、許可されている形式内にバリエーションがある場合、プロファイルはどのバリエーションを送信できるかを指定する必要があります。たとえば、Coswid形式にはバリエーションがあります。プロファイルでは、受信者が送信を許可されているすべてのバリエーションを受け入れる必要がある場合があります。
It is anticipated that there will be many profiles defined for EAT for many different use cases. This section gives a normative definition of one profile that is good for many constrained device use cases.
多くの異なるユースケースで食事のために定義される多くのプロファイルが定義されることが予想されます。このセクションでは、多くの制約されたデバイスユースケースに適した1つのプロファイルの規範的な定義を示します。
The identifier for this profile is "urn:ietf:rfc:rfc9711".
このプロファイルの識別子は「urn：ietf：rfc：rfc9711」です。
+================+==================================================+
| Issue | Profile Definition |
+================+==================================================+
| CBOR/JSON | CBOR MUST be used. |
+----------------+--------------------------------------------------+
| CBOR Encoding | Definite-length maps and arrays MUST be |
| | used. |
+----------------+--------------------------------------------------+
| CBOR Encoding | Definite-length strings MUST be used. |
+----------------+--------------------------------------------------+
| CBOR | Preferred serialization MUST be used. |
| Serialization | |
+----------------+--------------------------------------------------+
| COSE | COSE_Sign1 MUST be used. |
| Protection | |
+----------------+--------------------------------------------------+
| Algorithms | The receiver MUST accept ES256, ES384, |
| | and ES512; the sender MUST send one of |
| | these. |
+----------------+--------------------------------------------------+
| Detached EAT | Detached EAT bundles MUST NOT be sent |
| Bundle Usage | with this profile. |
+----------------+--------------------------------------------------+
| Verification | Either the COSE key identifier (kid) or |
| Key | the UEID MUST be used to identify the |
| Identification | verification key. If both are present, |
| | the kid takes precedence. (It is assumed |
| | the receiver has access to a database of |
| | trusted verification keys, which allows a |
| | lookup of the verification key ID; the |
| | key format and means of distribution are |
| | beyond the scope of this profile.) |
+----------------+--------------------------------------------------+
| Endorsements | This profile contains no endorsement |
| | identifier. |
+----------------+--------------------------------------------------+
| Freshness | A new single unique nonce MUST be used |
| | for every token request. |
+----------------+--------------------------------------------------+
| Claims | No requirement is made for the presence |
| | or absence of claims other than requiring |
| | an EAT nonce. As per general EAT rules, |
| | the receiver MUST NOT error out on claims |
| | it does not understand. |
+----------------+--------------------------------------------------+
Table 2: Constrained Device Profile Definition
表2：制約付きデバイスプロファイルの定義
Any profile with different requirements than those above MUST have a different profile identifier.
上記の要件とは異なる要件を持つプロファイルには、異なるプロファイル識別子が必要です。
Note that many claims can be present for tokens conforming to this profile, even claims not defined in this document. Note also that even slight deviation from the above requirements is considered a different profile that MUST have a different identifier. For example, if a kid (key identifier) or UEID is not used for key identification, it is not in conformance with this profile. As another example, requiring the presence of some claim is also not in conformance and requires another profile.
このプロファイルに準拠しているトークンには多くのクレームが存在する可能性があることに注意してください。このドキュメントでは定義されていないクレームもあります。また、上記の要件からのわずかな偏差でさえ、異なる識別子を持つ必要がある別のプロファイルと見なされることに注意してください。たとえば、KID（キー識別子）またはUEIDがキー識別に使用されない場合、このプロファイルに準拠していません。別の例として、いくつかのクレームの存在を要求することも適合性ではなく、別のプロファイルが必要です。
Derivations of this profile are encouraged. For example, another profile may be simply defined as "The Constrained Device Standard Profile" plus the requirement for the presence of claim xxxx and claim yyyy.
このプロファイルの派生が奨励されています。たとえば、別のプロファイルは、「制約付きデバイス標準プロファイル」に加えて、クレームxxxxの存在とクレームyyyyの存在の要件として単純に定義される場合があります。
An EAT is fundamentally defined using CDDL. This document specifies how to encode the CDDL in CBOR or JSON. Since CBOR can express some things that JSON cannot (e.g., tags) or that are expressed differently (e.g., labels), there is some CDDL that is specific to the encoding.
食事は、CDDLを使用して根本的に定義されています。このドキュメントは、CBORまたはJSONでCDDLをエンコードする方法を指定しています。CBORは、JSONができない（タグなど）、または異なる表現（ラベルなど）ができないものを表現できるため、エンコードに固有のCDDLがあります。
CDDL was not used to define CWT or JWT. It was not available at the time.
CDDLは、CWTまたはJWTを定義するために使用されませんでした。当時は利用できませんでした。
This document defines CDDL for both CWT and JWT. This document does not change the encoding or semantics of anything in a CWT or JWT.
このドキュメントでは、CWTとJWTの両方のCDDLを定義しています。このドキュメントは、CWTまたはJWTの何かのエンコーディングまたはセマンティクスを変更しません。
A Claims-Set is the central data structure for EAT, CWT, and JWT. It holds all the claims and is the structure that is secured by signing or other means. It is not possible to define EAT, CWT, or JWT in CDDL without it. The CDDL definition of Claims-Set here is applicable to EAT, CWT, and JWT.
クレームセットは、EAT、CWT、およびJWTの中心データ構造です。それはすべてのクレームを保持し、署名またはその他の手段によって保護されている構造です。それなしでCDDLでEAT、CWT、またはJWTを定義することはできません。ここでのクレームセットのCDDL定義は、EAT、CWT、およびJWTに適用できます。
This document specifies how to encode a Claims-Set in CBOR or JSON.
このドキュメントは、CBORまたはJSONでクレームセットをエンコードする方法を指定しています。
With the exception of nested tokens and some other externally defined structures (e.g., SWIDs), an entire Claims-Set must be encoded in either CBOR or JSON, never a mixture.
ネストされたトークンと他のいくつかの外部から定義された構造（SWIDSなど）を除き、クレームセット全体をCBORまたはJSONのいずれかでエンコードする必要があります。
CDDL for the seven claims defined by [RFC8392] and [RFC7519] is also specified in this document.
[RFC8392]および[RFC7519]によって定義された7つのクレームのCDDLもこのドキュメントで指定されています。
The following subsections use the types defined in "Standard Prelude" (Appendix D of [RFC8610]).
以下のサブセクションでは、「標準前奏曲」で定義されたタイプを使用します（[RFC8610]の付録D）。
time-int is identical to the epoch-based time but disallows floating-point representation.
Time-intはエポックベースの時間と同一ですが、浮動小数点表現を許可しません。
For CBOR-encoded tokens, OIDs are specified using the CDDL type name "oid" from [RFC9090]. They are encoded without the tag number. For JSON-encoded tokens, OIDs are text strings in the common form of "nn.nn.nn...".
Cborエンコードトークンの場合、[RFC9090]のCDDLタイプ名「OID」を使用してOIDが指定されます。タグ番号なしでエンコードされます。JSONエンコードトークンの場合、OIDは「nn.nn.nn ...」の一般的な形のテキスト文字列です。
Unless explicitly indicated, URIs are not the URI tag defined in [RFC8949]. They are just text strings that contain a URI conforming to the format defined in [RFC3986].
明示的に示されない限り、URIは[RFC8949]で定義されているURIタグではありません。それらは、[RFC3986]で定義されている形式に準拠したURIを含むテキスト文字列です。
time-int = #6.1(int)
binary-data = JC< base64-url-text, bstr>
base64-url-text = tstr .regexp "[A-Za-z0-9_-]+"
general-oid = JC< json-oid, ~oid >
json-oid = tstr .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*"
general-uri = JC< text, ~uri >
coap-content-format = uint .le 65535
JSON should be encoded per Appendix E of [RFC8610]. In addition, the following CDDL types are encoded in JSON as follows:
JSONは、[RFC8610]の付録Eに従ってエンコードする必要があります。さらに、次のCDDLタイプは、次のようにJSONでエンコードされています。
* bstr -- MUST be base64url encoded.
* BSTR -base64urlエンコードされている必要があります。
* time -- MUST be encoded as NumericDate as described in Section 2 of [RFC7519].
* 時間 - [RFC7519]のセクション2で説明されているように、数値としてエンコードする必要があります。
* string-or-uri -- MUST be encoded as StringOrURI as described in Section 2 of [RFC7519].
* string-or-uri- [rfc7519]のセクション2で説明されているように、stringoruriとしてエンコードする必要があります。
* uri -- MUST be a URI [RFC3986].
* URI -URI [RFC3986]でなければなりません。
* oid -- MUST be encoded as a string using the well-established dotted-decimal notation (e.g., the text "1.2.250.1") [RFC4517].
* oid-定評のある点線程度の表記を使用して文字列としてエンコードする必要があります（例：テキスト「1.2.250.1 "）[RFC4517]。
The CDDL generic "JC<>" is used in most places where there is a variance between CBOR and JSON. The first argument is the CDDL for JSON, and the second is CDDL for CBOR.
CDDLジェネリック「JC <>」は、CBORとJSONの間に差異があるほとんどの場所で使用されます。最初の引数はJSONのCDDLであり、2つ目はCBORのCDDLです。
Most map labels, Claims-Keys, Claim-Names, and enumerated-type values are integers for CBOR-encoded tokens and strings for JSON-encoded tokens. When this is the case, the JC<> CDDL construct is used to give both the integer and string values.
ほとんどのマップラベル、クレームキー、クレーム名、および列挙タイプの値は、cborエンコードされたトークンの整数と、JSONエンコードトークンの文字列です。この場合、JC <> CDDLコンストラクトを使用して、整数値と文字列値の両方を示します。
CBOR allows data items to be serialized in more than one form to accommodate a variety of use cases. This is addressed in Section 6.
CBORを使用すると、データ項目を複数のフォームでシリアル化して、さまざまなユースケースに対応できます。これはセクション6で説明されています。
See [EAT-GitHub] for additional information and stub files, when using the CDDL presented in this section to validate EAT protocol messages.
このセクションで提示されたCDDLを使用してEATプロトコルメッセージを検証する場合は、追加情報とスタブファイルについては[Eat-Github]を参照してください。
The payload CDDL defines all the EAT claims that are added to the main definition of a Claims-Set in Appendix D. Claims-Set is the payload for CWT, JWT, and potentially other token types. This is for both CBOR and JSON. When there is variation between CBOR and JSON, the JC<> CDDL generic defined in Appendix D is used. Note that the JC<> generic uses the CDDL ".feature" control operator defined in [RFC9165].
ペイロードCDDLは、付録Dのクレームセットの主な定義に追加されたすべてのEATクレームを定義します。クレームセットは、CWT、JWT、および潜在的に他のトークンタイプのペイロードです。これは、CBORとJSONの両方のためです。CBORとJSONの間に変動がある場合、付録Dで定義されているJC <> CDDLジェネリックが使用されます。JC <> genericは、[RFC9165]で定義されているCDDL ".Feature"制御演算子を使用していることに注意してください。
This CDDL uses, but does not define, Submodule or nested tokens because the definition for these types varies between CBOR and JSON and the JC<> generic cannot be used to define it. The submodule claim is the one place where a CBOR token can be nested inside a JSON token and vice versa. Encoding-specific definitions are provided in the following sections.
このCDDLは、これらのタイプの定義はCBORとJSONの間で異なるため、サブモジュールまたはネストされたトークンを使用しますが、定義していません。サブモジュールのクレームは、CBORトークンをJSONトークン内にネストできる場所の1つであり、その逆も同様です。エンコーディング固有の定義は、次のセクションに記載されています。
time-int = #6.1(int)
binary-data = JC< base64-url-text, bstr>
base64-url-text = tstr .regexp "[A-Za-z0-9_-]+"
general-oid = JC< json-oid, ~oid >
json-oid = tstr .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*"
general-uri = JC< text, ~uri >
coap-content-format = uint .le 65535
$$Claims-Set-Claims //=
(nonce-label => nonce-type / [ 2* nonce-type ])
nonce-type = JC< tstr .size (8..88), bstr .size (8..64)>
$$Claims-Set-Claims //= (ueid-label => ueid-type)
ueid-type = JC<base64-url-text .size (10..44) , bstr .size (7..33)>
$$Claims-Set-Claims //= (sueids-label => sueids-type)
sueids-type = {
+ tstr => ueid-type
}
$$Claims-Set-Claims //= (
oemid-label => oemid-pen / oemid-ieee / oemid-random
)
oemid-pen = int
oemid-ieee = JC<oemid-ieee-json, oemid-ieee-cbor>
oemid-ieee-cbor = bstr .size 3
oemid-ieee-json = base64-url-text .size 4
oemid-random = JC<oemid-random-json, oemid-random-cbor>
oemid-random-cbor = bstr .size 16
oemid-random-json = base64-url-text .size 24
$$Claims-Set-Claims //= (
hardware-version-label => hardware-version-type
)
hardware-version-type = [
version: tstr,
? scheme: $version-scheme
]
$$Claims-Set-Claims //= (
hardware-model-label => hardware-model-type
)
hardware-model-type = JC<base64-url-text .size (4..44),
bytes .size (1..32)>
$$Claims-Set-Claims //= ( sw-name-label => tstr )
$$Claims-Set-Claims //= (sw-version-label => sw-version-type)
sw-version-type = [
version: tstr
? scheme: $version-scheme
]
$$Claims-Set-Claims //= (oem-boot-label => bool)
$$Claims-Set-Claims //= ( debug-status-label => debug-status-type )
debug-status-type = ds-enabled /
disabled /
disabled-since-boot /
disabled-permanently /
disabled-fully-and-permanently
ds-enabled = JC< "enabled", 0 >
disabled = JC< "disabled", 1 >
disabled-since-boot = JC< "disabled-since-boot", 2 >
disabled-permanently = JC< "disabled-permanently", 3 >
disabled-fully-and-permanently =
JC< "disabled-fully-and-permanently", 4 >
$$Claims-Set-Claims //= (location-label => location-type)
location-type = {
latitude => number,
longitude => number,
? altitude => number,
? accuracy => number,
? altitude-accuracy => number,
? heading => number,
? speed => number,
? timestamp => ~time-int,
? age => uint
}
latitude = JC< "latitude", 1 >
longitude = JC< "longitude", 2 >
altitude = JC< "altitude", 3 >
accuracy = JC< "accuracy", 4 >
altitude-accuracy = JC< "altitude-accuracy", 5 >
heading = JC< "heading", 6 >
speed = JC< "speed", 7 >
timestamp = JC< "timestamp", 8 >
age = JC< "age", 9 >
$$Claims-Set-Claims //= (uptime-label => uint)
$$Claims-Set-Claims //= (boot-seed-label => binary-data)
$$Claims-Set-Claims //= (boot-count-label => uint)
$$Claims-Set-Claims //= ( intended-use-label => intended-use-type )
intended-use-type = JC< text, int>
$$Claims-Set-Claims //= (
dloas-label => [ + dloa-type ]
)
dloa-type = [
dloa_registrar: general-uri
dloa_platform_label: text
? dloa_application_label: text
]
$$Claims-Set-Claims //= (profile-label => general-uri / general-oid)
$$Claims-Set-Claims //= (
manifests-label => manifests-type
)
manifests-type = [+ manifest-format]
manifest-format = [
content-type: coap-content-format,
content-format: JC< $manifest-body-json,
$manifest-body-cbor >
]
$manifest-body-cbor /= bytes .cbor untagged-coswid
$manifest-body-json /= base64-url-text
$$Claims-Set-Claims //= (
measurements-label => measurements-type
)
measurements-type = [+ measurements-format]
measurements-format = [
content-type: coap-content-format,
content-format: JC< $measurements-body-json,
$measurements-body-cbor >
]
$measurements-body-cbor /= bytes .cbor untagged-coswid
$measurements-body-json /= base64-url-text
$$Claims-Set-Claims //= (
measurement-results-label =>
[ + measurement-results-group ] )
measurement-results-group = [
measurement-system: tstr,
measurement-results: [ + individual-result ]
]
individual-result = [
result-id: tstr / binary-data,
result: result-type,
]
result-type = comparison-success /
comparison-fail /
comparison-not-run /
measurement-absent
comparison-success = JC< "success", 1 >
comparison-fail = JC< "fail", 2 >
comparison-not-run = JC< "not-run", 3 >
measurement-absent = JC< "absent", 4 >
Detached-Submodule-Digest = [
hash-algorithm : text / int,
digest : binary-data
]
BUNDLE-Messages = BUNDLE-Tagged-Message / BUNDLE-Untagged-Message
BUNDLE-Tagged-Message = #6.602(BUNDLE-Untagged-Message)
BUNDLE-Untagged-Message = Detached-EAT-Bundle
Detached-EAT-Bundle = [
main-token : Nested-Token,
detached-claims-sets: {
+ tstr => JC<json-wrapped-claims-set,
cbor-wrapped-claims-set>
}
]
json-wrapped-claims-set = base64-url-text
cbor-wrapped-claims-set = bstr .cbor Claims-Set
nonce-label = JC< "eat_nonce", 10 >
ueid-label = JC< "ueid", 256 >
sueids-label = JC< "sueids", 257 >
oemid-label = JC< "oemid", 258 >
hardware-model-label = JC< "hwmodel", 259 >
hardware-version-label = JC< "hwversion", 260 >
uptime-label = JC< "uptime", 261 >
oem-boot-label = JC< "oemboot", 262 >
debug-status-label = JC< "dbgstat", 263 >
location-label = JC< "location", 264 >
profile-label = JC< "eat_profile", 265 >
submods-label = JC< "submods", 266 >
boot-count-label = JC< "bootcount", 267 >
boot-seed-label = JC< "bootseed", 268 >
dloas-label = JC< "dloas", 269 >
sw-name-label = JC< "swname", 270 >
sw-version-label = JC< "swversion", 271 >
manifests-label = JC< "manifests", 272 >
measurements-label = JC< "measurements", 273 >
measurement-results-label = JC< "measres" , 274 >
intended-use-label = JC< "intuse", 275 >
EAT-CBOR-Token = $CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
$CBOR-Tagged-Token /= CWT-Tagged-Message
$CBOR-Tagged-Token /= BUNDLE-Tagged-Message
$EAT-CBOR-Untagged-Token /= CWT-Untagged-Message
$EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message
Nested-Token = CBOR-Nested-Token
CBOR-Nested-Token =
JSON-Token-Inside-CBOR-Token /
CBOR-Token-Inside-CBOR-Token
CBOR-Token-Inside-CBOR-Token = bstr .cbor $CBOR-Tagged-Token
JSON-Token-Inside-CBOR-Token = tstr
$$Claims-Set-Claims //= (submods-label => { + text => Submodule })
Submodule = Claims-Set / CBOR-Nested-Token /
Detached-Submodule-Digest
EAT-JSON-Token = $EAT-JSON-Token-Formats
$EAT-JSON-Token-Formats /= JWT-Message
$EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message
Nested-Token = JSON-Selector
JSON-Selector = $JSON-Selector
$JSON-Selector /= [type: "JWT", nested-token: JWT-Message]
$JSON-Selector /= [type: "CBOR", nested-token:
CBOR-Token-Inside-JSON-Token]
$JSON-Selector /= [type: "BUNDLE", nested-token: Detached-EAT-Bundle]
$JSON-Selector /= [type: "DIGEST", nested-token:
Detached-Submodule-Digest]
CBOR-Token-Inside-JSON-Token = base64-url-text
$$Claims-Set-Claims //= (submods-label => { + text => Submodule })
Submodule = Claims-Set / JSON-Selector
Certain EAT claims can be used to track the owner of an entity; therefore, implementations should consider privacy-preserving options dependent on the usage of the EAT. For example, the location claim might be suppressed in EATs sent to unauthenticated consumers.
特定のEATクレームは、エンティティの所有者を追跡するために使用できます。したがって、実装は、食事の使用に依存するプライバシーを提供するオプションを考慮する必要があります。たとえば、認定されていない消費者に送られたEATで、場所の請求は抑制される場合があります。
A UEID is usually not privacy-preserving. Relying parties receiving tokens from a particular entity will be able to know that the tokens are from the same entity and identify the entity issuing those tokens.
UEIDは通常、プライバシーを摂取するものではありません。特定のエンティティからトークンを受け取る依存関係者は、トークンが同じエンティティからのものであることを知り、それらのトークンを発行するエンティティを特定することができます。
Thus, the use of the claim may violate privacy policies. In other usage situations, a UEID will not be allowed for certain products such as browsers that give privacy for the end user. It will often be the case that tokens will not have a UEID for these reasons.
したがって、請求の使用はプライバシーポリシーに違反する可能性があります。他の使用状況では、UEIDは、エンドユーザーにプライバシーを提供するブラウザなどの特定の製品には許可されません。多くの場合、これらの理由でトークンにはUEIDがない場合があります。
An SUEID is also usually not privacy-preserving. In some cases, it may have fewer privacy issues than a UEID depending on when and how it is generated.
Sueidは通常、プライバシーを摂取することもありません。場合によっては、いつ、どのように生成されるかに応じて、UEIDよりもプライバシーの問題が少ない場合があります。
There are several strategies that can be used to still be able to put UEIDs and SUEIDs in tokens:
トークンにueidsとsueidsを配置できるために使用できるいくつかの戦略があります。
* The entity obtains explicit permission from the user of the entity to use the UEID/SUEID; this may be through a prompt or through a license agreement. For example, agreements for some online banking and brokerage services might already cover use of a UEID/ SUEID.
* エンティティは、UEID/Sueidを使用するために、エンティティのユーザーから明示的な許可を取得します。これは、プロンプトまたはライセンス契約を介して行われる場合があります。たとえば、一部のオンラインバンキングおよび証券会社の契約は、すでにUEID/ Sueidの使用をカバーする可能性があります。
* The UEID/SUEID is used only in a particular context or use case. It is used only by one relying party.
* ueid/sueidは、特定のコンテキストまたはユースケースでのみ使用されます。1つの依存パーティーのみが使用しています。
* The entity authenticates the relying party and generates a derived UEID/SUEID just for that particular relying party. For example, the relying party could prove their identity cryptographically to the entity, then the entity generates a UEID just for that relying party by hashing a proofed relying party ID with the main entity UEID/SUEID.
* エンティティは、依存している当事者を認証し、その特定の依存者のためだけに派生したueid/sueidを生成します。たとえば、依存する当事者は、エンティティに対するアイデンティティを暗号化して証明することができ、エンティティは、主要なエンティティ/スイイドとの依存者IDを証明した当事者のためだけにueidを生成します。
Note that some of these privacy preservation strategies result in multiple UEIDs and SUEIDs per entity. Each UEID/SUEID is used in a different context, use case, or system on the entity. However, from the view of the relying party, there is just one UEID and it is still globally universal across manufacturers.
これらのプライバシー保存戦略のいくつかは、エンティティごとに複数のUEIDとスイイドをもたらすことに注意してください。各ueid/sueidは、エンティティ上の異なるコンテキスト、ユースケース、またはシステムで使用されます。ただし、依存者の観点から見ると、UEIDは1つだけで、メーカー全体でグローバルに普遍的です。
Geographic location is almost always considered personally identifiable information. Implementors should consider laws and regulations governing the transmission of location data from end-user devices to servers and services. Implementors should consider using location management facilities offered by the operating system on the entity generating the attestation. For example, many mobile phones prompt the user for permission before sending location data.
地理的位置は、ほとんど常に個人を特定できる情報と見なされます。実装者は、エンドユーザーデバイスからサーバーやサービスへの位置データの送信を管理する法律および規制を考慮する必要があります。実装者は、証明を生成するエンティティでオペレーティングシステムが提供するロケーション管理施設の使用を検討する必要があります。たとえば、多くの携帯電話は、ロケーションデータを送信する前にユーザーに許可を求めます。
The "bootseed" claim is effectively a stable entity identifier within a given boot epoch. Therefore, it is not suitable for use in attestation schemes that are privacy-preserving.
「ブートシード」クレームは、事実上、特定のブートエポック内の安定したエンティティ識別子です。したがって、プライバシーを摂取することの認証スキームでの使用には適していません。
EAT defines the EAT nonce claim for replay protection and token freshness. The nonce claim is based on a value usually derived remotely (outside of the entity). This claim might be used to extract and convey personally identifying information either inadvertently or by intention. For instance, an implementor may choose a nonce equivalent to a username associated with the device (e.g., account login). If the token is inspected by a third party, then this information could be used to identify the source of the token or an account associated with the token. To avoid the conveyance of privacy-related information in the nonce claim, it should be derived using a salt that originates from a true and reliable random number generator or any other source of randomness that would still meet the target system requirements for replay protection and token freshness.
Eatは、リプレイ保護とトークンの新鮮さのためのEat Nonceの主張を定義します。NONCEクレームは、通常はリモートで派生した値に基づいています（エンティティ以外）。このクレームは、不注意または意図的に情報を個人的に識別するために抽出および伝達するために使用される場合があります。たとえば、実装者は、デバイスに関連付けられたユーザー名（アカウントログインなど）に相当するNonCEを選択できます。トークンが第三者によって検査された場合、この情報を使用して、トークンのソースまたはトークンに関連付けられたアカウントを識別できます。NONCE請求におけるプライバシー関連情報の伝達を回避するには、リプレイ保護とトークンの新鮮さのターゲットシステム要件をまだ満たす、真の信頼できる乱数ジェネレーターまたはその他のランダム性のソースに由来する塩を使用して導出する必要があります。
The security considerations provided in Section 8 of [RFC8392] and of Section 11 of [RFC7519] apply to EAT in its CWT and JWT form, respectively. Moreover, Section 12 of [RFC9334] is also applicable to implementations of EAT. In addition, implementors should consider the information in the following subsections.
[RFC8392]のセクション8および[RFC7519]のセクション11で規定されているセキュリティ上の考慮事項は、それぞれCWTおよびJWT形式で食事をすることに適用されます。さらに、[RFC9334]のセクション12は、EATの実装にも適用できます。さらに、実装者は次のサブセクションで情報を考慮する必要があります。
This specification defines semantics for each claim. It does not require any particular level of security in the implementation of the claims or even for the attester itself. Such specification is far beyond the scope of this document, which is about a message format not the security level of an implementation.
この仕様は、各クレームのセマンティクスを定義します。請求の実装や、攻撃自体のために、特定のレベルのセキュリティを必要としません。このような仕様は、このドキュメントの範囲をはるかに超えています。これは、実装のセキュリティレベルではなくメッセージ形式に関するものです。
The receiver of an EAT knows the trustworthiness of the claims in it by understanding the implementation made by the attester vendor and/ or understanding the checks and processing performed by the verifier.
Eatの受信者は、Attesterベンダーによる実装を理解し、および/または検証者が実行したチェックと処理を理解することにより、その請求の信頼性を知っています。
For example, this document states that a UEID is permanent and that it must not change, but it does not describe any security requirements or a level of defense to prevent an attacker from changing the UEID.
たとえば、このドキュメントでは、UEIDは永続的であり、変更してはならないが、攻撃者がUEIDを変更するのを防ぐためのセキュリティ要件や防御レベルを説明していないと述べています。
The degree of security will vary from use case to use case. In some cases, the receiver may only need to know something of the implementation such as that it was implemented in a TEE. In other cases, the receiver may require the attester to be certified by a particular certification program. Or perhaps the receiver is content with very little security.
セキュリティの程度は、ユースケースごとに異なります。場合によっては、レシーバーは、ティーで実装されたような実装の何かを知る必要がある場合があります。それ以外の場合、受信者は、特定の認定プログラムによって攻撃者が認定されることを要求する場合があります。または、おそらくレシーバーがセキュリティがほとんどないコンテンツです。
Private key material can be used to sign and/or encrypt the EAT or to derive the keys used for signing and/or encryption. In some instances, the manufacturer of the entity may create the key material separately and provision the key material in the entity itself. The manufacturer of any entity that is capable of producing an EAT should take care to ensure that any private key material be suitably protected prior to provisioning the key material in the entity itself. This can require creation of key material in an enclave (see [RFC4949] for definition of "enclave"), secure transmission of the key material from the enclave to the entity using an appropriate protocol, and persistence of the private key material in some form of secure storage to which (preferably) only the entity has access.
秘密のキー資料を使用して、食事に署名および/または暗号化するか、署名や暗号化に使用されるキーを導き出すことができます。場合によっては、エンティティの製造業者は、キー資料を個別に作成し、エンティティ自体に重要な資料を提供する場合があります。食事を生産できるエンティティの製造業者は、エンティティ自体の重要な資料をプロビジョニングする前に、秘密のキー資料を適切に保護するように注意する必要があります。これには、エンクレーブに重要な材料の作成（「エンクレーブ」の定義については[rfc4949]を参照）、適切なプロトコルを使用してエンクレーブからエンティティへの主要な材料の保護された送信、およびエンティティのみがアクセスできる安全なストレージのある形での秘密キーマテリアルの持続性が必要です。
Regarding transmission of key material from the enclave to the entity, the key material may pass through one or more intermediaries. Therefore, some form of protection (e.g., key wrapping) may be necessary. The transmission itself may be performed electronically, but it can also be done by human courier. In the latter case, there should be minimal to no exposure of the key material to the human (e.g., encrypted portable memory). Moreover, the human should transport the key material directly from the secure enclave where it was created to a destination secure enclave where it can be provisioned.
エンクレーブからエンティティへの主要な資料の送信に関して、重要な資料は1つ以上の仲介者を通過する場合があります。したがって、何らかの形の保護（例：キーラッピング）が必要になる場合があります。トランスミッション自体は電子的に実行される場合がありますが、人間の宅配便によっても実行できます。後者の場合、主要な材料を人間に曝露する最小限から最小限の露出（例えば、暗号化されたポータブルメモリ）が必要です。さらに、人間は、主要な材料を安全な飛び地から直接輸送し、そこで作成された宛先セキュアエンクレーブにプロビジョニングできるセキュアエンクレーブに輸送する必要があります。
All EAT use MUST provide a freshness mechanism to prevent replay and related attacks. The extensive discussions in [RFC9334] on freshness, as well as the security considerations, apply here. One option to provide freshness is the EAT nonce claim (Section 4.1).
すべての食事の使用は、リプレイや関連する攻撃を防ぐために新鮮さのメカニズムを提供する必要があります。[RFC9334]での新鮮さに関する広範な議論とセキュリティに関する考慮事項は、ここで適用されます。新鮮さを提供する1つのオプションは、Eat Nonceの請求です（セクション4.1）。
In many cases, more than one EAT consumer may be required to fully verify the entity attestation. Examples include individual consumers for nested EATs or consumers for individual claims with an EAT. When multiple consumers are required for verification of an EAT, it is important to minimize information exposure to each consumer. In addition, the communication between multiple consumers should be secure.
多くの場合、エンティティの証明を完全に検証するには、複数の食事消費者が必要になる場合があります。例には、ネストされた食事のための個々の消費者または食事を伴う個々の請求のための消費者が含まれます。複数の消費者が食事の検証に必要な場合、各消費者への情報露出を最小限に抑えることが重要です。さらに、複数の消費者間の通信は安全でなければなりません。
For instance, consider the example of an encrypted and signed EAT with multiple claims. A consumer may receive the EAT (denoted as the "receiving consumer"), decrypt its payload, and verify its signature but then pass specific subsets of claims to other consumers for evaluation ("downstream consumers"). Since any COSE encryption will be removed by the receiving consumer, the communication of claim subsets to any downstream consumer MUST leverage an equivalent communication security protocol (e.g., TLS).
たとえば、複数のクレームで暗号化および署名された食事の例を考えてください。消費者は、食事（「受信消費者」として示される）を受け取り、ペイロードを復号化し、その署名を確認するが、評価のために他の消費者に請求の特定のサブセットを渡すことができます（「ダウンストリーム消費者」）。COSE暗号化は受信消費者によって削除されるため、下流の消費者とのクレームサブセットの通信は、同等の通信セキュリティプロトコル（TLSなど）を活用する必要があります。
However, assume the EAT of the previous example is hierarchical and each claim subset for a downstream consumer is created in the form of a nested EAT. Then, the nested EAT itself is encrypted and cryptographically verifiable (due to its COSE envelope) by a downstream consumer (unlike the previous example where a claims set without a COSE envelope is sent to a downstream consumer). Therefore, TLS between the receiving and downstream consumers is not strictly required. Nevertheless, downstream consumers of a nested EAT should provide a nonce unique to the EAT they are consuming.
ただし、前の例のEATが階層的であり、下流の消費者の各クレームサブセットがネストされた食事の形で作成されていると仮定します。その後、ネストされたEAT自体は、下流の消費者によって暗号化され、暗号化された（COSEエンベロープのため）（COSEエンベロープのため）、COSEエンベロープのないクレームが下流の消費者に送信される前の例とは異なります）。したがって、受信消費者と下流の消費者の間のTLSは厳密に必要ではありません。それにもかかわらず、ネストされた食事の下流の消費者は、彼らが消費している食事に固有のノンセを提供するはずです。
A detached EAT bundle is composed of a nested EAT and a claims set as per Section 5. Although the attached claims set is vulnerable to modification in transit, any modification can be detected by the receiver through the associated digest, which is a claim fully contained within an EAT. Moreover, the digest itself can only be derived using an appropriate COSE hash algorithm, implying that an attacker cannot induce false detection of modified detached claims because the algorithms in the COSE registry are assumed to be of sufficient cryptographic strength.
分離したEATバンドルは、セクション5に従ってネストされたEATとクレームセットで構成されています。添付のクレームセットは、輸送中の変更に対して脆弱ですが、ASTASSION DIGESTを介してレシーバーが修正を検出できます。さらに、ダイジェスト自体は、適切なCOSEハッシュアルゴリズムを使用してのみ導出できます。これは、COSEレジストリのアルゴリズムが十分な暗号強度であると考えられているため、攻撃者が修正されたデタッチされたクレームの誤検出を誘導できないことを意味します。
In all cases, there must be some way that the verification key itself is verified or determined to be trustworthy. The key identification itself is never enough. This will always be by some out-of-band mechanism that is not described here. For example, the verifier may be configured with a root certificate or a master key by the verifier system administrator.
すべての場合において、検証キー自体が信頼できると検証または決定される方法がある必要があります。重要な識別自体だけでは十分ではありません。これは常に、ここでは説明されていない帯域外のメカニズムによって行われます。たとえば、検証器は、Verifier System Administratorによってルート証明書またはマスターキーで構成されてもよいです。
Often, an X.509 certificate or an endorsement carries more than just the verification key. For example, an X.509 certificate might have key usage constraints, and an endorsement might have reference values. When this is the case, the key identifier must be either a protected header or in the payload, such that it is cryptographically bound to the EAT. This is in line with the requirements in "Key Identification" of JSON Web Signature (Section 6 of [RFC7515]).
多くの場合、X.509証明書または承認は、検証キーだけ以上のものを持ちます。たとえば、X.509証明書には主要な使用法の制約があり、承認には参照値がある場合があります。この場合、キー識別子は保護されたヘッダーまたはペイロード内のいずれかである必要があり、そのため、それはeatに暗号化されているようにします。これは、JSON Web署名（[RFC7515]のセクション6）の「キー識別」の要件と一致しています。
Claims defined for EAT are compatible with those of CWT and JWT, so the CWT and JWT Claims registries, [IANA.CWT.Claims] and [IANA.JWT.Claims], are reused. No new IANA registry is created.
EATで定義されたクレームはCWTおよびJWTの請求と互換性があるため、CWTおよびJWTはレジストリ、[iana.cwt.claims]および[iana.jwt.claims]を請求します。新しいIANAレジストリは作成されていません。
All EAT claims defined in this document have been placed in both registries. All new EAT claims defined subsequently should be placed in both registries.
このドキュメントで定義されているすべてのEATクレームは、両方のレジストリに配置されています。その後定義されたすべての新しいEATクレームは、両方のレジストリに配置する必要があります。
Appendix E describes some considerations when defining new claims.
付録Eでは、新しいクレームを定義する際にいくつかの考慮事項について説明しています。
Per this specification, the following values have been added to the "JSON Web Token Claims" registry established by [RFC7519] and the "CBOR Web Token (CWT) Claims" registry established by [RFC8392]. Each entry below has been added to both registries.
この仕様に従って、[RFC7519]によって確立された「JSON Webトークンクレーム」レジストリに次の値が追加され、[RFC8392]によって確立された「Cbor Webトークン（CWT）クレーム」レジストリが追加されています。以下の各エントリは両方のレジストリに追加されました。
The "Claim Description", "Change Controller", and "Reference" fields are common and equivalent for the JWT and CWT registries. The "Claim Key" and "Claim Value Type" fields are for the CWT registry only. The "Claim Name" field is as defined for the CWT registry, not the JWT registry. The "JWT Claim Name" field is equivalent to the "Claim Name" field in the JWT registry.
「クレーム説明」、「Change Controller」、および「Reference」フィールドは、JWTおよびCWTレジストリで一般的で同等です。「クレームキー」および「クレーム値タイプ」フィールドは、CWTレジストリのみです。「クレーム名」フィールドは、JWTレジストリではなく、CWTレジストリに対して定義されています。「JWTクレーム名」フィールドは、JWTレジストリの「クレーム名」フィールドに相当します。
IANA has registered the following claims.
IANAは次の請求を登録しました。
Claim Name:
クレーム名：
Nonce
nonce
Claim Description:
クレームの説明：
Nonce
nonce
JWT Claim Name:
JWTクレーム名：
eat_nonce
eat_nonce
Claim Key:
主張キー：
10
10
Claim Value Type:
請求値タイプ：
bstr or array
BSTRまたはアレイ
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
UEID
ueid
Claim Description:
クレームの説明：
Universal Entity ID
ユニバーサルエンティティID
JWT Claim Name:
JWTクレーム名：
ueid
ueid
CWT Claim Key:
CWTクレームキー：
256
256
Claim Value Type:
請求値タイプ：
bstr
BSTR
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
SUEIDs
スイイド
Claim Description:
クレームの説明：
Semipermanent UEIDs
セミペルマネントueids
JWT Claim Name:
JWTクレーム名：
sueids
スイイド
CWT Claim Key:
CWTクレームキー：
257
257
Claim Value Type:
請求値タイプ：
map
地図
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Hardware OEM ID
ハードウェアOEM ID
Claim Description:
クレームの説明：
Hardware OEM ID
ハードウェアOEM ID
JWT Claim Name:
JWTクレーム名：
oemid
oemid
Claim Key:
主張キー：
258
258
Claim Value Type:
請求値タイプ：
bstr or int
BSTRまたはINT
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Hardware Model
ハードウェアモデル
Claim Description:
クレームの説明：
Model identifier for hardware
ハードウェアのモデル識別子
JWT Claim Name:
JWTクレーム名：
hwmodel
hwmodel
Claim Key:
主張キー：
259
259
Claim Value Type:
請求値タイプ：
bstr
BSTR
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Hardware Version
ハードウェアバージョン
Claim Description:
クレームの説明：
Hardware Version Identifier
ハードウェアバージョン識別子
JWT Claim Name:
JWTクレーム名：
hwversion
Hwversion
Claim Key:
主張キー：
260
260
Claim Value Type:
請求値タイプ：
array
配列
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Uptime
稼働時間
Claim Description:
クレームの説明：
Uptime
稼働時間
JWT Claim Name:
JWTクレーム名：
uptime
稼働時間
Claim Key:
主張キー：
261
261
Claim Value Type:
請求値タイプ：
uint
uint
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
OEM Authorized Boot
OEM認定ブート
Claim Description:
クレームの説明：
Indicates whether the software booted was OEM authorized
起動されたソフトウェアがOEMが許可されたかどうかを示します
JWT Claim Name:
JWTクレーム名：
oemboot
oemboot
Claim Key:
主張キー：
262
262
Claim Value Type:
請求値タイプ：
bool
ブール
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Debug Status
デバッグステータス
Claim Description:
クレームの説明：
The status of debug facilities
デバッグ設備のステータス
JWT Claim Name:
JWTクレーム名：
dbgstat
dbgstat
Claim Key:
主張キー：
263
263
Claim Value Type:
請求値タイプ：
uint
uint
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Location
位置
Claim Description:
クレームの説明：
The geographic location
地理的位置
JWT Claim Name:
JWTクレーム名：
location
位置
Claim Key:
主張キー：
264
264
Claim Value Type:
請求値タイプ：
map
地図
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
EAT Profile
プロフィールを食べる
Claim Description:
クレームの説明：
The EAT profile followed
その後の食事プロフィールが続きました
JWT Claim Name:
JWTクレーム名：
eat_profile
eat_profile
Claim Key:
主張キー：
265
265
Claim Value Type:
請求値タイプ：
uri or oid
uriまたはoid
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Submodules Section
サブモジュールセクション
Claim Description:
クレームの説明：
The section containing submodules
サブモジュールを含むセクション
JWT Claim Name:
JWTクレーム名：
submods
サブモッド
Claim Key:
主張キー：
266
266
Claim Value Type:
請求値タイプ：
map
地図
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Boot Count
ブートカウント
Claim Description:
クレームの説明：
The number of times the entity or submodule has been booted
エンティティまたはサブモジュールが起動されている回数
JWT Claim Name:
JWTクレーム名：
bootcount
bootcount
Claim Key:
主張キー：
267
267
Claim Value Type:
請求値タイプ：
uint
uint
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Boot Seed
ブートシード
Claim Description:
クレームの説明：
Identifies a boot cycle
ブートサイクルを識別します
JWT Claim Name:
JWTクレーム名：
bootseed
ブートシード
Claim Key:
主張キー：
268
268
Claim Value Type:
請求値タイプ：
bstr
BSTR
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
DLOAs
dloas
Claim Description:
クレームの説明：
Certifications received as Digital Letters of Approval
承認のデジタル文字として受け取った認定
JWT Claim Name:
JWTクレーム名：
dloas
dloas
Claim Key:
主張キー：
269
269
Claim Value Type:
請求値タイプ：
array
配列
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Software Name
ソフトウェア名
Claim Description:
クレームの説明：
The name of the software running in the entity
エンティティで実行されているソフトウェアの名前
JWT Claim Name:
JWTクレーム名：
swname
swname
Claim Key:
主張キー：
270
270
Claim Value Type:
請求値タイプ：
tstr
TSTR
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Software Version
ソフトウェアバージョン
Claim Description:
クレームの説明：
The version of software running in the entity
エンティティで実行されているソフトウェアのバージョン
JWT Claim Name:
JWTクレーム名：
swversion
揺れ
Claim Key:
主張キー：
271
271
Claim Value Type:
請求値タイプ：
array
配列
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Software Manifests
ソフトウェアがマニフェストします
Claim Description:
クレームの説明：
Manifests describing the software installed on the entity
エンティティにインストールされているソフトウェアを説明するマニフェスト
JWT Claim Name:
JWTクレーム名：
manifests
マニフェスト
Claim Key:
主張キー：
272
272
Claim Value Type:
請求値タイプ：
array
配列
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Measurements
測定
Claim Description:
クレームの説明：
Measurements of the software, memory configuration, and such on the entity
エンティティ上のソフトウェア、メモリ構成などの測定
JWT Claim Name:
JWTクレーム名：
measurements
測定
Claim Key:
主張キー：
273
273
Claim Value Type:
請求値タイプ：
array
配列
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Software Measurement Results
ソフトウェア測定の結果
Claim Description:
クレームの説明：
The results of comparing software measurements to reference values
ソフトウェア測定値を参照値と比較した結果
JWT Claim Name:
JWTクレーム名：
measres
測定値
Claim Key:
主張キー：
274
274
Claim Value Type:
請求値タイプ：
array
配列
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
Claim Name:
クレーム名：
Intended Use
目的の使用
Claim Description:
クレームの説明：
The intended use of the EAT
食事の意図的な使用
JWT Claim Name:
JWTクレーム名：
intuse
intuse
Claim Key:
主張キー：
275
275
Claim Value Type:
請求値タイプ：
uint
uint
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9711
RFC 9711
IANA has registered the following new subtypes in the "DEV URN Subtypes" registry [IANA.DEV-URNs] under the "Device Identification" registry group; see [RFC9039].
IANAは、「デバイス識別」レジストリグループの下に「dev urnサブタイプ」レジストリ[iana.dev-urns]に次の新しいサブタイプを登録しています。[RFC9039]を参照してください。
+=========+===================================+===========+
| Subtype | Description | Reference |
+=========+===================================+===========+
| ueid | Universal Entity ID | RFC 9711 |
+---------+-----------------------------------+-----------+
| sueid | Semipermanent Universal Entity ID | RFC 9711 |
+---------+-----------------------------------+-----------+
Table 3: UEID URN Registration
表3：UEID URN登録
The ABNF [RFC5234] [RFC7405] for these two URNs is as follows, where b64ueid is the base64url-encoded binary byte string for the UEID or SUEID:
これら2つのurnのabnf [rfc5234] [rfc7405]は次のとおりです。ここで、b64ueidはueidまたはsueidのbase64urlエンコードバイナリバイト文字列です。
body =/ ueidbody
ueidbody = %s"ueid:" b64ueid
In the "CBOR Tags" registry [IANA.cbor-tags], IANA has allocated the following tag from the Specification Required range, with the present document as the reference.
「CBORタグ」レジストリ[IANA.CBOR-TAGS]では、IANAは次のタグを仕様必要範囲から割り当て、現在のドキュメントを参照として割り当てました。
+=====+===========+=====================+=====================+
| Tag | Data Item | Semantics | Reference |
+=====+===========+=====================+=====================+
| 602 | array | Detached EAT Bundle | RFC 9711, Section 5 |
+-----+-----------+---------------------+---------------------+
Table 4: Detached EAT Bundle Tag Registration
表4：剥離したバンドルタグ登録
IANA has created a new registry titled "Entity Attestation Token (EAT) Intended Uses" under the new "Remote Attestation Procedures (RATS)" registry group. The registry uses the Expert Review registration procedure [RFC8126].
IANAは、新しい「リモート証明手順（RATS）」レジストリグループの下で「エンティティ証明トークン（EAT）を意図した使用」というタイトルの新しいレジストリを作成しました。レジストリは、専門家のレビュー登録手順[RFC8126]を使用しています。
Guidelines for designated experts:
指定された専門家向けのガイドライン：
* Each intended use should be clearly described so a user knows what it means.
* 意図された各使用は、ユーザーがそれが何を意味するかを知っているので、明確に説明する必要があります。
* Each intended use should be distinct from others that are registered.
* それぞれの使用は、登録されている他のものとは異なる必要があります。
* Point squatting is discouraged.
* ポイントスクワッティングは落胆します。
The three columns for the registry are:
レジストリの3つの列は次のとおりです。
1. Value: This is a unique integer that is used to identify the intended use in CBOR-encoded tokens.
1. 値：これは、CBORエンコードトークンでの使用を識別するために使用されるユニークな整数です。
2. Description: This is one or more text paragraphs that sufficiently define what the intended use means. It may also be a reference to another document.
2. 説明：これは、意図された使用の意味を十分に定義する1つ以上のテキスト段落です。また、別のドキュメントへの参照かもしれません。
3. Reference: This field contains a reference to the defining specification.
3. 参照：このフィールドには、定義仕様への参照が含まれています。
The following 5 values represent the initial content of the registry. Note that 0 will be marked as "reserved" for the CBOR value, and the maximum CBOR value for assignment is 255.
次の5つの値は、レジストリの初期コンテンツを表します。0はCBOR値の「予約済み」としてマークされ、割り当ての最大CBOR値は255であることに注意してください。
1 -- Generic:
1-ジェネリック：
Generic attestation describes an application where the EAT consumer requires the most up-to-date security assessment of the attesting entity. It is expected that this is the most commonly used application of EAT.
一般的な証明は、EAT消費者が証明エンティティの最も最新のセキュリティ評価を必要とするアプリケーションを説明しています。これは、最も一般的に使用される食事のアプリケーションであると予想されます。
2 -- Registration:
2-登録：
Entities that are registering for a new service may be expected to provide an attestation as part of the registration process. This "intuse" setting indicates that the attestation is not intended for any use but registration.
新しいサービスに登録しているエンティティは、登録プロセスの一部として証明を提供することが期待される場合があります。この「intuse」設定は、登録以外の使用を目的としたものではないことを示しています。
3 -- Provisioning:
3-プロビジョニング：
Entities may be provisioned with different values or settings by an EAT consumer. Examples include key material or device management trees. The consumer may require an EAT to assess entity security state of the entity prior to provisioning.
エンティティは、Eat Consumerによって異なる値または設定でプロビジョニングされる場合があります。例には、キーマテリアルまたはデバイス管理ツリーが含まれます。消費者は、プロビジョニング前にエンティティセキュリティのエンティティの状態を評価するために食事を必要とする場合があります。
4 -- Certificate Issuance:
4-証明書発行：
Certification Authorities (CAs) may require attestation results (which in a background check model might require receiving evidence to be passed to a verifier) to make decisions about the issuance of certificates. An EAT may be used as part of the certificate signing request (CSR).
認証当局（CAS）には、証明書の発行に関する決定を下すために、認証当局（CAS）が証明された結果（バックグラウンドチェックモデルで証拠を受信する必要がある場合があります）を必要とする場合があります。EATは、証明書署名リクエスト（CSR）の一部として使用できます。
5 -- Proof of Possession:
5-所有証明：
An EAT consumer may require an attestation as part of an accompanying proof-of-possession (PoP) application. More precisely, a PoP transaction is intended to provide the recipient with cryptographically verifiable proof that the sender has possession of a key. This kind of attestation may be necessary to verify the security state of the entity storing the private key used in a PoP application.
食事消費者は、付随するプルーフオブポッセッション（POP）アプリケーションの一部として証明を必要とする場合があります。より正確には、ポップトランザクションは、送信者がキーを所有しているという暗号化的に検証可能な証拠を受信者に提供することを目的としています。この種の証明は、ポップアプリケーションに使用される秘密鍵を保存するエンティティのセキュリティ状態を検証するために必要になる場合があります。
[DLOA] GlobalPlatform, "GlobalPlatform Card: Digital Letter of
Approval", Public Release Version 1.0, GPC_SPE_095,
November 2015, <https://globalplatform.org/wp-
content/uploads/2015/12/
GPC_DigitalLetterOfApproval_v1.0.pdf>.
[IANA.cbor-tags]
IANA, "CBOR Tags",
<https://www.iana.org/assignments/cbor-tags>.
[IANA.COSE.Algorithms]
IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose>.
[IANA.CWT.Claims]
IANA, "CBOR Web Token (CWT) Claims",
<https://www.iana.org/assignments/cwt>.
[IANA.DEV-URNs]
IANA, "DEV URN Subtypes",
<https://www.iana.org/assignments/device-identification>.
[IANA.JWT.Claims]
IANA, "JSON Web Token Claims",
<https://www.iana.org/assignments/jwt>.
[PEN] IANA, "Private Enterprise Numbers (PENs)",
<https://www.iana.org/assignments/enterprise-numbers/>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RFC 4517,
DOI 10.17487/RFC4517, June 2006,
<https://www.rfc-editor.org/info/rfc4517>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[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>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[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>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[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>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9090] Bormann, C., "Concise Binary Object Representation (CBOR)
Tags for Object Identifiers", RFC 9090,
DOI 10.17487/RFC9090, July 2021,
<https://www.rfc-editor.org/info/rfc9090>.
[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>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[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>.
[ThreeGPP.IMEI]
3GPP, "Numbering, addressing and identification", Version
19, 3GPP TS 23.003, September 2024,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=729>.
[W3C.GeoLoc]
Cáceres, M. and R. Grant, "Geolocation", W3C
Recommendation, September 2024,
<https://www.w3.org/TR/geolocation/>.
[WGS84] National Geospatial-Intelligence Agency (NGA), "Department
of Defense World Geodetic System 1984: Its Definition and
Relationships with Local Geodetic Systems",
NGA.STND.0036_1.0.0_WGS84, July 2014,
<https://nsgreg.nga.mil/doc/view?i=4085>.
[BirthdayAttack]
Wikipedia, "Birthday attack", October 2024,
<https://en.wikipedia.org/w/
index.php?title=Birthday_attack&oldid=1249270346>.
[CBOR.Certs]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
M. Furuhed, "CBOR Encoded X.509 Certificates (C509
Certificates)", Work in Progress, Internet-Draft, draft-
ietf-cose-cbor-encoded-cert-13, 3 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-13>.
[CC-Example]
Eurosmart, "Secure Sub-System in System-on-Chip (3S in
SoC) Protection Profile", Version 1.8, October 2023,
<https://commoncriteriaportal.org/nfs/ccpfiles/files/
ppfiles/pp0117V2b_pdf.pdf>.
[EAT-GitHub]
"The Entity Attestation Token (EAT)", commit 62c726b,
January 2024, <https://github.com/ietf-rats-wg/eat>.
[EAT.media-types]
Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media
Types", Work in Progress, Internet-Draft, draft-ietf-rats-
eat-media-type-12, 3 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
eat-media-type-12>.
[GP-Example]
GlobalPlatform, "GlobalPlatform Technology: TEE
Certification Process", Public Release Version 2.0,
GP_PRO_023, January 2021, <https://globalplatform.org/wp-
content/uploads/2021/01/
GP_TEECertificationProcess_v2.0_PublicRelease.pdf>.
[IEEE-RA] IEEE, "IEEE Registration Authority",
<https://standards.ieee.org/products-services/regauth/
index.html>.
[IEEE.802-2014]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE Std 802-2014,
DOI 10.1109/IEEESTD.2014.6847097, June 2014,
<https://ieeexplore.ieee.org/document/6847097>.
[IEEE.802.1AR]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Secure Device Identity", IEEE Std 802.1AR-2018,
DOI 10.1109/IEEESTD.2018.8423794, August 2018,
<https://ieeexplore.ieee.org/document/8423794>.
[JTAG] IEEE, "IEEE Standard for Reduced-Pin and Enhanced-
Functionality Test Access Port and Boundary-Scan
Architecture", IEEE Std 1149.7-2009,
DOI 10.1109/IEEESTD.2010.5412866, February 2010,
<https://ieeexplore.ieee.org/document/5412866>.
[OUI.Guide]
IEEE, "Guidelines for Use of Extended Unique Identifier
(EUI), Organizationally Unique Identifier (OUI), and
Company ID (CID)", August 2017,
<https://standards.ieee.org/content/dam/ieee-
standards/standards/web/documents/tutorials/eui.pdf>.
[OUI.Lookup]
IEEE, "IEEE Registration Authority: Assignments",
<https://regauth.standards.ieee.org/standards-ra-web/pub/
view.html#registries>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC9039] Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource
Names for Device Identifiers", RFC 9039,
DOI 10.17487/RFC9039, June 2021,
<https://www.rfc-editor.org/info/rfc9039>.
[RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header Parameters for Carrying and Referencing X.509
Certificates", RFC 9360, DOI 10.17487/RFC9360, February
2023, <https://www.rfc-editor.org/info/rfc9360>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/info/rfc9562>.
[UCCS] Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
Work in Progress, Internet-Draft, draft-ietf-rats-uccs-12,
3 November 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-uccs-12>.
Most examples are shown as a Claims-Set that would be a payload for a CWT, a JWT, a detached EAT bundle, or future token types. The signing is left off so the Claims-Set is easier to see. Some examples of signed tokens are also given.
ほとんどの例は、CWT、JWT、分離したEATバンドル、または将来のトークンタイプのペイロードとなるクレームセットとして示されています。署名は中断されているため、クレームセットを見るのが簡単です。署名されたトークンの例もいくつか与えられています。
This is a simple attestation of a TEE; it includes a manifest that is a payload CoSWID to describe the TEE's software.
これはティーの簡単な証明です。これには、ティーのソフトウェアを説明するためのペイロードコスウィッドであるマニフェストが含まれています。
/ This is an EAT payload that describes a simple TEE. /
{
/ eat_nonce / 10: h'48df7b172d70b5a18935d0460a73dd71',
/ oemboot / 262: true,
/ dbgstat / 263: 2, / disabled-since-boot /
/ manifests / 272: [
[
258, / CoAP Content ID for CoSWID /
/ This is a byte-string-wrapped /
/ payload CoSWID. It gives the TEE /
/ software name, the version, and /
/ the name of the file it is in. /
/ {0: "3a24", /
/ 12: 1, /
/ 1: "Acme TEE OS", /
/ 13: "3.1.4", /
/ 2: [{31: "Acme TEE OS", 33: 1}, /
/ {31: "Acme TEE OS", 33: 2}], /
/ 6: { /
/ 17: { /
/ 24: "acme_tee_3.exe" /
/ } /
/ } /
/ } /
h' a60064336132340c01016b
41636d6520544545204f530d65332e31
2e340282a2181f6b41636d6520544545
204f53182101a2181f6b41636d652054
4545204f5318210206a111a118186e61
636d655f7465655f332e657865'
]
]
}
/ This is a payload CoSWID created by the software (SW) vendor. All /
/ this does is name the TEE SW, name its version, and list the one /
/ file that makes up the TEE. /
1398229316({
/ Unique CoSWID ID / 0: "3a24",
/ tag-version / 12: 1,
/ software-name / 1: "Acme TEE OS",
/ software-version / 13: "3.1.4",
/ entity / 2: [
{
/ entity-name / 31: "Acme TEE OS",
/ role / 33: 1 / tag-creator /
},
{
/ entity-name / 31: "Acme TEE OS",
/ role / 33: 2 / software-creator /
}
],
/ payload / 6: {
/ ...file / 17: {
/ ...fs-name / 24: "acme_tee_3.exe"
}
}
})
/ This example shows use of submodules to give information /
/ about the chip, board, and overall device. /
/ /
/ The main attestation is associated with the chip /
/ containing the CPU and running the main OS. It is what /
/ has the keys and produces the token. /
/ /
/ The board is made by a different vendor than the chip; /
/ perhaps it is some generic IoT board. /
/ /
/ The device is some specific appliance that is made by a /
/ different vendor than either the chip or the board. /
/ /
/ Here, the board and device submodules aren't the typical /
/ target environments as described by RATS Architecture /
/ (RFC 9334), but they are a valid use of submodules. /
{
/ eat_nonce / 10: h'e253cabedc9eec24ac4e25bcbeaf7765',
/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',
/ oemid / 258: h'894823', / IEEE OUI format OEM ID /
/ hwmodel / 259: h'549dcecc8b987c737b44e40f7c635ce8'
/ Hash of chip model name /,
/ hwversion / 260: ["1.3.4", 1], / Multipartnumeric /
/ swname / 270: "Acme OS",
/ swversion / 271: ["3.5.5", 1],
/ oemboot / 262: true,
/ dbgstat / 263: 3, / permanent-disable /
/ timestamp (iat) / 6: 1526542894,
/ submods / 266: {
/ A submodule to hold some claims about the circuit board /
"board" : {
/ oemid / 258: h'9bef8787eba13e2c8f6e7cb4b1f4619a',
/ hwmodel / 259: h'ee80f5a66c1fb9742999a8fdab930893'
/ Hash of board module name /,
/ hwversion / 260: ["2.0a", 2] / multipartnumeric+sfx /
},
/ A submodule to hold claims about the overall device /
"device" : {
/ oemid / 258: 61234, / PEN Format OEM ID /
/ hwversion / 260: ["4.0", 1] / Multipartnumeric /
}
}
}
/ This is an example of a token produced by a hardware block /
/ purposely built for attestation. Only the nonce claim changes /
/ from one attestation to the next as the rest come from either /
/ the hardware directly or from one-time-programmable memory /
/ (e.g., a fuse). The entire encoded token is 47 bytes, 8 of /
/ which are the nonce and 16 of which are the UEID. /
{
/ eat_nonce / 10: h'd79b964ddd5471c1393c8888',
/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',
/ oemid / 258: 64242, / Private Enterprise Number /
/ oemboot / 262: true,
/ dbgstat / 263: 3, / disabled-permanently /
/ hwversion / 260: [ "3.1", 1 ] / Type is multipartnumeric /
}
/ This is an attestation of a public key and the key store /
/ implementation that protects and manages it. The key store /
/ implementation is in a security-oriented execution /
/ environment separate from the high-level OS (HLOS), for /
/ example, a Trusted Execution Environment (TEE). The key /
/ store is the attester. /
/ /
/ There is some attestation of the HLOS, just version and /
/ boot and debug status. It is a Claims-Set submodule because /
/ it has a lower security level than the key store. The key /
/ store's implementation has access to info about the HLOS, so /
/ it is able to include it. /
/ /
/ A key and an indication of the user authentication given to /
/ allow access to the key is given. The labels for these are /
/ in the private space as this is a hypothetical example, /
/ not part of a standard protocol. /
{
/ eat_nonce / 10: h'99b67438dba40743266f70bf75feb1026d5134
97a229bfe8',
/ oemboot / 262: true,
/ dbgstat / 263: 2, / disabled-since-boot /
/ manifests / 272: [
[ 258, / CoAP Content ID. /
h'a600683762623334383766
0c000169436172626f6e6974650d6331
2e320e0102a2181f75496e6475737472
69616c204175746f6d6174696f6e1821
02'
]
/ Above is an encoded CoSWID /
/ with the following data /
/ SW Name: "Carbonite" /
/ SW Vers: "1.2" /
/ SW Creator: /
/ "Industrial Automation" /
],
/ exp / 4: 1634324274, / 2021-10-15T18:57:54Z /
/ iat / 6: 1634317080, / 2021-10-15T16:58:00Z /
-80000 : "fingerprint",
-80001 : { / The key -- A COSE_Key /
/ kty / 1: 2, / EC2, elliptic curve with x & y/
/ kid / 2: h'36675c206f96236c3f51f54637b94ced',
/ curve / -1: 2, / curve is P-256 /
/ x-coord / -2: h'65eda5a12577c2bae829437fe338701a
10aaa375e1bb5b5de108de439c08551d',
/ y-coord / -3: h'1e52ed75701163f7f9e40ddf9f341b3d
c9ba860af7e0ca7ca7e9eecd0084d19c'
},
/ submods / 266 : {
"HLOS" : { / submod for high-level OS /
/ eat_nonce / 10: h'8b0b28782a23d3f6',
/ oemboot / 262: true,
/ manifests / 272: [
[ 258, / CoAP Content ID. /
h'a600687337
6537346b78380c000168
44726f6964204f530d65
52322e44320e0302a218
1F75496E647573747269
616c204175746f6d6174
696f6e182102'
]
/ Above is an encoded CoSWID /
/ with the following data: /
/ SW Name: "Droid OS" /
/ SW Vers: "R2.D2" /
/ SW Creator: /
/ "Industrial Automation"/
]
}
}
}
This is a simple token that might be for an IoT device. It includes CoSWID format measurements of the SW. The CoSWID is byte string wrapped in the token and is also shown in diagnostic form.
これは、IoTデバイス用の単純なトークンです。SWのCoswid形式測定が含まれています。Coswidはトークンに巻かれたバイト文字列であり、診断形式でも表示されます。
/ This EAT payload is for an IoT device with a TEE. The attestation /
/ is produced by the TEE. There is a submodule for the IoT OS (the /
/ main OS of the IoT device that is not as secure as the TEE). The /
/ submodule contains claims for the IoT OS. The TEE also measures /
/ the IoT OS and puts the measurements in the submodule. /
{
/ eat_nonce / 10: h'5e19fba4483c7896',
/ oemboot / 262: true,
/ dbgstat / 263: 2, / disabled-since-boot /
/ oemid / 258: h'8945ad', / IEEE CID based /
/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',
/ submods / 266: {
"OS" : {
/ oemboot / 262: true,
/ dbgstat / 263: 2, / disabled-since-boot /
/ measurements / 273: [
[
258, / CoAP Content ID /
/ This is a byte-string-wrapped /
/ evidence CoSWID. It has /
/ hashes of the main files of /
/ the IoT OS. /
h'a600663463613234350c
17016d41636d6520522d496f542d4f
530d65332e312e3402a2181f724163
6d6520426173652041747465737465
7218210103a11183a318187161636d
655f725f696f745f6f732e65786514
1a0044b349078201582005f6b327c1
73b4192bd2c3ec248a292215eab456
611bf7a783e25c1782479905a31818
6d7265736f75726365732e72736314
1a000c38b10782015820c142b9aba4
280c4bb8c75f716a43c99526694caa
be529571f5569bb7dc542f98a31818
6a636f6d6d6f6e2e6c6962141a0023
3d3b0782015820a6a9dcdfb3884da5
f884e4e1e8e8629958c2dbc7027414
43a913e34de9333be6'
]
]
}
}
}
/ This is an evidence CoSWID created for the "Acme R-IoT-OS" /
/ that is created by the "Acme Base Attester" (both fictitious /
/ names). It provides measurements of the SW (other than the /
/ attester SW) on the device. /
1398229316({
/ Unique CoSWID ID / 0: "4ca245",
/ tag-version / 12: 23, / Attester-maintained counter /
/ software-name / 1: "Acme R-IoT-OS",
/ software-version / 13: "3.1.4",
/ entity / 2: {
/ entity-name / 31: "Acme Base Attester",
/ role / 33: 1 / tag-creator /
},
/ evidence / 3: {
/ ...file / 17: [
{
/ ...fs-name / 24: "acme_r_iot_os.exe",
/ ...size / 20: 4502345,
/ ...hash / 7: [
1, / SHA-256 /
h'05f6b327c173b419
2bd2c3ec248a2922
15eab456611bf7a7
83e25c1782479905'
]
},
{
/ ...fs-name / 24: "resources.rsc",
/ ...size / 20: 800945,
/ ...hash / 7: [
1, / SHA-256 /
h'c142b9aba4280c4b
b8c75f716a43c995
26694caabe529571
f5569bb7dc542f98'
]
},
{
/ ...fs-name / 24: "common.lib",
/ ...size / 20: 2309435,
/ ...hash / 7: [
1, / SHA-256 /
h'a6a9dcdfb3884da5
f884e4e1e8e86299
58c2dbc702741443
a913e34de9333be6'
]
}
]
}
})
This is a JSON-encoded payload that might be the output of a verifier that evaluated the IoT Attestation example immediately above.
これは、上記のIoT証明の例を評価した検証剤の出力である可能性のあるJSONエンコードされたペイロードです。
This particular verifier knows enough about the TEE attester to be able to pass claims such as debug status directly through to the relying party. The verifier also knows the reference values for the measured software components and is able to check them. It informs the relying party that they were correct in the "measres" claim. "Trustus Verifications" is the name of the service that verifies the software component measurements.
この特定の検証者は、ティーアテスターについて十分に知っており、デバッグステータスなどのクレームを依存パーティーに直接合格させることができます。検証者は、測定されたソフトウェアコンポーネントの参照値も把握しており、それらを確認できます。頼っている当事者に、「測定者」の主張で正しいことを通知します。「Trustus Verifications」は、ソフトウェアコンポーネントの測定値を検証するサービスの名前です。
{
"eat_nonce": "jkd8KL-8xQk",
"oemboot": true,
"dbgstat": "disabled-since-boot",
"oemid": "iUWt",
"ueid": "AZj1Ck_2wFhhyIYNE6Y4",
"swname": "Acme R-IoT-OS",
"swversion": [
"3.1.4"
],
"measres": [
[
"Trustus Measurements",
[
[
"all",
"success"
]
]
]
]
}
The lines in this example are wrapped per [RFC8792].
この例の線は、[RFC8792]ごとにラップされています。
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"eat_nonce": "lI-IYNE6Rj6O",
"ueid": "AJj1Ck_2wFhhyIYNE6Y46g==",
"secboot": true,
"dbgstat": "disabled-permanently",
"iat": 1526542894,
"submods": {
"Android App Foo": {
"swname": "Foo.app"
},
"Secure Element Eat": [
"CBOR",
"2D3ShEOhASagWGaoCkiUj4hg0TpGPhkBAFABmPUKT_bAWGHIhg0TpjjqGQ\
ECGfryGQEFBBkBBvUZAQcDGQEEgmMzLjEBGQEKoWNURUWCL1gg5c-V_ST6txRGdC3VjU\
Pa4XjlX-K5QpGpKRCC_8JjWgtYQPaQywOIZ3-mJKN3X9fLxOhAnsmBa-MvpHRzOw-Ywn\
-67bvJljuctezAPD41s6_At7NbSV3qwJlxIuqGfwe41es="
],
"Linux Android": {
"swname": "Android"
},
"Subsystem J": [
"JWT",
"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJKLUF0dGVzd\
GVyIiwiaWF0IjoxNjUxNzc0ODY4LCJleHAiOm51bGwsImF1ZCI6IiIsInN1YiI6IiJ9.\
gjw4nFMhLpJUuPXvMPzK1GMjhyJq2vWXg1416XKszwQ"
]
}
}
This is a simple CWT-format token signed with the Elliptic Curve Digital Signature Algorithm (ECDSA).
これは、Elliptic Curve Digital Signature Algorithm（ECDSA）で署名された単純なCWT形式のトークンです。
/ This is a full CWT-format token. The payload is the /
/ attestation hardware block in Appendix A.1.3 of /
/ RFC 9711. The main structure that is visible is /
/ that of the COSE_Sign1. /
61( 18( [
h'A10126', / protected headers /
{}, / empty unprotected headers /
h'A60A4CD79B964DDD5471C1393C88881901005001
98F50A4FF6C05861C8860D13A638EA19010219FA
F2190106F5190107031901048263332E3101', / payload /
h'9B9B2F5E470000F6A20C8A4157B5763FC45BE759
9A5334028517768C21AFFB845A56AB557E0C8973
A07417391243A79C478562D285612E292C622162
AB233787' / signature /
] ) )
In this detached EAT bundle, the main token is produced by a hardware (HW) attestation block. The detached Claims-Set is produced by a TEE and is largely identical to the simple TEE example in Appendix A.1.1. The TEE digests its Claims-Set and feeds that digest to the HW block.
この分離したEATバンドルでは、メイントークンはハードウェア（HW）の証明ブロックによって生成されます。分離されたクレームセットはティーによって生成され、付録A.1.1の単純なティーの例とほぼ同じです。ティーはそのクレームセットを消化し、HWブロックに消化するフィードを与えます。
In a better example, the attestation produced by the HW block would be a CWT and thus signed and secured by the HW block. Since the signature covers the digest from the TEE, that Claims-Set is also secured.
より良い例では、HWブロックによって生成された証明はCWTであり、したがってHWブロックによって署名および保護されます。署名はティーからのダイジェストをカバーするため、クレームセットも確保されます。
The detached EAT bundle itself can be assembled by untrusted software.
分離したEATバンドル自体は、信頼できないソフトウェアで組み立てることができます。
/ This is a detached EAT bundle tag. /
602([
/ The first part is a full EAT token with claims like nonce /
/ and UEID. Most importantly, it includes a submodule that /
/ is a detached digest, which is the hash of the "TEE" /
/ claims set in the next part of the detached EAT bundle. /
/ The COSE payload is as follows: /
/ { /
/ 10: h'948F8860D13A463E', /
/ 256: h'0198F50A4FF6C05861C8860D13A638EA', /
/ 258: 64242, /
/ 262: true, /
/ 263: 3, /
/ 260: ["3.1", 1], /
/ 266: { /
/ "TEE": [ /
/ -16, /
/ h'ab86f765643aabfd09c84eebe150b7f6 /
/ 1bc24804cee75e90c5f99cb850fe808f' /
/ ] /
/ } /
/ } /
h'D83DD28443A10126A05866A80A48948F8860D13A463E1901
00500198F50A4FF6C05861C8860D13A638EA19010219FAF2
19010504190106F5190107031901048263332E310119010A
A163544545822F58208DEF652F47000710D9F466A4C666E2
09DD74F927A1CEA352B03143E188838ABE5840F690CB0388
677FA624A3775FD7CBC4E8409EC9816BE32FA474733B0F98
C27FBAEDBBC9963B9CB5ECC03C3E35B3AFC0B7B35B495DEA
C0997122EA867F07B8D5EB',
{
/ A CBOR-encoded byte-string-wrapped EAT claims-set. /
/ It contains claims for a simple TEE attestation. /
"TEE" : h'a40a5048df7b172d70b5a18935d0460a73dd7119
0106f51901070219011081821901025858a60064
336132340c01016b41636d6520544545204f530d
65332e312e340282a2181f6b41636d6520544545
204f53182101a2181f6b41636d6520544545204f
5318210206a111a118186e61636d655f7465655f
332e657865'
}
])
/ This example contains a submodule that is a detached digest, /
/ which is the hash of a Claims-Set conveyed outside this /
/ token. It is also an example of a token from an attestation /
/ hardware block. /
{
/ eat_nonce / 10: h'3515744961254b41a6cf9c02',
/ ueid / 256: h'0198f50a4ff6c05861c8860d13a638ea',
/ oemid / 258: 64242, / Private Enterprise Number /
/ oemboot / 262: true,
/ dbgstat / 263: 3, / disabled-permanently /
/ hwversion / 260: [ "3.1", 1 ], / multipartnumeric /
/ submods/ 266: {
"TEE": [ / detached digest submod /
-16, / SHA-256 /
h'ab86f765643aabfd09c8
4eebe150b7f61bc24804
cee75e90c5f99cb850fe
808f'
]
}
}
In this bundle, there are two detached Claims-Sets: "Audio Subsystem" and "Graphics Subsystem". The JWT at the start of the bundle has detached signature submodules with hashes that cover these two Claims-Sets. The JWT itself is protected using the Hashed Message Authentication Code (HMAC) with a key of "xxxxxx".
このバンドルには、「オーディオサブシステム」と「グラフィックサブシステム」という2つの分離されたクレームセットがあります。バンドルの開始時のJWTは、これら2つのクレームセットをカバーするハッシュを備えた署名サブモジュールを分離しました。JWT自体は、「xxxxxx」のキーを使用して、ハッシュされたメッセージ認証コード（HMAC）を使用して保護されています。
The lines in this example are wrapped per [RFC8792].
この例の線は、[RFC8792]ごとにラップされています。
=============== NOTE: '\' line wrapping per RFC 8792 ================
[
[
"JWT",
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlYXRfbm9uY2UiOiJ5dT\
c2Tk44SXVWNmUiLCJzdWJtb2RzIjp7IkF1ZGlvIFN1YnN5c3RlbSI6WyJESUdFU1QiLF\
siU0hBLTI1NiIsIkZSRW4yVlR3aTk5cWNNRVFzYmxtTVFnM2I1b2ZYUG5OM1BJYW5CME\
5RT3MiXV0sIkdyYXBoaWNzIFN1YnN5c3RlbSI6WyJESUdFU1QiLFsiU0hBLTI1NiIsIk\
52M3NqUVU3Q1Z0RFRka0RTUlhWcFZDNUNMVFBCWmVQWWhTLUhoVlZWMXMiXV19fQ.FYs\
7R-TKhgAk85NyCOPQlbtGGjFM_3chnhBEOuM6qCo"
],
{
"Audio Subsystem" : "ewogICAgImVhdF9ub25jZSI6ICJsSStJWU5FNlJ\
qNk8iLAogICAgInVlaWQiOiAiQWROSlU0b1lYdFVwQStIeDNqQTcvRFEiCiAgICAib2V\
taWQiOiAiaVVXdCIsCiAgICAib2VtYm9vdCI6IHRydWUsIAogICAgInN3bmFtZSI6ICJ\
BdWRpbyBQcm9jZXNzb3IgT1MiCn0K",
"Graphics Subsystem" : "ewogICAgImVhdF9ub25jZSI6ICJZWStJWU5F\
NlJqNk8iLAogICAgInVlaWQiOiAiQWVUTUlRQ1NVMnhWQmtVdGlndHU3bGUiCiAgICAi\
b2VtaWQiOiA3NTAwMCwKICAgICJvZW1ib290IjogdHJ1ZSwgCiAgICAic3duYW1lIjog\
IkdyYXBoaWNzIE9TIgp9Cg"
}
]
This calculation is to determine the probability of a collision of type 0x01 UEIDs given the total possible entity population and the number of entities in a particular entity management database.
この計算は、総可能性のあるエンティティ母集団と特定のエンティティ管理データベースのエンティティの数を考慮して、タイプ0x01 UEIDの衝突の確率を決定することです。
Three different-sized databases are considered. The number of devices per person roughly models non-personal devices such as traffic lights, devices in stores they shop in, facilities they work in, and so on, even considering individual light bulbs. A device may have individually attested subsystems, for example, parts of a car or a mobile phone. It is assumed that the largest database will have at most 10% of the world's population of devices. Note that databases that handle more than a trillion records exist today.
3つの異なるサイズのデータベースが考慮されます。1人あたりのデバイスの数は、個々の電球を考慮して、交通灯、買い物をする店舗のデバイス、施設などのデバイスなど、大まかに非個人的なデバイスをモデル化しています。デバイスには、車や携帯電話の一部など、個別にサブシステムが証明されている場合があります。最大のデータベースには、世界のデバイス人口の最大10％があると想定されています。今日、1兆以上のレコードを処理するデータベースが存在することに注意してください。
The trillion-record database size models an easy-to-imagine reality over the next decades. The quadrillion-record database is roughly at the limit of what is imaginable and should probably be accommodated. The 100 quadrillion database is highly speculative perhaps involving nanorobots for every person, livestock animals, and domesticated birds. It is included to round out the analysis.
数兆のデータベースサイズは、今後数十年にわたって想像しやすい現実をモデル化しています。Quadrillion-Recordデータベースは、想像できるものの限界にあり、おそらく対応する必要があります。100倍のデータベースは、おそらくすべての人、家畜動物、および飼いならされた鳥のためにナノロボットを含む非常に投機的です。分析を締めくくるために含まれています。
Note that the items counted here certainly do not have IP addresses and are not individually connected to the network. They may be connected to internal buses, via serial links, via Bluetooth, and so on. This is not the same problem as sizing IP addresses.
ここで数えられるアイテムには確かにIPアドレスがなく、ネットワークに個別に接続されていないことに注意してください。それらは、シリアルリンクを介して、Bluetoothを介して内部バスに接続される場合があります。これは、IPアドレスのサイズと同じ問題ではありません。
+=========+===========+=============+==========+=================+
| People | Devices/ | Subsystems/ | Database | Database Size |
| | Person | Device | Portion | |
+=========+===========+=============+==========+=================+
| 10 | 100 | 10 | 10% | trillion |
| billion | | | | (10^12) |
+---------+-----------+-------------+----------+-----------------+
| 10 | 100,000 | 10 | 10% | quadrillion |
| billion | | | | (10^15) |
+---------+-----------+-------------+----------+-----------------+
| 100 | 1,000,000 | 10 | 10% | 100 quadrillion |
| billion | | | | (10^17) |
+---------+-----------+-------------+----------+-----------------+
Table 5: Entity Database Size Examples
表5：エンティティデータベースサイズの例
This is conceptually similar to the Birthday Problem where m is the number of possible birthdays (always 365) and k is the number of people. It is also conceptually similar to the Birthday Attack where collisions of the output of hash functions are considered.
これは概念的には誕生日の問題に似ています。Mは誕生日の可能性があり（常に365）、Kは人の数です。また、概念的には、ハッシュ関数の出力の衝突が考慮される誕生日攻撃に似ています。
The proper formula for the collision calculation is:
衝突計算の適切な式は次のとおりです。
p = 1 - e^{-k^2/(2n)}
For this calculation:
この計算のために：
p:
p:
Collision probability
衝突確率
n:
n:
Total possible population
総人口の総
k:
k:
Actual population
実際の人口
However, for the very large values involved here, this formula requires floating-point precision higher than commonly available in calculators and software, so this simple approximation is used. See [BirthdayAttack].
ただし、ここに関係する非常に大きな値の場合、この式には、計算機やソフトウェアで一般的に利用可能なフローティングポイント精度が必要なため、この単純な近似が使用されます。[BirthndAttack]を参照してください。
p = k^2 / 2n
For this calculation:
この計算のために：
p:
p:
Collision probability
衝突確率
n:
n:
Total population based on number of bits in UEID
UEIDのビット数に基づく総人口
k:
k:
Population in a database
データベース内の人口
+=====================+==============+==============+==============+
| Database Size | 128-bit UEID | 192-bit UEID | 256-bit UEID |
+=====================+==============+==============+==============+
| trillion (10^12) | 2 * 10^-15 | 8 * 10^-35 | 5 * 10^-55 |
+---------------------+--------------+--------------+--------------+
| quadrillion (10^15) | 2 * 10^-09 | 8 * 10^-29 | 5 * 10^-49 |
+---------------------+--------------+--------------+--------------+
| 100 quadrillion | 2 * 10^-05 | 8 * 10^-25 | 5 * 10^-45 |
| (10^17) | | | |
+---------------------+--------------+--------------+--------------+
Table 6: UEID Size Options
表6：UEIDサイズのオプション
Next, to calculate the probability of a collision occurring in one year's operation of a database, it is assumed that the database size is in a steady state and that 10% of the database changes per year. For example, a trillion record database would have 100 billion states per year. Each of those states has the above calculated probability of a collision.
次に、データベースの1年間の操作で衝突が発生する可能性を計算するために、データベースサイズは定常状態であり、データベースの10％が年間変化すると想定されています。たとえば、1兆レコードデータベースには年間1,000億州があります。これらの各状態には、上記の衝突の確率があります。
This assumption is a worst-case scenario since it assumes that each state of the database is completely independent from the previous state. In reality, this is unlikely as state changes will be the addition or deletion of a few records.
この仮定は、データベースの各状態が前の状態から完全に独立していると想定しているため、最悪のシナリオです。実際には、州の変更がいくつかのレコードの追加または削除になるため、これはありそうにありません。
The following table gives the time interval until there is a probability of a collision, which is based on there being one tenth of the number of states per year as the number of records in the database.
次の表は、衝突の可能性が生じるまで時間間隔を示します。これは、データベースのレコード数として年間10分の1の状態数があることに基づいています。
t = 1 / ((k / 10) * p)
For this calculation:
この計算のために：
t:
t:
Time until a collision
衝突までの時間
p:
p:
Collision probability for UEID size
UEIDサイズの衝突確率
k:
k:
Database size
データベースサイズ
+=====================+==============+==============+==============+
| Database Size | 128-bit UEID | 192-bit UEID | 256-bit UEID |
+=====================+==============+==============+==============+
| trillion (10^12) | 60,000 years | 10^24 years | 10^44 years |
+---------------------+--------------+--------------+--------------+
| quadrillion (10^15) | 8 seconds | 10^14 years | 10^34 years |
+---------------------+--------------+--------------+--------------+
| 100 quadrillion | 8 | 10^11 years | 10^31 years |
| (10^17) | microseconds | | |
+---------------------+--------------+--------------+--------------+
Table 7: UEID Collision Probability
表7：UEID衝突確率
Clearly, 128 bits is enough for the near future, thus the requirement that type 0x01 UEIDs be a minimum of 128 bits.
明らかに、近い将来128ビットで十分であるため、タイプ0x01 UEIDが最低128ビットであるという要件があります。
There is no requirement for 256 bits today as quadrillion-record databases are not expected in the near future and because this time-to-collision calculation is a very worst-case scenario. A future update of the standard may increase the requirement to 256 bits, so there is a requirement that implementations be able to receive 256-bit UEIDs.
近い将来、およびこの衝突までの計算が非常に最悪のシナリオであるため、Quadrillion-Recordデータベースが予想されないため、今日256ビットには要件はありません。標準の将来の更新により、要件が256ビットに増加する可能性があるため、実装が256ビットのUEIDを受け取ることができるという要件があります。
A UEID is not a Universally Unique Identifier (UUID) [RFC9562] by conscious choice for the following reasons.
UEIDは、以下の理由で意識的な選択により、普遍的にユニークな識別子（UUID）[RFC9562]ではありません。
UUIDs are limited to 128 bits, which may not be enough for some future use cases.
UUIDは128ビットに制限されており、将来のユースケースでは十分ではない場合があります。
Today, cryptographic-quality random numbers are available from common computing platforms. In particular, hardware randomness sources were introduced in CPUs between 2010 and 2015. Operating systems and cryptographic libraries make use of this hardware. Consequently, there is little need for protocols to construct random numbers from multiple sources on their own.
今日、暗号化品質の乱数は、一般的なコンピューティングプラットフォームから入手できます。特に、2010年から2015年の間にハードウェアのランダム性ソースがCPUに導入されました。オペレーティングシステムと暗号化ライブラリは、このハードウェアを利用しています。その結果、プロトコルが複数のソースから乱数を構築する必要はほとんどありません。
Version 4 UUIDs do allow for the use of such cryptographic-quality random numbers, but they do so by mapping into the overall UUID structure of time and clock values. This structure is of no value here yet adds complexity. It also slightly reduces the number of actual bits with entropy.
バージョン4 UUIDでは、このような暗号化品質の乱数を使用することができますが、時間とクロック値の全体的なUUID構造にマッピングすることでそうします。この構造はここではまだ価値がありませんが、複雑さを追加します。また、エントロピーで実際のビット数をわずかに減らします。
The design of UUID accommodates the construction of a unique identifier by the combination of several identifiers that separately do not provide sufficient uniqueness. The design philosophy underlying UEID assumes that this construction is no longer needed, in particular because cryptographic-quality random number generators are readily available. Therefore, hardware, software, and/or manufacturing processes can implement UEID in a simple and direct way.
UUIDの設計は、十分な一意性を個別に提供しないいくつかの識別子の組み合わせにより、一意の識別子の構築に対応します。UEIDの根底にある設計哲学は、特に暗号化品質の乱数ジェネレーターがすぐに利用できるため、この構造はもはや必要ではないと想定しています。したがって、ハードウェア、ソフトウェア、および/または製造プロセスは、UEIDを簡単かつ直接的な方法で実装できます。
Note also that a type 2 UEID (EUI/MAC) is only 7 bytes whereas a UUID is 16.
また、タイプ2 UEID（EUI/MAC）はわずか7バイトであるのに対し、UUIDは16であることに注意してください。
This section describes several distinct ways in which an IEEE Initial Device Identifier (IDevID) [IEEE.802.1AR] relates to EAT, particularly to UEID and SUEID.
このセクションでは、IEEE初期デバイス識別子（IDEVID）[IEEE.802.1AR]が、特にUEIDとSueidに関連するいくつかの異なる方法について説明します。
[IEEE.802.1AR] orients around the definition of an implementation called a "DevID Module". It describes how IDevIDs and LDevIDs are stored, protected, and accessed using a DevID Module. A particular level of defense against attack that should be achieved to be a DevID is defined here. The intent is that IDevIDs and LDevIDs can be used with any network protocol or message format. In these protocols and message formats, the DevID secret is used to sign a nonce or similar to prove the association of the DevID certificates with the device.
[IEEE.802.1AR]「devidモジュール」と呼ばれる実装の定義の周りの方向。IDEVIDとLDEVIDがDevIDモジュールを使用して保存、保護、およびアクセスする方法について説明します。Devidであると達成されるべき攻撃に対する特定の防御レベルは、ここで定義されています。意図は、IDEVIDSとLDEVIDを任意のネットワークプロトコルまたはメッセージ形式で使用できることです。これらのプロトコルとメッセージ形式では、Devid Secretを使用して、Devid証明書とデバイスとの関連性を証明するためにNonCEまたは同様に署名します。
By contrast, EAT standardizes a message format that is sent to a relying party, the very thing that is not defined in [IEEE.802.1AR]. Nor does EAT give details on how keys, data, and such are stored, protected, and accessed. EAT is intended to work with a variety of different on-device implementations ranging from minimal protection of assets to the highest levels of asset protection. It does not define any particular level of defense against attack; instead, it provides a set of security considerations.
対照的に、EATは、[IEEE.802.1AR]で定義されていないまさにそのまさに依存者に送信されるメッセージ形式を標準化します。また、Eatは、キー、データなどが保存、保護、およびアクセスされる方法の詳細を提供しません。EATは、資産の最小限の保護から最高レベルの資産保護まで、さまざまな異なるオンデバイスの実装と連携することを目的としています。攻撃に対する特定のレベルの防御を定義しません。代わりに、一連のセキュリティに関する考慮事項を提供します。
EAT and DevID can be viewed as complimentary when used together or as competing to provide a device identity service.
EATおよびDEVIDは、一緒に使用する場合、またはデバイスのアイデンティティサービスを提供するために競合する場合、無料と見なすことができます。
As described above, EAT standardizes a message format, but [IEEE.802.1AR] does not. Vice versa, EAT does not define a device implementation, but DevID does.
上記のように、EATはメッセージ形式を標準化しますが、[IEEE.802.1AR]は標準化されていません。その逆の場合、Eatはデバイスの実装を定義しませんが、Devidはそうします。
Hence, EAT can be the message format that a DevID is used with. The DevID secret becomes the attestation key used to sign EATs, and the DevID and its certificate chain become the endorsement sent to the verifier.
したがって、Eatは、Devidが使用されるメッセージ形式になります。Devid Secretは、Eatsに署名するために使用される証明キーになり、Devidとその証明書チェーンは検証者に送信される承認になります。
In this case, the EAT and the DevID are likely to both provide a device identifier (e.g., a serial number). In the EAT, it is the UEID (or SUEID). In the DevID (used as an endorsement), it is a device serial number included in the subject field of the DevID certificate. For this use, it is a good idea for the serial numbers to be the same or for the UEID to be a hash of the DevID serial number.
この場合、EATとDEVIDは両方ともデバイス識別子（シリアル番号など）を提供する可能性があります。食事では、それはueid（またはsueid）です。Devid（承認として使用）では、Devid証明書のサブジェクトフィールドに含まれるデバイスシリアル番号です。この使用のために、シリアル番号が同じであるか、UEIDがDevidシリアル番号のハッシュになることをお勧めします。
The UEID, SUEID, and other claims such as OEM ID are equivalent to the secure device identity that is put into the subject field of a DevID certificate. These EAT claims can represent all the same fields and values that can be put in a DevID certificate subject. EAT explicitly and carefully defines a variety of useful claims.
UEID、Sueid、およびOEM IDなどのその他のクレームは、Devid証明書の主題フィールドに配置される安全なデバイスIDと同等です。これらのEATクレームは、Devid証明書の科目に配置できるすべての同じフィールドと値を表すことができます。明示的かつ慎重に食べることは、さまざまな有用な主張を定義します。
EAT secures the conveyance of these claims by having them signed on the device by the attestation key when the EAT is generated. EAT also signs the nonce that gives freshness at this time. Since these claims are signed for every EAT generated, they can include things that vary over time such as GPS location.
EATは、食事が生成されたときに証明キーによってデバイスに署名することにより、これらのクレームの伝達を確保します。また、この時点で新鮮さを与えるノンセにも署名してください。これらのクレームは、生成されたすべての食事に対して署名されているため、GPSの場所など、時間とともに異なるものを含めることができます。
DevID secures the device identity fields by embedding them in a certificate and signing it. The certificate is created once during manufacturing and remains unchanged.
Devidは、証明書に埋め込んで署名することにより、デバイスのIDフィールドを保護します。証明書は製造中に1回作成され、変更されていません。
So in one case, the signing of the identity happens on the device, and in the other case, it happens in a manufacturing facility. However, in both cases, the signing of the nonce that proves the binding to the actual device happens on the device.
したがって、あるケースでは、アイデンティティの署名はデバイスで行われ、他のケースでは製造施設で発生します。ただし、どちらの場合も、実際のデバイスへのバインディングがデバイスで発生することを証明するノンセの署名。
While EAT does not specify how the signing keys, signature process, and storage of the identity values should be secured against attack, an EAT implementation may have equal defenses against attack. One reason EAT uses CBOR is because it is simple enough that a basic EAT implementation can be constructed entirely in hardware. This allows EAT to be implemented with the strongest defenses possible.
Eatは、署名キー、署名プロセス、およびID値の保存方法を攻撃に対して保護する方法を指定していませんが、EATの実装は攻撃に対して等しい防御を持つ可能性があります。EATがCBORを使用する理由の1つは、基本的なEAT実装を完全にハードウェアで構築できるほど簡単であるためです。これにより、可能な限り強力な防御でEATを実装できます。
It is possible to define a way to encode EAT claims in an X.509 certificate. For example, the EAT claims might be mapped to X.509 v3 extensions. It is even possible to stuff a whole CBOR-encoded unsigned EAT token into an X.509 certificate.
X.509証明書でEATクレームをエンコードする方法を定義することができます。たとえば、EATクレームはX.509 V3拡張機能にマッピングされる場合があります。CBORエンコードされた署名されていないEATトークン全体をX.509証明書に詰めることさえ可能です。
If that X.509 certificate is an IDevID or LDevID, it becomes another way to use EAT and DevID together.
そのX.509証明書がIDEVIDまたはLDEVIDである場合、それは食事を使用して一緒に開発する別の方法になります。
Note that the DevID must still be used with an authentication protocol that has a nonce or equivalent. The EAT here is not being used as the protocol to interact with the relying party.
DevIDは、非CEまたは同等の認証プロトコルで引き続き使用する必要があることに注意してください。ここでの食事は、頼りになるパーティーと対話するためのプロトコルとして使用されていません。
In terms of permanence, an IDevID is similar to a UEID in that they do not change over the life of the device. They cease to exist only when the device is destroyed.
永続性の観点から、IDEVIDは、デバイスの寿命にわたって変化しないという点でUEIDに似ています。デバイスが破壊された場合にのみ存在しなくなります。
An SUEID is similar to an LDevID. They change on device life-cycle events.
スイイドはldevidに似ています。デバイスライフサイクルイベントで変更されます。
[IEEE.802.1AR] describes much of this permanence as resistant to attacks that seek to change the ID. IDevID permanence can be described this way because [IEEE.802.1AR] is oriented around the definition of an implementation with a particular level of defense against attack.
[IEEE.802.1AR]この永続性の多くは、IDを変更しようとする攻撃に耐性があると説明しています。[IEEE.802.1AR]は、攻撃に対する特定のレベルの防御を伴う実装の定義を中心に方向付けられているため、このようにして、この方法で説明できます。
EAT is not defined around a particular implementation and must work on a range of devices that have a range of defenses against attack. For EAT, permanence is not defined in terms of resistance to attacks. Instead, it is defined in the context of operational functionality and the device life cycle.
EATは特定の実装を中心に定義されておらず、攻撃に対してさまざまな防御を持つさまざまなデバイスで作業する必要があります。EATの場合、永続性は攻撃に対する抵抗の観点から定義されていません。代わりに、運用機能とデバイスライフサイクルのコンテキストで定義されます。
[RFC8392] was published before CDDL was available and thus is specified in prose, not CDDL. In the following example, CDDL specifies CWT as it is needed to complete this specification. This CDDL also covers the Claims-Set for JWT.
[RFC8392]は、CDDLが利用可能になる前に公開されたため、CDDLではなく散文で指定されています。次の例では、CDDLはこの仕様を完了するために必要なCWTを指定します。このCDDLは、JWTのクレームセットもカバーしています。
Note that Section 4.3.1 requires that the "iat" claim be the type ~time-int (Section 7.2.1), not the type ~time when it is used in an EAT as floating-point values are not allowed for the "iat" claim in EAT.
セクション4.3.1では、「IAT」クレームは、EATの「IAT」請求の場合は、Floating-Point値としてEATで使用されるタイプ〜の時間ではなく、Type〜Time-INT（セクション7.2.1）であることを要求していることに注意してください。
The COSE-related types in this CDDL are defined in [RFC9052].
このCDDLのCOSE関連タイプは、[RFC9052]で定義されています。
This, however, is NOT a normative or standard definition of CWT or JWT in CDDL. The prose in CWT and JWT remains the normative definition. See also [UCCS].
ただし、これはCDDLのCWTまたはJWTの規範的または標準的な定義ではありません。CWTとJWTでの散文は、依然として規範的な定義です。[UCCS]も参照してください。
Claims-Set = {
* $$Claims-Set-Claims
* Claim-Label .feature "extended-claims-label" => any
}
Claim-Label = int / text
string-or-uri = text
$$Claims-Set-Claims //= ( iss-claim-label => string-or-uri )
$$Claims-Set-Claims //= ( sub-claim-label => string-or-uri )
$$Claims-Set-Claims //= ( aud-claim-label => string-or-uri )
$$Claims-Set-Claims //= ( exp-claim-label => ~time )
$$Claims-Set-Claims //= ( nbf-claim-label => ~time )
$$Claims-Set-Claims //= ( iat-claim-label => ~time )
$$Claims-Set-Claims //= ( cti-claim-label => bytes )
iss-claim-label = JC<"iss", 1>
sub-claim-label = JC<"sub", 2>
aud-claim-label = JC<"aud", 3>
exp-claim-label = JC<"exp", 4>
nbf-claim-label = JC<"nbf", 5>
iat-claim-label = JC<"iat", 6>
cti-claim-label = CBOR-ONLY<7> ; jti in JWT: different name and text
JSON-ONLY<J> = J .feature "json"
CBOR-ONLY<C> = C .feature "cbor"
JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C>
; A JWT message is either a JSON Web Signature (JWS) or a JSON Web
; Encryption (JWE) in compact serialization form with the payload
; as a Claims-Set. Compact serialization is the protected headers,
; payload, and signature that are each b64url-encoded and separated
; by a ".". This CDDL simply matches the top-level syntax of a JWS
; or JWE as it is not possible to do more in CDDL.
JWT-Message =
text .regexp "[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+"
; Note that the payload of a JWT is defined in the CDDL description
; of claims-set. That definition is common to CBOR and JSON.
; This is some CDDL describing a CWT at the top level. This is
; not normative. RFC 8392 is the normative definition of CWT.
CWT-Messages = CWT-Tagged-Message / CWT-Untagged-Message
; The payload of the COSE_Message is always a Claims-Set.
; The contents of a CWT tag must always be a COSE tag.
CWT-Tagged-Message = #6.61(COSE_Tagged_Message)
; An untagged CWT may be a COSE tag or not.
CWT-Untagged-Message = COSE_Messages
The following are design considerations that may be helpful to take into account when creating new EAT claims. This is the product of discussion in the RATS Working Group.
以下は、新しいEATクレームを作成する際に考慮に入れるのに役立つ可能性のある設計上の考慮事項です。これは、ラットワーキンググループでの議論の産物です。
EAT reuses the CWT and JWT claims registries. There is no registry exclusively for EAT claims. This is not an update to the expert review criteria for the JWT and CWT claims registries as that would be an overreach for this document.
EAT EAT CWTおよびJWTクレームレジストリを再利用します。EATクレーム専用のレジストリはありません。これは、JWTおよびCWTの請求レジストリの専門家レビュー基準の更新ではありません。
It is a broad goal that EATs can be processed by relying parties in a general way regardless of the type, manufacturer, or technology of the device from which they originate. It is a goal that there be general-purpose verification implementations that can verify tokens for large numbers of use cases with special cases and configurations for different device types. This is a goal of interoperability of the semantics of claims themselves, not just of the signing, encoding, and serialization formats.
これは、発生するデバイスのタイプ、メーカー、またはテクノロジーに関係なく、一般的な方法で当事者に依存することで食べることができる幅広い目標です。さまざまなデバイスタイプの特別なケースと構成を伴う多数のユースケースのトークンを検証できる汎用検証実装があることが目標です。これは、署名、エンコード、シリアル化形式の形式だけでなく、クレーム自体のセマンティクスの相互運用性の目標です。
This is a lofty goal and difficult to achieve broadly as it requires careful definition of claims in a technology-neutral way. Sometimes it will be difficult to design a claim that can represent the semantics of data from very different device types. However, the goal remains even when difficult.
これは高尚な目標であり、テクノロジーに中立な方法で請求を慎重に定義する必要があるため、広く達成することは困難です。非常に異なるデバイスタイプのデータのセマンティクスを表すことができるクレームを設計することが難しい場合があります。ただし、困難な場合でも目標は残ります。
Claims should be defined such that they are not specific to an operating system. They should be applicable to multiple large high-level operating systems from different vendors as well as to multiple small embedded operating systems from multiple vendors and everything in between.
クレームは、オペレーティングシステムに固有のものではないように定義する必要があります。これらは、さまざまなベンダーからの複数の大規模な高レベルオペレーティングシステム、および複数のベンダーとその間のすべての複数の小さな組み込みオペレーティングシステムに適用できる必要があります。
Claims should not be defined such that they are specific to a software environment or programming language.
クレームは、ソフトウェア環境またはプログラミング言語に固有のものであるように定義されるべきではありません。
Claims should not be defined such that they are specific to a chip or particular hardware. For example, they should not just be the contents of some HW status register as it is unlikely that the same HW status register with the same bits exists on a chip of a different manufacturer.
クレームは、それらがチップまたは特定のハードウェアに固有のように定義されるべきではありません。たとえば、同じビットを持つ同じHWステータスレジスタが異なるメーカーのチップに存在する可能性は低いため、HWステータスレジスタの内容だけではないはずです。
The boot and debug state claims in this document are an example of a claim that has been defined in this neutral way.
このドキュメントのブートとデバッグ状態の主張は、この中立的な方法で定義されているクレームの例です。
Many use cases will have EATs generated by some of the most secure hardware and software that exists. Secure Elements and smart cards are examples of this. However, EAT is intended for use in low-security use cases the same as high-security use cases. For example, an app on a mobile device may generate EATs on its own.
多くのユースケースは、存在する最も安全なハードウェアとソフトウェアのいくつかによって生成される食事を持っています。安全な要素とスマートカードは、この例です。ただし、EATは、高セキュリティユースケースと同じセキュリティユースケースで使用することを目的としています。たとえば、モバイルデバイス上のアプリは、それ自体でEatを生成する場合があります。
Claims should be defined and registered based on whether they are useful and interoperable, not based on security level. In particular, there should be no exclusion of claims because they are only used in low-security environments.
クレームは、セキュリティレベルに基づいて、有用で相互運用可能かどうかに基づいて定義および登録する必要があります。特に、低セキュリティ環境でのみ使用されるため、クレームは除外されるべきではありません。
Where possible, claims should use data items, identifiers, and formats that are already standardized. This takes advantage of the expertise put into creating those formats and improves interoperability.
可能であれば、クレームは、既に標準化されているデータ項目、識別子、および形式を使用する必要があります。これにより、これらの形式を作成するための専門知識を活用し、相互運用性を向上させます。
Often, extant claims will not be defined in an encoding or serialization format used by EAT. It is preferred to define a CBOR and JSON encoding for them so that EAT implementations do not require a plethora of encoders and decoders for serialization formats.
多くの場合、現存するクレームは、EATが使用するエンコードまたはシリアル化形式で定義されません。EATの実装では、シリアル化形式のために大量のエンコーダーとデコーダーを必要としないように、CBORとJSONエンコードを定義することが推奨されます。
In some cases, it may be better to use the encoding and serialization as is. For example, signed X.509 certificates and Certificate Revocation Lists (CRLs) can be carried as is in a byte string. This retains interoperability with the extensive infrastructure for creating and processing X.509 certificates and CRLs.
場合によっては、エンコードとシリアル化をそのまま使用する方が良いかもしれません。たとえば、署名されたX.509証明書と証明書の取り消しリスト（CRL）は、バイト文字列のように持ち運ぶことができます。これにより、X.509証明書とCRLを作成および処理するための広範なインフラストラクチャとの相互運用性が保持されます。
It is not always possible or convenient to achieve the above goals, so the definition and use of proprietary claims is an option.
上記の目標を達成することが常に可能であるか便利ではないため、独自の主張の定義と使用が選択肢です。
For example, a device manufacturer may generate a token with proprietary claims intended only for verification by a service offered by that device manufacturer. This is a supported use case.
たとえば、デバイスメーカーは、そのデバイスメーカーが提供するサービスによる検証のみを目的とした独自の請求を含むトークンを生成する場合があります。これはサポートされているユースケースです。
In many cases, proprietary claims will be the easiest and most obvious way to proceed; however, for better interoperability, use of general standardized claims is preferred.
多くの場合、独自の主張は、最も簡単で最も明白な方法です。ただし、相互運用性を向上させるには、一般的な標準化されたクレームの使用が推奨されます。
The verifier must possess the correct key when it performs the cryptographic part of an EAT verification (e.g., verifying the COSE/ JOSE signature). This section describes several ways to identify the verification key. There is not one standard method.
検証者は、食事検証の暗号化部分を実行するときに正しいキーを所有する必要があります（たとえば、COSE/ JOSE署名の検証）。このセクションでは、検証キーを識別するいくつかの方法について説明します。1つの標準的な方法はありません。
The verification key itself may be a public key, a symmetric key, or something complicated in the case of a scheme such as Direct Anonymous Attestation (DAA).
検証キー自体は、直接的な匿名証明（DAA）などのスキームの場合、公開鍵、対称キー、または複雑なものです。
RATS Architecture [RFC9334] describes what is called an endorsement. This is an input to the verifier that is usually the basis of the trust placed in an EAT and the attester that generated it. It may contain the public key for verification of the signature on the EAT, and it may contain implied claims, i.e., those that are passed on to the relying party in attestation results.
RATSアーキテクチャ[RFC9334]は、承認と呼ばれるものを説明しています。これは、通常、食事に配置された信頼とそれを生成したアテスターの基礎である検証者への入力です。食事の署名を検証するための公開鍵を含む場合があり、暗黙の請求、つまり、証明の結果で頼っている当事者に渡された請求を含む場合があります。
There is not yet any standard format(s) for an endorsement. One format that may be used for an endorsement is an X.509 certificate. Endorsement data such as reference values and implied claims can be carried in X.509 v3 extensions. In this use, the public key in the X.509 certificate becomes the verification key, so identification of the endorsement is also identification of the verification key.
承認のための標準形式はまだありません。承認に使用できる形式の1つは、X.509証明書です。参照値や黙示的なクレームなどの承認データは、X.509 V3拡張機能で伝えることができます。この使用では、X.509証明書の公開キーが検証キーになるため、承認の識別も検証キーの識別です。
The verification key identification and establishment of trust in the EAT and the attester may also be by some other means than an endorsement.
検証の重要な識別と食事と攻撃に対する信頼の確立は、承認以外の手段によるものかもしれません。
For the components (attester, verifier, relying party, etc.) of a particular end-to-end attestation system to reliably interoperate, its definition should specify how the verification key is identified. Usually, this will be in the profile document for a particular attestation system.
特定のエンドツーエンドの証明システムのコンポーネント（Attester、Verifier、Relying Partyなど）の場合、確実に相互運用するため、その定義は検証キーの識別方法を指定する必要があります。通常、これは特定の証明システムのプロファイルドキュメントにあります。
See also the security considerations in Section 9.6.
セクション9.6のセキュリティ上の考慮事項も参照してください。
Following is a list of possible methods of key identification. A specific attestation system may employ any one of these or one not listed here.
以下は、重要な識別の可能な方法のリストです。特定の証明システムは、これらのいずれかまたはここにリストされていないものを採用する場合があります。
The following assumes endorsements are X.509 certificates or equivalent and thus does not mention or define any identifier for endorsements in other formats. If such an endorsement format is created, new identifiers for them will also need to be created.
以下は、承認がX.509証明書または同等のものであると仮定しているため、他の形式の承認の識別子は言及または定義しません。そのような承認形式が作成された場合、それらの新しい識別子も作成する必要があります。
The COSE standard header parameter for Key ID (kid) may be used; see [RFC9052] and [RFC7515].
キーID（KID）のCOSE標準ヘッダーパラメーターを使用できます。[RFC9052]および[RFC7515]を参照してください。
COSE leaves the semantics of the key ID open-ended. It could be a record locator in a database, a hash of a public key, an input to a Key Derivation Function (KDF), an Authority Key Identifier (AKI) for an X.509 certificate, or other. The profile document should specify what the key ID's semantics are.
Coseは、キーIDのセマンティクスをオープンエンドに残します。これは、データベース内のレコードロケーター、公開キーのハッシュ、キー派生関数（KDF）への入力、X.509証明書の機関キー識別子（AKI）などです。プロファイルドキュメントは、キーIDのセマンティクスが何であるかを指定する必要があります。
COSE X.509 [RFC9360] and JSON Web Signature [RFC7515] define several header parameters (x5t, x5u,...) for referencing or carrying X.509 certificates, any of which may be used.
COSE X.509 [RFC9360]およびJSON Web Signature [RFC7515]は、X.509証明書を参照または運ぶために、いくつかのヘッダーパラメーター（X5T、X5U、...）を定義します。
The X.509 certificate may be an endorsement and thus carrying additional input to the verifier. It may be just an X.509 certificate, not an endorsement. The same header parameters are used in both cases, and it is up to the attestation system design and the verifier to determine which.
X.509証明書は承認である可能性があり、したがって、検証剤への追加の入力を運ぶことができます。それは単なるX.509証明書であり、承認ではありません。どちらの場合も同じヘッダーパラメーターが使用されており、どちらを決定するのは証明システムの設計と検証剤次第です。
Compressed X.509 and CBOR Native certificates are defined by CBOR Certificates [CBOR.Certs]. These are semantically compatible with X.509 and therefore can be used as an equivalent to X.509 as described above.
圧縮されたX.509およびCBORネイティブ証明書は、CBOR証明書[CBOR.CERTS]によって定義されます。これらはx.509とセマンティックに互換性があるため、上記のようにx.509に相当するものとして使用できます。
These are identified by their own header parameters (c5t, c5u, etc.).
これらは、独自のヘッダーパラメーター（C5T、C5Uなど）によって識別されます。
For some attestation systems, a claim may be reused as a key identifier. For example, the UEID uniquely identifies the entity and therefore can work well as a key identifier or endorsement identifier.
一部の証明システムの場合、主要な識別子として請求が再利用される場合があります。たとえば、UEIDはエンティティを一意に識別するため、キー識別子または承認識別子としてうまく機能します。
An advantage of this is that key identification requires no additional bytes in the EAT and makes the EAT smaller.
これの利点は、重要な識別には食事に追加のバイトが必要であり、食事を小さくすることです。
A disadvantage of this is that the unverified EAT must be substantially decoded to obtain the identifier since the identifier is in the COSE/JOSE payload, not in the headers.
これの欠点は、識別子がヘッダーではなくCOSE/JOSEペイロードにあるため、識別子を取得するために、未検証の食事を実質的にデコードする必要があることです。
Many thanks to the following for their contributions to earlier draft versions of this document:
このドキュメントの以前のドラフトバージョンへの貢献について、以下に感謝します。
Henk Birkholz
Fraunhofer SIT
Email: henk.birkholz@sit.fraunhofer.de
Thomas Fossati
Arm Limited
Email: thomas.fossati@arm.com
Miguel Ballesteros
Michael Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
Patrick Uiterwijk
Mathias Brossard
Hannes Tschofenig
Arm Limited
Email: hannes.tschofenig@arm.com
Paul Crowley
Laurence Lundblade
Security Theory LLC
Email: lgl@securitytheory.com
Giridhar Mandyam
Email: giridhar.mandyam@gmail.com
Jeremy O'Donoghue
Qualcomm Technologies Inc.
279 Farnborough Road
Farnborough
GU14 7LS
United Kingdom
Phone: +44 1252 363189
Email: jodonogh@qti.qualcomm.com
Carl Wallace
Red Hound Software, Inc.
Email: carl@redhoundsoftware.com