Internet Engineering Task Force (IETF) H. Birkholz
Request for Comments: 9999 Fraunhofer SIT
Category: Standards Track N. Smith
ISSN: 2070-1721 Independent
T. Fossati
Linaro
H. Tschofenig
UniBw M.
July 2026
The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies.
Remote ATtestation ProcedureS (RATS) アーキテクチャ (RFC 9334) によって導入された概念的なメッセージは、RATS 対話中に RATS 役割間で伝達されるプロトコルに依存しないデータ単位です。概念的なメッセージは、ワイヤ形式、エンコーディング、転送メカニズム、または処理の詳細を指定せずに、RATS データ フロー内のそのようなデータ ユニットの意味と機能を説明します。概念メッセージの初期セットは RFC 9334 のセクション 8 で定義されており、証拠、証明結果、承認、基準値、および評価ポリシーが含まれます。
This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension.
このドキュメントでは、これらのメッセージをカプセル化するための共通の構造を提供する概念メッセージ ラッパー (CMW) を紹介します。これは、専用の Concise Binary Object Representation (CBOR) タグ、対応する JSON Web Token (JWT) および CBOR Web Token (CWT) クレーム、および X.509 拡張機能を定義します。
Together, these mechanisms allow CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts such as X.509 certificates. Additionally, this document defines media types and CoAP Content-Formats that may be used to identify CMWs when transported over protocols such as HTTP, MIME, and CoAP.
これらのメカニズムを組み合わせることで、CBOR ベースのプロトコル、JWT および CWT を使用する Web API、および X.509 証明書などの PKIX アーティファクトで CMW を使用できるようになります。さらに、この文書は、HTTP、MIME、CoAP などのプロトコル経由で転送されるときに CMW を識別するために使用できるメディア タイプと CoAP コンテンツ フォーマットを定義します。
The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, enables the evolution of message serialization formats without breaking compatibility, and avoids the need to redefine how messages are handled within each protocol.
目標は、リモート構成証明プロトコルの相互運用性と柔軟性を向上させることです。CMW などの共有メッセージ形式を導入すると、さまざまな認証メッセージ タイプの一貫したサポートが可能になり、互換性を損なうことなくメッセージのシリアル化形式を進化させることができ、各プロトコル内でメッセージを処理する方法を再定義する必要がなくなります。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9999.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9999 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Conventions and Definitions
3. Conceptual Message Wrappers
3.1. Record CMW
3.1.1. Conceptual Message Type
3.2. Tag CMW
3.2.1. How to Plug in a New Tag CMW
3.3. Collection CMW
3.4. Demuxing
4. Cryptographic Protection of CMWs
4.1. Signing CBOR CMW Using COSE_Sign1
4.2. Signing JSON CMW Using JWS
4.3. Transporting CMW in COSE and JSON Web Tokens
4.3.1. Encoding Requirements
4.4. Transporting CMW in PKIX Formats
4.4.1. ASN.1 Module
4.4.2. Compatibility with Trusted Computing Group (TCG)
ConceptualMessageWrapper
5. Examples
5.1. JSON-Encoded Record
5.2. CBOR-Encoded Record
5.3. CBOR-Encoded Tag CMW
5.4. CBOR-Encoded Record with an Explicit Conceptual Message
Indicator
5.5. CBOR-Encoded Collection
5.6. JSON-Encoded Collection
5.7. Use in JWT
6. Collected CDDL
7. Privacy Considerations
8. Security Considerations
8.1. CMW Protection
8.2. Using Collection CMWs for Evidence of Composite or Layered
Devices
8.3. Integrating CMW into Protocols
9. IANA Considerations
9.1. CWT cmw Claim Registration
9.2. JWT cmw Claim Registration
9.3. +jws Structured Syntax Suffix
9.3.1. Registry Entry
9.4. RATS Conceptual Message Wrapper (CMW) Indicators Registry
9.4.1. Structure of Entries
9.5. Media Types
9.5.1. application/cmw+cbor
9.5.2. application/cmw+json
9.5.3. application/cmw+cose
9.5.4. application/cmw+jws
9.6. CoAP Content-Formats
9.6.1. Registering New CoAP Content-Formats for Parameterized
CMW Media Types
9.6.2. CBOR Tags per RFC 9277
9.7. SMI Number Registration
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Registering and Using CMWs
Acknowledgments
Contributors
Authors' Addresses
The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture [RFC9334] are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of [RFC9334] and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies.
Remote ATtestation ProcedureS (RATS) アーキテクチャ [RFC9334] によって導入された概念的なメッセージは、RATS 対話中に RATS 役割間で伝達されるプロトコルに依存しないデータ単位です。概念的なメッセージは、ワイヤ形式、エンコーディング、転送メカニズム、または処理の詳細を指定せずに、RATS データ フロー内のそのようなデータ ユニットの意味と機能を説明します。概念メッセージの初期セットは [RFC9334] のセクション 8 で定義されており、証拠、証明結果、承認、基準値、および評価ポリシーが含まれます。
Each conceptual message can have multiple claim-encoding and serialization formats (Section 9 of [RFC9334]). Throughout their lifetime, RATS conceptual messages are typically transported over different protocols. For example:
各概念的メッセージは、複数のクレームエンコーディングおよびシリアル化フォーマットを持つことができます ([RFC9334] のセクション 9)。RATS 概念メッセージは、その存続期間を通じて、通常、さまざまなプロトコルを介して転送されます。例えば：
* In a "background-check" topology (Section 5.2 of [RFC9334]), Evidence (e.g., Entity Attestation Token (EAT) [RFC9711]) first flows from the Attester to the Relying Party (RP); then it flows from the RP to the Verifier and each leg following a separate protocol path. See Figure 1.
* 「バックグラウンドチェック」トポロジ ([RFC9334] のセクション 5.2) では、証拠 (例: エンティティ認証トークン (EAT) [RFC9711]) は、まず認証者から信頼当事者 (RP) に流れます。その後、RP から Verifier に流れ、個別のプロトコル パスに従って各レッグに流れます。図 1 を参照してください。
.------------.
| Verifier |
'------------'
^
| EAT
| over
| REST API
.------------. .---|--------.
| Attester +------------->|--' RP |
'------------' EAT over TLS '------------'
Figure 1: Conveyance of RATS Conceptual Messages in the 'background-check' Topology
図 1: 「バックグラウンド チェック」トポロジにおける RATS 概念的メッセージの伝達
* In a "passport" topology (Section 5.1 of [RFC9334]), an attestation result payload (e.g., EAT Attestation Result (EAR) [EAR]) is initially sent from the Verifier to the Attester; later, it is sent via a different channel from the Attester to the RP. See Figure 2.
* 「パスポート」トポロジ ([RFC9334] のセクション 5.1) では、検証結果ペイロード (例: EAT Attestation Result (EAR) [EAR]) が最初に検証者から検証者に送信されます。その後、認証者から別のチャネルを介して RP に送信されます。図 2 を参照してください。
.------------.
| Verifier |
'--------+---'
EAR |
over |
REST API |
v
.------------. .------------.
| Attester +------------->| RP |
'------------' EAR over TLS '------------'
Figure 2: Conveyance of RATS Conceptual Messages in the 'passport' Topology
図 2: 「パスポート」トポロジにおける RATS 概念的メッセージの伝達
By using the CMW format outlined in this document, protocol designers can avoid the need to update protocol specifications to accommodate different conceptual messages and serialization formats used by various attestation technologies. This approach streamlines the implementation process for developers, enabling easier support for diverse attestation technologies. For instance, an RP application implementer does not need to parse attestation-related messages, such as Evidence from Attesters on Internet of Things (IoT) devices with Trusted Platform Modules (TPMs) or servers using confidential computing hardware like Intel Trust Domain Extensions (TDX). Instead, they can leverage the CMW format, remaining agnostic to the specific attestation technology.
この文書で概説されている CMW 形式を使用することにより、プロトコル設計者は、さまざまな認証テクノロジで使用されるさまざまな概念メッセージやシリアル化形式に対応するためにプロトコル仕様を更新する必要を回避できます。このアプローチにより、開発者の実装プロセスが合理化され、さまざまな認証テクノロジのサポートが容易になります。たとえば、RP アプリケーションの実装者は、トラステッド プラットフォーム モジュール (TPM) を備えたモノのインターネット (IoT) デバイスやインテル トラスト ドメイン エクステンション (TDX) などの機密コンピューティング ハードウェアを使用するサーバー上の認証者からの証拠など、認証関連のメッセージを解析する必要がありません。代わりに、特定の構成証明テクノロジーにとらわれずに、CMW 形式を利用できます。
A further design goal is extensibility. This means that adding support for new conceptual messages and new attestation technologies should not change the core of the processor; it also means that a CMW stack can be designed to offer a plug-in interface for both encoding and decoding. To achieve this, the format must provide consistent message encapsulation and explicit typing. These features allow the selection of the appropriate message handler based on its type identifier. An opaque message can then be passed between the core and the handler.
さらなる設計目標は拡張性です。これは、新しい概念メッセージと新しい認証テクノロジのサポートを追加しても、プロセッサのコアが変更されるべきではないことを意味します。これは、エンコードとデコードの両方にプラグイン インターフェイスを提供するように CMW スタックを設計できることも意味します。これを実現するには、形式が一貫したメッセージのカプセル化と明示的な型付けを提供する必要があります。これらの機能により、タイプ識別子に基づいて適切なメッセージ ハンドラーを選択できます。その後、不透明なメッセージをコアとハンドラーの間で受け渡すことができます。
This document defines two encapsulation formats for RATS conceptual messages that aim to achieve the goals stated above.
この文書は、上記の目標を達成することを目的とした RATS 概念的メッセージの 2 つのカプセル化形式を定義します。
These encapsulation formats have been specifically designed to possess the following characteristics:
これらのカプセル化形式は、次の特性を持つように特別に設計されています。
* They are self-describing: they can convey precise typing information without relying on the framing provided by the embedding protocol or the storage system.
* これらは自己記述型であり、埋め込みプロトコルやストレージ システムによって提供されるフレームに依存せずに、正確な型情報を伝達できます。
* They are based on media types [RFC6838], which allows the cost of their registration to be spread across numerous usage scenarios.
* これらはメディア タイプ [RFC6838] に基づいており、その登録コストを多数の使用シナリオに分散することができます。
A protocol designer could use these formats, for example, to:
プロトコル設計者は、これらの形式を次の目的で使用できます。
* convey Evidence, Endorsements, and Reference Values in certificates and Certificate Revocation List (CRL) extensions [DICE-ARCH];
* 証明書および証明書失効リスト (CRL) 拡張機能で証拠、裏書、参照値を伝達する [DICE-ARCH]。
* embed Attestation Results or Evidence as first-class authentication credentials in TLS handshake messages [RA-TLS-DTLS] [RA-EXP-AUTH];
* 構成証明の結果または証拠を、TLS ハンドシェイク メッセージに第一級の認証資格情報として埋め込む [RA-TLS-DTLS] [RA-EXP-AUTH]。
* transport attestation-related payloads in RESTful APIs (where "RESTful" refers to the Representational State Transfer (REST) architecture); or
* RESTful API での認証関連のペイロードの転送 (「RESTful」とは Representational State Transfer (REST) アーキテクチャを指します)。または
* serve as stable storage of Attestation Results in the form of file system objects.
* ファイル システム オブジェクトの形式で認証結果の安定したストレージとして機能します。
This document also defines a corresponding CBOR tag, JWT and CWT claims, and an X.509 extension. These allow embedding the wrapped conceptual messages into CBOR-based protocols, web APIs, and PKIX formats and protocols. In addition, media types and CoAP Content-Formats are defined for transporting CMWs in HTTP, MIME, CoAP, and other Internet protocols.
この文書では、対応する CBOR タグ、JWT および CWT クレーム、および X.509 拡張も定義します。これらにより、ラップされた概念メッセージを CBOR ベースのプロトコル、Web API、PKIX 形式とプロトコルに埋め込むことができます。さらに、メディア タイプと CoAP コンテンツ フォーマットは、HTTP、MIME、CoAP、およびその他のインターネット プロトコルで CMW を転送するために定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
In this document, Concise Data Definition Language (CDDL) (see [RFC8610], [RFC9165], and [RFC9741]) is used to describe the data formats.
この文書では、データ形式を記述するために Concise Data Definition Language (CDDL) ([RFC8610]、[RFC9165]、および [RFC9741] を参照) を使用します。
The reader is assumed to be familiar with the vocabulary and concepts defined in [RFC9334].
読者は、[RFC9334] で定義されている語彙と概念に精通していることを前提としています。
This document reuses the terms defined in Section 2 of [RFC9193] (e.g., "Content-Type").
この文書は、[RFC9193] のセクション 2 で定義された用語 (例:「Content-Type」) を再利用します。
A RATS CMW has a tree structure. Leaf nodes are of type "Record" (Section 3.1) or "Tag" (Section 3.2). Intermediate nodes are of type "Collection" (Section 3.3); they hold together multiple CMW items.
RATS CMW はツリー構造になっています。リーフノードのタイプは「レコード」(セクション 3.1) または「タグ」(セクション 3.2) です。中間ノードのタイプは「コレクション」です (セクション 3.3)。複数の CMW アイテムをまとめて保持します。
The following snippet outlines the productions associated with the top-level types.
次のスニペットは、トップレベルのタイプに関連付けられたプロダクションの概要を示しています。
start = cmw
cmw = json-cmw / cbor-cmw
json-cmw = json-record / json-collection
cbor-cmw = cbor-record / cbor-collection / $cbor-tag
The complete CDDL can be found in Section 6.
完全な CDDL はセクション 6 にあります。
Sections 4.3 and 4.4 describe the transport of CMWs using CBOR, JWTs, and PKIX formats including Certificate Signing Requests (CSRs), X.509 certificates, and CRLs.
セクション 4.3 と 4.4 では、CBOR、JWT、および証明書署名要求 (CSR)、X.509 証明書、CRL を含む PKIX 形式を使用した CMW のトランスポートについて説明します。
This document only defines an encapsulation, not a security format. It is the responsibility of the Attester to ensure that the CMW contents have the necessary security protection. Security considerations are discussed in Section 8.
この文書はカプセル化のみを定義し、セキュリティ形式は定義しません。CMW コンテンツに必要なセキュリティ保護が施されていることを確認するのは認証者の責任です。セキュリティに関する考慮事項についてはセクション 8 で説明します。
The format of the Record CMW is shown in Figure 3. The JSON [STD90] and CBOR [STD94] representations are provided separately. Both the json-record and cbor-record have the same fields, except for slight differences in the types discussed below.
レコード CMW の形式を図 3 に示します。JSON [STD90] 表現と CBOR [STD94] 表現は別々に提供されます。json-record と cbor-record は両方とも、以下で説明するタイプのわずかな違いを除いて、同じフィールドを持ちます。
json-record = [
type: media-type
value: base64url-string
? ind: uint .bits cm-type
]
cbor-record = [
type: coap-content-format-type / media-type
value: bytes
? ind: uint .bits cm-type
]
Figure 3: CDDL Definition of the Record CMW
図 3: レコード CMW の CDDL 定義
Each contains two or three members:
それぞれに 2 つまたは 3 つのメンバーが含まれています。
type:
タイプ：
Either a text string representing a Content-Type (e.g., an EAT media type [RFC9782]) or an unsigned integer corresponding to a CoAP Content-Format ID (Section 12.3 of [RFC7252]). The latter is not used in the JSON serialization.
Content-Type (EAT メディア タイプ [RFC9782] など) を表すテキスト文字列、または CoAP コンテンツ フォーマット ID ([RFC7252] セクション 12.3) に対応する符号なし整数のいずれか。後者は JSON シリアル化では使用されません。
value:
値：
The RATS conceptual message serialized according to the value defined in the type member. When using JSON, the value field MUST be encoded as Base64 using the URL and filename-safe alphabet (Section 5 of [RFC4648]) without padding. This always applies, even if the conceptual message format is already textual (e.g., a JWT EAT). When using CBOR, the value field MUST be encoded as a CBOR byte string.
type メンバーで定義された値に従ってシリアル化された RATS 概念メッセージ。JSON を使用する場合、値フィールドは、パディングなしで URL とファイル名セーフなアルファベット ([RFC4648] のセクション 5) を使用して Base64 としてエンコードされなければなりません (MUST)。これは、概念的なメッセージ形式がすでにテキスト形式 (JWT EAT など) である場合でも、常に当てはまります。CBOR を使用する場合、値フィールドは CBOR バイト文字列としてエンコードされなければなりません。
ind:
ind:
An optional bitmap with a maximum size of 4 bytes that indicates which conceptual message types are carried in the value field. Any combination (i.e., any value between 1 and 2^32-1 inclusive) is allowed. Only 5 bits are registered in this document, so the acceptable values are currently limited to 1 to 31. This is useful only if the type is potentially ambiguous and there is no further context available to the CMW consumer to decide. For example, this might be the case if the base media type is not profiled (e.g., application/eat+cwt), if the value field contains multiple conceptual messages with different types (e.g., both Reference Values and Endorsements within the same application/ rim+cose), or if the same profile identifier is shared by different conceptual messages. The value MUST be non-zero. The absence of information about the conceptual message indicator is indicated by omitting the ind field entirely. For further details, see Section 3.1.1.
値フィールドにどの概念メッセージ タイプが含まれるかを示す、最大サイズ 4 バイトのオプションのビットマップ。任意の組み合わせ (つまり、1 から 2^32-1 までの任意の値) が許可されます。このドキュメントには 5 ビットのみが登録されているため、許容可能な値は現在 1 ～ 31 に制限されています。これは、タイプがあいまいな可能性があり、CMW コンシューマーが決定できる追加のコンテキストがない場合にのみ役立ちます。例えば、ベースメディアタイプがプロファイリングされていない場合（例えば、application/eat+cwt）、値フィールドに異なるタイプの複数の概念メッセージが含まれている場合（例えば、同じアプリケーション/rim+cose 内の参照値と承認の両方）、または同じプロファイル識別子が異なる概念メッセージによって共有されている場合がこれに該当する可能性があります。値はゼロ以外でなければなりません。概念メッセージ インジケーターに関する情報が存在しないことは、ind フィールドを完全に省略することによって示されます。詳細については、セクション 3.1.1 を参照してください。
The cm-type type is the control type for the ind field. As such, it indicates which bits are allowed to be set in the ind bitmap.
cm-type タイプは、ind フィールドの制御タイプです。そのため、ind ビットマップでどのビットを設定できるかを示します。
cm-type = &(
reference-values: 0
endorsements: 1
evidence: 2
attestation-results: 3
appraisal-policy: 4
)
Figure 4: CDDL Definition of the CM Type
図 4: CM タイプの CDDL 定義
The cm-type as defined by this document has five allowed values: Reference Values, Endorsements, Evidence, Attestation Results, and Appraisal Policy, as defined in Section 8 of [RFC9334]. Note that an Appraisal Policy may refer to the appraisal of Evidence or Attestation Results, depending on whether the consumer of the conceptual message is a Verifier or an RP.
この文書で定義されている cm-type には、[RFC9334] のセクション 8 で定義されている、Reference Values、Endorsements、Evidence、Attestation Results、および Appraisal Policy という 5 つの値が許可されています。評価ポリシーは、概念メッセージの利用者が検証者であるか RP であるかに応じて、証拠または証明結果の評価を指す場合があることに注意してください。
It is recommended that future specifications extending the RATS conceptual messages add new values to the cm-type using the process defined in Section 9.4.
RATS 概念メッセージを拡張する将来の仕様では、セクション 9.4 で定義されたプロセスを使用して cm-type に新しい値を追加することが推奨されます。
Tag CMWs derive their tag numbers from a corresponding CoAP Content-Format ID using the TN() transform defined in Appendix B of [RFC9277]. Such CBOR tag numbers are in the range [1668546817, 1668612095].
タグ CMW は、[RFC9277] の付録 B で定義されている TN() 変換を使用して、対応する CoAP コンテンツ フォーマット ID からタグ番号を導出します。このような CBOR タグ番号は [1668546817、1668612095] の範囲内にあります。
The RATS conceptual message is first serialized according to the Content-Format ID and then encoded as a CBOR byte string, to which the TN-derived tag number is prepended.
RATS 概念メッセージは、まずコンテンツ フォーマット ID に従ってシリアル化され、次に TN 由来のタグ番号が先頭に付加される CBOR バイト文字列としてエンコードされます。
The Tag CMW is defined in Figure 5 using two different macros: one for CBOR-encoded types and the other for all other types. Both macros take the CBOR tag number tn as a parameter. The tag-cm-cbor macro takes the CDDL definition of the associated conceptual message fmt as a second parameter.
図 5 では、タグ CMW が 2 つの異なるマクロを使用して定義されています。1 つは CBOR エンコード型用で、もう 1 つは他のすべての型用です。どちらのマクロも CBOR タグ番号 tn をパラメータとして受け取ります。tag-cm-cbor マクロは、関連する概念メッセージ fmt の CDDL 定義を 2 番目のパラメーターとして受け取ります。
tag-cm-cbor<tn, fmt> = #6.<tn>(bytes .cbor fmt)
tag-cm-data<tn> = #6.<tn>(bytes)
Figure 5: CDDL Definition of the Tag CMW Macros
図 5: タグ CMW マクロの CDDL 定義
To plug a new Tag CMW into the CDDL defined in Section 6, the $cbor-tag type socket must be extended with a new instance of the Tag CMW macro (i.e., one of tag-cm-cbor or tag-cm-data).
新しいタグ CMW をセクション 6 で定義された CDDL にプラグインするには、$cbor-tag タイプのソケットをタグ CMW マクロの新しいインスタンス (つまり、tag-cm-cbor または tag-cm-data のいずれか) で拡張する必要があります。
For instance, if a conceptual message of type my-evidence has the TN-derived CBOR tag 1668612069, $cbor-tag would be extended as follows:
たとえば、タイプ my-evidence の概念メッセージに TN 由来の CBOR タグ 1668612069 がある場合、$cbor-tag は次のように拡張されます。
$cbor-tag /= tag-cm-cbor<1668612069, my-evidence>
my-evidence = {
&(eat_nonce: 10) => bytes .size (8..64)
}
Instead, if a (non-CBOR) conceptual message has the TN-derived CBOR tag 1668612070, $cbor-tag would be extended as follows:
代わりに、(非 CBOR) 概念的メッセージに TN 由来の CBOR タグ 1668612070 がある場合、$cbor-tag は次のように拡張されます。
$cbor-tag /= tag-cm-data<1668612070>
The socket is initialized as described in Figure 7.
ソケットは図 7 に示すように初期化されます。
Layered Attesters and composite devices (Sections 3.2 and 3.3 of [RFC9334]) generate Evidence that consists of multiple parts. For example, in data center servers, it is not uncommon for separate attesting environments (AEs) to serve a subsection of the entire machine. One AE might measure and attest to what was booted on the main CPU, while another AE might measure and attest to what was booted on a SmartNIC plugged into a PCI Express (PCIe) slot, and a third AE might measure and attest to what was booted on the machine's Graphics Processing Unit (GPU). To allow aggregation of multiple, potentially non-homogeneous evidence formats collected from different AEs, this document defines a Collection CMW as a container that holds several CMW items, each with a label that is unique within the scope of the collection.
階層化された認証者と複合デバイス ([RFC9334] のセクション 3.2 および 3.3) は、複数の部分で構成される証拠を生成します。たとえば、データ センター サーバーでは、個別の認証環境 (AE) がマシン全体のサブセクションにサービスを提供することは珍しくありません。1 つの AE はメイン CPU で何がブートされたかを測定および証明し、別の AE は PCI Express (PCIe) スロットに接続された SmartNIC で何がブートされたかを測定および証明し、3 番目の AE はマシンのグラフィックス プロセッシング ユニット (GPU) で何がブートされたかを測定および証明する可能性があります。異なる AE から収集された複数の潜在的に不均質な証拠フォーマットの集約を可能にするために、この文書では、コレクション CMW を、コレクションの範囲内でそれぞれに一意のラベルが付いた複数の CMW アイテムを保持するコンテナとして定義します。
Although originally designed to support layered Attester and composite device use cases, the Collection CMW can be adapted for other scenarios that require the aggregation of RATS conceptual messages. For instance, collections may be used to group Endorsements, Reference Values, Attestation Results, and more. A single Collection CMW can contain a mix of different message types; it can also be used to carry messages related to multiple devices simultaneously.
もともと、階層化されたアテスターと複合デバイスのユースケースをサポートするように設計されていましたが、コレクション CMW は、RATS 概念メッセージの集約を必要とする他のシナリオにも適応できます。たとえば、コレクションは、承認、参照値、証明結果などをグループ化するために使用できます。単一のコレクション CMW には、さまざまなメッセージ タイプを組み合わせて含めることができます。また、複数のデバイスに関連するメッセージを同時に送信するために使用することもできます。
The Collection CMW (Figure 6) is defined as a CBOR map or JSON object containing CMW values. The position of a cmw entry in the cmw-collection is not significant. Labels can be strings (or integers in the CBOR serialization) that serve as a mnemonic for different conceptual messages in the collection.
コレクション CMW (図 6) は、CMW 値を含む CBOR マップまたは JSON オブジェクトとして定義されます。cmw コレクション内の cmw エントリの位置は重要ではありません。ラベルは、コレクション内のさまざまな概念的メッセージのニーモニックとして機能する文字列 (または CBOR シリアル化では整数) にすることができます。
json-collection = {
? "__cmwc_t": ~uri / oid
+ &(label: text) => json-cmw
}
cbor-collection = {
? "__cmwc_t": ~uri / oid
+ &(label: (int / text)) => cbor-cmw
}
Figure 6: CDDL Definition of the Collection CMW
図 6: コレクション CMW の CDDL 定義
A collection MUST have at least one CMW entry.
コレクションには少なくとも 1 つの CMW エントリが必要です。
The "__cmwc_t" key is reserved for associating an optional type with the overall collection and MUST NOT be used for any purpose other than described here.
「__cmwc_t」キーは、オプションのタイプをコレクション全体に関連付けるために予約されており、ここで説明する以外の目的に使用してはなりません。
The value of the "__cmwc_t" key is either a Uniform Resource Identifier (URI) or an object identifier (OID). The OID is always absolute and never relative. The URI MUST be in the absolute form (Section 4.3 of [RFC3986]).
「__cmwc_t」キーの値は、Uniform Resource Identifier (URI) またはオブジェクト識別子 (OID) のいずれかです。OID は常に絶対的であり、決して相対的ではありません。URI は絶対形式でなければなりません ([RFC3986] のセクション 4.3)。
The "__cmwc_t" key functions similarly to an EAT profile claim (see Section 4.3.2 of [RFC9711]) but at a higher level. It can be used to indicate basics like CBOR serialization and CBOR Object Signing and Encryption (COSE) algorithms just as a profile in EAT does. It provides a namespace in which the collection labels are interpreted. At the higher level, it can be used to describe the allowed Collection CMW assembly (this is somewhat parallel to the way EAT profiles indicate which claims are required and/or allowed). For an example of a "__cmwc_t" that is defined for a bundle of endorsements and reference values, see Section 4.3.1 of [CoRIM].
「__cmwc_t」キーは、EAT プロファイル要求 ([RFC9711] のセクション 4.3.2 を参照) と同様に機能しますが、より高いレベルで機能します。これは、EAT のプロファイルと同様に、CBOR シリアル化や CBOR Object Signing and Encryption (COSE) アルゴリズムなどの基本を示すために使用できます。これは、コレクションのラベルが解釈される名前空間を提供します。より高いレベルでは、許可されたコレクション CMW アセンブリを記述するために使用できます (これは、EAT プロファイルがどのクレームが必要であるか、および/または許可されているかを示す方法とある程度似ています)。推奨値と参考値のバンドルに対して定義された「__cmwc_t」の例については、[CoRIM] のセクション 4.3.1 を参照してください。
Since the Collection CMW is recursive (a Collection CMW is itself a CMW), implementations MAY limit the allowed depth of nesting.
Collection CMW は再帰的であるため (Collection CMW 自体が CMW である)、実装は許容されるネストの深さを制限してもよい(MAY)。
Implementation note: An API that uses CMW may support a discoverable "max-cmw-depth" attribute, allowing applications to advertise their own limits. Also, a protocol using CMW may require its users to specify a minimum depth. The exact details of how such a limit is discovered or set are out of scope of this document.
実装に関する注意: CMW を使用する API は、検出可能な「max-cmw- Depth」属性をサポートし、アプリケーションが独自の制限をアドバタイズできるようにする場合があります。また、CMW を使用するプロトコルでは、ユーザーが最小の深さを指定する必要がある場合があります。このような制限がどのように検出または設定されるかについての正確な詳細は、このドキュメントの範囲外です。
The split in the JSON/CBOR decoding path is expected to occur via the media type or content format (see Sections 9.5 and 9.6, respectively) or via the container context of the embedded CMW (see Sections 9.1 and 9.2 for CWT/JWT and Section 9.7 for X.509).
JSON/CBOR デコードパスの分割は、メディアタイプまたはコンテンツ形式 (それぞれセクション 9.5 および 9.6 を参照)、または埋め込み CMW のコンテナコンテキスト (CWT/JWT についてはセクション 9.1 および 9.2、X.509 についてはセクション 9.7 を参照) を介して発生すると予想されます。
The following pseudocode illustrates how a one-byte look-ahead is sufficient to determine how to decode the remaining byte buffer.
次の疑似コードは、残りのバイト バッファをデコードする方法を決定するために 1 バイトの先読みで十分であることを示しています。
func exampleCMWTypeDemux(b []byte) CMWType {
if len(b) == 0 {
return Unknown
}
switch b[0] {
case 0x82: // 2-elements cbor-record (w/o ind field)
case 0x83: // 3-elements cbor-record (w/ ind field)
case 0x9f: // start of cbor-record using indefinite-length encoding
return CBORRecord
case 0xda: // tag-cm-cbor (CBOR tag in the TN range)
return CBORTag
case 0x5b: // ASCII '[', start of json-record
return JSONRecord
case 0x7b: // ASCII '{', start of json-collection
return JSONCollection
case 0xa0..0xbb: // CBOR map start values, start of cbor-collection
case 0xbf: // ditto
return CBORCollection
}
return Unknown
}
This code is provided for informational purposes only. It is not expected that implementations will follow this demuxing strategy.
このコードは情報提供のみを目的として提供されています。実装がこの逆多重化戦略に従うことは期待されていません。
This section highlights a number of mechanisms through which protocol designers can add data origin authentication, integrity, and (if used with a challenge-response protocol) anti-replay protection when employing CMWs. These properties must be evaluated carefully in the context of the overall security model of the protocol.
このセクションでは、プロトコル設計者が CMW を使用する際に、データ発信元の認証、整合性、および (チャレンジ/レスポンス プロトコルで使用する場合) アンチリプレイ保護を追加できる多数のメカニズムに焦点を当てます。これらのプロパティは、プロトコルの全体的なセキュリティ モデルのコンテキストで慎重に評価する必要があります。
A CBOR CMW can be signed using COSE [RFC9052]. A signed-cbor-cmw is a COSE_Sign1 with the following layout:
CBOR CMW は、COSE [RFC9052] を使用して署名できます。signed-cbor-cmw は、次のレイアウトを持つ COSE_Sign1 です。
signed-cbor-cmw = [
protected: bytes .cbor signed-cbor-cmw-protected-hdr
unprotected: signed-cbor-cmw-unprotected-hdr
payload: bytes .cbor cbor-cmw
signature: bytes
]
The payload MUST be the CBOR-encoded Tag, Record, or Collection CMW.
ペイロードは、CBOR でエンコードされたタグ、レコード、またはコレクション CMW でなければなりません。
signed-cbor-cmw-protected-hdr = {
1 => int ; alg
3 => "application/cmw+cbor" / 273 ; cty
* cose.label => cose.values
}
signed-cbor-cmw-unprotected-hdr = {
* cose.label => cose.values
}
cose.label = int / text
cose.values = any
The protected header MUST include the signature algorithm identifier. The protected header MUST include either the media type application/ cmw+cbor or the CoAP Content-Format 273. Other header parameters MAY be added to the header buckets, for example, a kid that identifies the signing key.
保護されたヘッダーには署名アルゴリズム識別子が含まれなければなりません (MUST)。保護されたヘッダーには、メディア タイプ application/cmw+cbor または CoAP Content-Format 273 のいずれかを含めなければなりません (MUST)。他のヘッダー パラメーター (署名キーを識別する kid など) をヘッダー バケットに追加してもよいです (MAY)。
A JSON CMW can be signed using JSON Web Signature (JWS) [RFC7515]. A signed-json-cmw uses either the Flattened JSON Serialization (Section 7.2.2 of [RFC7515]) or the Compact Serialization (Section 3.1 of [RFC7515]).
JSON CMW は、JSON Web Signature (JWS) [RFC7515] を使用して署名できます。signed-json-cmw は、フラット化された JSON シリアル化 ([RFC7515] のセクション 7.2.2) またはコンパクト シリアル化 ([RFC7515] のセクション 3.1) のいずれかを使用します。
signed-json-cmw = jws-flattened-json / jws-compact
jws-flattened-json = {
"protected": protected
? "header": unprotected
"payload": payload
"signature": signature
}
jws-compact =
(((protected .cat ".") .cat payload) .cat ".") .cat signature
protected = text .b64u (text .json signed-json-cmw-protected-hdr)
unprotected = text .b64u (text .json signed-json-cmw-unprotected-hdr)
payload = text .b64u (text .json json-cmw)
signature = text .b64u bytes
The payload MUST be the JSON-encoded Record or Collection CMW.
ペイロードは、JSON でエンコードされたレコードまたはコレクション CMW である必要があります。
signed-json-cmw-protected-hdr = {
"alg": text
"cty": "application/cmw+json"
* text => text
}
signed-json-cmw-unprotected-hdr = {
* text => text
}
The protected header MUST include the signature algorithm identifier and the media type application/cmw+json. Other header parameters MAY be added to the header buckets, for example, a kid that identifies the signing key.
保護されたヘッダーには、署名アルゴリズム識別子とメディア タイプ application/cmw+json が含まれなければなりません (MUST)。他のヘッダパラメータ、例えば署名鍵を識別するkidをヘッダバケットに追加してもよい(MAY)。
To facilitate the embedding of CMWs in CBOR-based protocols and web APIs, this document defines two "cmw" claims for use with JWT and CWT.
CBOR ベースのプロトコルおよび Web API への CMW の埋め込みを容易にするために、このドキュメントでは、JWT および CWT で使用する 2 つの「cmw」クレームを定義します。
The definitions for these claims can be found in Sections 9.2 and 9.1, respectively.
これらの請求項の定義は、それぞれセクション 9.2 および 9.1 に記載されています。
A Collection CMW carried in a "cmw" JWT claim MUST be a json-collection. A Collection CMW carried in a "cmw" CWT claim MUST be a cbor-collection.
「cmw」JWT クレームで保持されるコレクション CMW は、json-collection である必要があります。「cmw」CWT クレームで伝送されるコレクション CMW は、cbor-collection でなければなりません。
A Record CMW carried in a "cmw" JWT claim MUST be a json-record. A Record CMW carried in a "cmw" CWT claim MUST be a cbor-record.
「cmw」JWT クレームで伝送されるレコード CMW は、json レコードでなければなりません。「cmw」CWT クレームで伝送されるレコード CMW は、cbor レコードでなければなりません (MUST)。
CMW may need to be transported in PKIX formats, such as CSRs or in X.509 certificates and CRLs.
CMW は、CSR などの PKIX 形式、または X.509 証明書および CRL で転送する必要がある場合があります。
The use of CMW in CSRs is documented in [RA-CERT-SIGN], while one of the possible applications in X.509 certificates and CRLs is detailed in Section 6.1 of [DICE-ARCH].
CSR での CMW の使用は [RA-CERT-SIGN] に文書化されており、X.509 証明書と CRL での可能なアプリケーションの 1 つは [DICE-ARCH] のセクション 6.1 で詳しく説明されています。
This section outlines the CMW extension designed to carry CMW objects. Section 7 discusses some privacy considerations related to the transport of CMW in X.509 formats.
このセクションでは、CMW オブジェクトを伝送するために設計された CMW 拡張機能の概要を説明します。セクション 7 では、X.509 形式での CMW の転送に関連するプライバシーに関する考慮事項について説明します。
The CMW extension MAY be included in X.509 certificates, CRLs [RFC5280], and CSRs.
CMW 拡張は、X.509 証明書、CRL [RFC5280]、および CSR に含めてもよい(MAY)。
The CMW extension MUST be identified by the following object identifier:
CMW 拡張は、次のオブジェクト識別子によって識別されなければなりません。
id-pe-cmw OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 35 }
This extension SHOULD NOT be marked critical. In cases where the wrapped conceptual message is essential for granting resource access, and there is a risk that legacy RPs would bypass crucial controls, it is acceptable to mark the extension as critical.
この拡張機能はクリティカルとしてマークされるべきではありません。ラップされた概念メッセージがリソースへのアクセスを許可するために不可欠であり、レガシー RP が重要な制御をバイパスするリスクがある場合、拡張機能をクリティカルとしてマークすることは許容されます。
The CMW extension has the following syntax:
CMW 拡張機能の構文は次のとおりです。
CMW ::= CHOICE {
json UTF8String,
cbor OCTET STRING
}
The CMW MUST include the serialized CMW object in either JSON or CBOR format, utilizing the appropriate CHOICE entry.
CMW には、適切な CHOICE エントリを利用して、シリアル化された CMW オブジェクトを JSON または CBOR 形式で含める必要があります。
The DER-encoded [X.690] CMW is the value of the OCTET STRING for the extnValue field of the extension.
DER でエンコードされた [X.690] CMW は、拡張機能の extnValue フィールドの OCTET STRING の値です。
This section provides an ASN.1 module [X.680] for the CMW extension, following the conventions established in [RFC5912] and [RFC6268].
このセクションでは、[RFC5912] および [RFC6268] で確立された規則に従って、CMW 拡張用の ASN.1 モジュール [X.680] を提供します。
CMWExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cmw-extn(123) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
EXTENSION
FROM PKIX-CommonTypes-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ;
-- CMW Extension
ext-CMW EXTENSION ::= {
SYNTAX CMW
IDENTIFIED BY id-pe-cmw }
-- CMW Extension OID
id-pe-cmw OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 35 }
-- CMW Extension Syntax
CMW ::= CHOICE {
json UTF8String,
cbor OCTET STRING
}
END
Section 6.1.8 of [DICE-ARCH] specifies the ConceptualMessageWrapper (CMW) format and its corresponding object identifier. The CMW format outlined in [DICE-ARCH] permits only a subset of the CMW grammar defined in this document. In particular, the collection format cannot be encoded using TCG CMWs.
[DICE-ARCH] のセクション 6.1.8 では、ConceptualMessageWrapper (CMW) 形式とそれに対応するオブジェクト識別子を指定しています。[DICE-ARCH] で概説されている CMW 形式は、この文書で定義されている CMW 文法のサブセットのみを許可します。特に、コレクション形式は TCG CMW を使用してエンコードできません。
The (equivalent) examples in Sections 5.1, 5.2, and 5.3 assume that the Media-Type-Name application/vnd.example.rats-conceptual-msg has been registered alongside a corresponding CoAP Content-Format ID, 64999 [RFC9876]. The CBOR tag 1668612070 is derived applying the TN() transform as described in Section 3.2.
セクション 5.1、5.2、および 5.3 の (同等の) 例では、Media-Type-Name application/vnd.example.rats-conception-msg が、対応する CoAP Content-Format ID、64999 [RFC9876] と一緒に登録されていることを前提としています。CBOR タグ 1668612070 は、セクション 3.2 で説明されている TN() 変換を適用して導出されます。
All the examples focus on the wrapping aspects. The wrapped messages are not instances of real conceptual messages.
すべての例は、ラッピングの側面に焦点を当てています。ラップされたメッセージは、実際の概念的なメッセージのインスタンスではありません。
[
"application/vnd.example.rats-conceptual-msg",
"I0faVQ"
]
[
64999,
h'2347da55'
]
with the following wire representation:
次のワイヤ表現で:
82 # array(2)
19 fde7 # unsigned(64999)
44 # bytes(4)
2347da55 # "#G\xDAU"
Note that a Media-Type-Name can also be used with the CBOR-encoded Record form, for example, if it is known that the receiver cannot handle CoAP Content-Formats, or (unlike the case in point) if a CoAP Content-Format ID has not been registered.
たとえば、受信機が CoAP コンテンツ フォーマットを処理できないことがわかっている場合、または (この例とは異なり) CoAP コンテンツ フォーマット ID が登録されていない場合、Media-Type-Name は CBOR でエンコードされたレコード フォームでも使用できることに注意してください。
[
"application/vnd.example.rats-conceptual-msg",
h'2347da55'
]
1668612070(h'2347da55')
with the following wire representation:
次のワイヤ表現で:
da 6374ffe6 # tag(1668612070)
44 # bytes(4)
2347da55 # "#G\xDAU"
This is an example of a signed CoRIM (Concise Reference Integrity Manifest) [CoRIM] with an explicit ind value of 0b0000_0011 (3), indicating that the wrapped message contains both Reference Values and Endorsements.
これは、明示的な ind 値 0b0000_0011 (3) を持つ署名された CoRIM (Concise Reference Integrity Manifest) [CoRIM] の例であり、ラップされたメッセージに参照値と承認の両方が含まれていることを示しています。
[
"application/rim+cose",
h'd28440a044d901f5a040',
3
]
with the following wire representation (this example uses line wrapping per [RFC8792]):
次のワイヤ表現を使用します (この例では [RFC8792] に従って行折り返しを使用しています)。
=============== NOTE: '\' line wrapping per RFC 8792 ================
83 # array(3)
74 # text(20)
6170706c69636174696f6e2f72696d2b636f7365 # "application/rim+\
cose"
4a # bytes(10)
d28440a044d901f5a040 # serialized CM value
03 # unsigned(3)
The following example is a CBOR-encoded Collection CMW that assembles conceptual messages from three Attesters: Evidence for Attesters A and B and Attestation Results for Attester C. It is given an explicit "__cmwc_t" using the URI form.
次の例は、3 人の認証者 (認証者 A と B の証拠、および認証者 C の認証結果) からの概念的なメッセージを組み立てる CBOR エンコードされたコレクション CMW です。これには、URI 形式を使用して明示的な「__cmwc_t」が与えられます。
{
"__cmwc_t": "tag:example.com,2024:composite-attester",
/ attester A / 0: [
64999,
h'2347da55',
4
],
/ attester B / 1: 1668612070(h'2347da55'),
/ attester C / 2: [
"application/eat+jwt",
h'2e2e2e',
8
]
}
The following example is a JSON-encoded Collection CMW that assembles Evidence from two Attesters.
次の例は、2 人の認証者からの証拠を組み立てる JSON エンコードされたコレクション CMW です。
{
"__cmwc_t": "tag:example.com,2024:another-composite-attester",
"attester A": [
"application/eat-ucs+json",
"e30K",
4
],
"attester B": [
"application/eat-ucs+cbor",
"oA",
4
]
}
The following example shows the use of the "cmw" JWT claim to transport a Collection CMW in a JWT Claims Set [RFC7519]:
次の例は、「cmw」JWT クレームを使用して、JWT クレーム セット [RFC7519] 内のコレクション CMW を転送する方法を示しています。
{
"cmw": {
"__cmwc_t": "tag:example.com,2024:another-composite-attester",
"attester A": [
"application/eat-ucs+json",
"e30K",
4
],
"attester B": [
"application/eat-ucs+cbor",
"oA",
4
]
},
"iss": "evidence collection daemon",
"exp": 1300819380
}
This section contains all the CDDL definitions included in this specification.
このセクションには、この仕様に含まれるすべての CDDL 定義が含まれています。
start = cmw
cmw = json-cmw / cbor-cmw
json-cmw = json-record / json-collection
cbor-cmw = cbor-record / cbor-collection / $cbor-tag
json-record = [
type: media-type
value: base64url-string
? ind: uint .bits cm-type
]
cbor-record = [
type: coap-content-format-type / media-type
value: bytes
? ind: uint .bits cm-type
]
tag-cm-cbor<tn, fmt> = #6.<tn>(bytes .cbor fmt)
tag-cm-data<tn> = #6.<tn>(bytes)
json-collection = {
? "__cmwc_t": ~uri / oid
+ &(label: text) => json-cmw
}
cbor-collection = {
? "__cmwc_t": ~uri / oid
+ &(label: (int / text)) => cbor-cmw
}
media-type = text .abnf ("Content-Type" .cat Content-Type-ABNF)
base64url-string = text .regexp "[A-Za-z0-9_-]+"
coap-content-format-type = uint .size 2
oid = text .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*"
cm-type = &(
reference-values: 0
endorsements: 1
evidence: 2
attestation-results: 3
appraisal-policy: 4
)
Content-Type-ABNF = '
Content-Type = Media-Type-Name *( *SP ";" *SP parameter )
parameter = token "=" ( token / quoted-string )
token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "\'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA
quoted-string = %x22 *( qdtext / quoted-pair ) %x22
qdtext = SP / %x21 / %x23-5B / %x5D-7E
quoted-pair = "\\" ( SP / VCHAR )
Media-Type-Name = type-name "/" subtype-name
type-name = restricted-name
subtype-name = restricted-name
restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first = ALPHA / DIGIT
restricted-name-chars = ALPHA / DIGIT / "!" / "#" /
"$" / "&" / "-" / "^" / "_"
restricted-name-chars =/ "." ; Characters before first dot always
; specify a facet name
restricted-name-chars =/ "+" ; Characters after last plus always
; specify a structured syntax suffix
DIGIT = %x30-39 ; 0 - 9
POS-DIGIT = %x31-39 ; 1 - 9
ALPHA = %x41-5A / %x61-7A ; A - Z / a - z
SP = %x20
VCHAR = %x21-7E ; printable ASCII (no SP)
'
signed-cbor-cmw = [
protected: bytes .cbor signed-cbor-cmw-protected-hdr
unprotected: signed-cbor-cmw-unprotected-hdr
payload: bytes .cbor cbor-cmw
signature: bytes
]
signed-cbor-cmw-protected-hdr = {
1 => int ; alg
3 => "application/cmw+cbor" / 273 ; cty
* cose.label => cose.values
}
signed-cbor-cmw-unprotected-hdr = {
* cose.label => cose.values
}
cose.label = int / text
cose.values = any
signed-json-cmw = jws-flattened-json / jws-compact
jws-flattened-json = {
"protected": protected
? "header": unprotected
"payload": payload
"signature": signature
}
jws-compact =
(((protected .cat ".") .cat payload) .cat ".") .cat signature
signed-json-cmw-protected-hdr = {
"alg": text
"cty": "application/cmw+json"
* text => text
}
signed-json-cmw-unprotected-hdr = {
* text => text
}
protected = text .b64u (text .json signed-json-cmw-protected-hdr)
unprotected = text .b64u (text .json signed-json-cmw-unprotected-hdr)
payload = text .b64u (text .json json-cmw)
signature = text .b64u bytes
$cbor-tag /= tag-cm-cbor<1668547091, cbor-collection>
$cbor-tag /= tag-cm-cbor<1668547092, signed-cbor-cmw>
$cbor-tag /= tag-cm-data<1668547093> ; bytes(cmw+json collection)
$cbor-tag /= tag-cm-data<1668547094> ; bytes(cmw+jws)
The privacy considerations outlined in Section 11 of [RFC9334] are fully applicable. In particular, when a CMW contains Personally Identifiable Information (PII), which is the case for Evidence and sometimes for other conceptual messages as well, care must be taken to prevent unintended recipients from accessing it. Generally, utilizing secure channels between the parties exchanging CMWs can help address or mitigate these concerns. A specific scenario arises when a public key certificate is issued based on Evidence information provided by the certificate requestor to the issuing Certification Authority (CA). For instance, an individual seeking a publicly trusted code signing certificate may be willing to disclose the details of the hardware where their code signing keys are stored (e.g., a Hardware Security Module (HSM) model, patch level, etc.). However, they likely do not want this information to be publicly accessible. Applications that intend to publicly "broadcast" Evidence claims received from a third party via X.509 certificates should define a certification practice statement [RFC3647] that clearly specifies the circumstances under which the CA can include such data in the issued certificate. Note that the aforementioned consideration does not apply to cases where X.509 certificates are explicitly designed as a security envelope for Evidence claims, such as in [DICE-ARCH].
[RFC9334] のセクション 11 に概説されているプライバシーに関する考慮事項は完全に適用されます。特に、CMW に個人識別情報 (PII) が含まれている場合 (証拠の場合や、場合によっては他の概念メッセージの場合も同様)、意図しない受信者がアクセスできないように注意する必要があります。一般に、CMW を交換する当事者間で安全なチャネルを利用すると、これらの懸念に対処または軽減することができます。特定のシナリオは、証明書要求者が発行認証局 (CA) に提供した証拠情報に基づいて公開キー証明書が発行されるときに発生します。たとえば、公的に信頼できるコード署名証明書を求める個人は、コード署名キーが保存されているハードウェアの詳細 (ハードウェア セキュリティ モジュール (HSM) モデル、パッチ レベルなど) を喜んで開示する可能性があります。ただし、彼らはこの情報が一般に公開されることを望んでいない可能性があります。X.509 証明書を介して第三者から受け取った証拠要求を公的に「ブロードキャスト」することを意図するアプリケーションは、CA が発行された証明書にそのようなデータを含めることができる状況を明確に指定する認証実践ステートメント [RFC3647] を定義する必要があります。前述の考慮事項は、[DICE-ARCH] など、X.509 証明書が証拠請求のセキュリティ エンベロープとして明示的に設計されている場合には適用されないことに注意してください。
The security considerations discussed in Section 12.2 of [RFC9334] concerning the protection of conceptual messages are fully applicable. The following subsections provide further elaboration on these points, particularly in relation to Collection CMWs.
概念的メッセージの保護に関して [RFC9334] のセクション 12.2 で議論されているセキュリティ上の考慮事項は完全に適用可能です。以下のサブセクションでは、特にコレクション CMW に関連して、これらの点についてさらに詳しく説明します。
Record, Tag, and Collection CMWs alone do not offer authenticity, integrity protection, or confidentiality. It is the responsibility of the designer for each use case to determine the necessary security properties and implement them accordingly.
レコード、タグ、およびコレクション CMW だけでは、信頼性、完全性の保護、または機密性は提供されません。必要なセキュリティ プロパティを決定し、それに応じて実装するのは、各ユース ケースの設計者の責任です。
RATS conceptual messages are typically secured using cryptography. If the messages are already protected, no additional security requirements are imposed by this encapsulation. If an adversary attempts to modify the payload encapsulation, it will result in incorrect processing of the encapsulated message, leading to an error. If the messages are not protected, additional security must be added at a different layer. For example, a cbor-record containing an Unprotected CWT Claims Set (UCCS) [RFC9781] can be signed as described in Section 4.1.
RATS 概念メッセージは通常、暗号化を使用して保護されます。メッセージがすでに保護されている場合、このカプセル化によって追加のセキュリティ要件が課されることはありません。攻撃者がペイロードのカプセル化を変更しようとすると、カプセル化されたメッセージが正しく処理されず、エラーが発生します。メッセージが保護されていない場合は、別のレイヤーでセキュリティを追加する必要があります。たとえば、Unprotected CWT Claims Set (UCCS) [RFC9781] を含む cbor レコードは、セクション 4.1 で説明されているように署名できます。
Section 4 describes a number of methods that can be used to add cryptographic protection to CMW.
セクション 4 では、CMW に暗号化保護を追加するために使用できるいくつかの方法について説明します。
When a Collection CMW is used to encapsulate Evidence for composite or layered attestation of a single device, all Evidence messages within the CMW MUST be cryptographically bound together to prevent an attacker from replacing Evidence from a compromised device with that from a non-compromised device. If the Collection CMW is not protected from tampering by external security measures (such as object security primitives) or internal mechanisms (such as intra-item binding), an attacker could manipulate the collection's contents to deceive the Verifier into accepting bogus Evidence as genuine.
コレクション CMW を使用して単一デバイスの複合または階層化された証明書の証拠をカプセル化する場合、攻撃者が侵害されたデバイスの証拠を侵害されていないデバイスの証拠に置き換えることを防ぐために、CMW 内のすべての証拠メッセージを暗号的にバインドしなければなりません (MUST)。コレクション CMW が外部セキュリティ対策 (オブジェクト セキュリティ プリミティブなど) または内部メカニズム (アイテム内バインディングなど) によって改ざんから保護されていない場合、攻撃者はコレクションのコンテンツを操作して、検証者を騙して偽の証拠を本物として受け入れるように仕向ける可能性があります。
Authenticity and integrity protection is expected to be provided by the underlying attestation technology. For example, key material used to sign/bind an entire Collection CMW should be an attestation key, handled as described in Section 12.1 of [RFC9334]. The binding does not necessarily have to be a signature over the Collection CMW; it might also be achieved through identifiers, linking claims (e.g., nonces) across Collection CMW items, or signing or hashing between the members of the collection. It is the responsibility of the Attester who creates the Collection CMW to ensure that the contents of the collection are integrity protected.
信頼性と完全性の保護は、基礎となる認証テクノロジーによって提供されることが期待されています。たとえば、コレクション CMW 全体の署名/バインドに使用される鍵マテリアルは、[RFC9334] のセクション 12.1 で説明されているように処理される証明書鍵である必要があります。バインディングは、必ずしもコレクション CMW 上の署名である必要はありません。また、識別子、コレクション CMW アイテム間でクレーム (ノンスなど) をリンクすること、またはコレクションのメンバー間の署名またはハッシュを通じて実現される場合もあります。コレクションのコンテンツの整合性が確実に保護されるようにするのは、コレクション CMW を作成する認証者の責任です。
When CMW is integrated into some hosting protocol (for example, attested CSR [RA-CERT-SIGN] or attested TLS [RA-TLS-DTLS] [RA-EXP-AUTH]), it is up to that hosting protocol to describe how CMW is intended to be used and how it fits into the overall security model.
CMW が何らかのホスティング プロトコル (たとえば、証明された CSR [RA-CERT-SIGN] または証明された TLS [RA-TLS-DTLS] [RA-EXP-AUTH]) に統合されている場合、CMW がどのように使用されることを意図し、全体的なセキュリティ モデルにどのように適合するかを記述するのはそのホスティング プロトコルの責任になります。
Such an analysis should consider the types of conceptual messages allowed, including the permitted combinations, the protection requirements, the interface with the hosting protocol, and any other security-relevant aspect arising from the interaction between the CMW assembly and the hosting protocol.
このような分析では、許可される概念メッセージの種類 (許可される組み合わせ、保護要件、ホスティング プロトコルとのインターフェイス、CMW アセンブリとホスティング プロトコル間の対話から生じるその他のセキュリティ関連の側面など) を考慮する必要があります。
IANA has added a new cmw claim to the "CBOR Web Token (CWT) Claims" registry [IANA.cwt] as follows:
IANA は、次のように新しい cmw クレームを「CBOR Web Token (CWT) Claims」レジストリ [IANA.cwt] に追加しました。
Claim Name:
クレーム名:
cmw
cmw
Claim Description:
クレームの説明:
RATS Conceptual Message Wrapper
RATS 概念的メッセージ ラッパー
JWT Claim Name:
JWT クレーム名:
cmw
cmw
Claim Key:
クレームキー:
299
299
Claim Value Type:
クレーム値のタイプ:
CBOR map, CBOR array, or CBOR tag
CBORマップ、CBOR配列、またはCBORタグ
Change Controller:
コントローラを変更します:
IETF
IETF
Reference:
参照：
Sections 3.1, 3.2, and 3.3 of RFC 9999
RFC 9999 のセクション 3.1、3.2、および 3.3
IANA has added a new cmw claim to the "JSON Web Token Claims" registry within the "JSON Web Token (JWT)" registry group [IANA.jwt] as follows:
IANA は、次のように、「JSON Web Token (JWT)」レジストリ グループ [IANA.jwt] 内の「JSON Web Token Claims」レジストリに新しい cmw クレームを追加しました。
Claim Name:
クレーム名:
cmw
cmw
Claim Description:
クレームの説明:
RATS Conceptual Message Wrapper
RATS 概念的メッセージ ラッパー
Change Controller:
コントローラを変更します:
IETF
IETF
Reference:
参照：
Sections 3.1 and 3.3 of RFC 9999
RFC 9999 のセクション 3.1 および 3.3
IANA has registered the +jws structured syntax suffix in the "Structured Syntax Suffixes" registry [IANA.structured-suffixes] in the manner described in [RFC6838], which can be used to indicate that the media type is encoded as JWS [RFC7515].
IANA は、[RFC6838] で説明されている方法で +jws 構造化構文接尾辞を「構造化構文接尾辞」レジストリ [IANA.structurd-suffixes] に登録しました。これは、メディア タイプが JWS [RFC7515] としてエンコードされていることを示すために使用できます。
Name:
名前：
JSON Web Signature (JWS)
JSON Web署名(JWS)
+suffix:
+接尾辞:
+jws
+jws
References:
参考文献:
[RFC7515]
[RFC7515]
Encoding Considerations:
エンコーディングに関する考慮事項:
binary. Values are represented as a JSON Object or as a series of base64url-encoded values, each separated from the next by a single period ('.') character.
バイナリ。値は、JSON オブジェクトとして、または Base64URL でエンコードされた一連の値として表され、それぞれの値は単一のピリオド (「.」) 文字で区切られます。
Interoperability Considerations:
相互運用性に関する考慮事項:
N/A
該当なし
Fragment Identifier Considerations:
フラグメント識別子の考慮事項:
N/A
該当なし
Security Considerations:
セキュリティに関する考慮事項:
See Section 10 of [RFC7515]
[RFC7515] のセクション 10 を参照
Contact:
接触：
RATS WG mailing list (rats@ietf.org) or IETF Security Area (saag@ietf.org)
RATS WG メーリング リスト (rats@ietf.org) または IETF セキュリティ領域 (saag@ietf.org)
Author/Change Controller:
作成者/変更管理者:
Remote ATtestation procedureS (RATS) Working Group. The IETF has change control over this registration.
リモート ATtestation プロシージャ (RATS) ワーキング グループ。IETF はこの登録に対する変更管理を持っています。
IANA has created a new "RATS Conceptual Message Wrapper (CMW) Indicators" registry within the "Remote Attestation Procedures (RATS)" registry group [IANA.rats]. The registration procedure for the new registry is IETF Review (Section 4.8 of [RFC8126]).
IANA は、「Remote Attestation Procedures (RATS)」レジストリ グループ [IANA.rats] 内に新しい「RATS Conceptual Message Wrapper (CMW) Indicators」レジストリを作成しました。新しいレジストリの登録手順は IETF レビュー ([RFC8126] のセクション 4.8) です。
The objective is to register CMW Indicator values for all RATS conceptual messages (see Section 8 of [RFC9334]).
目的は、すべての RATS 概念メッセージの CMW インジケータ値を登録することです ([RFC9334] のセクション 8 を参照)。
Indicator values should be added in ascending order, with no gaps between them.
インジケーター値は、間に隙間がないように昇順で追加する必要があります。
Acceptable values correspond to the RATS conceptual messages defined by the RATS architecture [RFC9334] and any updates to it.
許容される値は、RATS アーキテクチャ [RFC9334] およびその更新によって定義された RATS 概念メッセージに対応します。
Each entry in the "RATS Conceptual Message Wrapper (CMW) Indicators" registry must include the following:
「RATS Conceptual Message Wrapper (CMW) Indicators」レジストリの各エントリには、次のものが含まれている必要があります。
Indicator Value:
インジケーター値:
A number corresponding to the bit position in the ind bitmap (Section 3.1).
ind ビットマップ内のビット位置に対応する数値 (セクション 3.1)。
Conceptual Message Name:
概念的なメッセージ名:
A text string describing the RATS conceptual message this indicator corresponds to.
このインジケーターが対応する RATS 概念メッセージを説明するテキスト文字列。
Reference:
参照：
A reference to the document that defines the entry.
エントリを定義するドキュメントへの参照。
The initial contents of the registry are shown in Table 1.
レジストリの初期内容を表 1 に示します。
+=================+=========================+===============+
| Indicator Value | Conceptual Message Name | Reference |
+=================+=========================+===============+
| 0 | Reference Values | Section 3.1.1 |
| | | of RFC 9999 |
+-----------------+-------------------------+---------------+
| 1 | Endorsements | Section 3.1.1 |
| | | of RFC 9999 |
+-----------------+-------------------------+---------------+
| 2 | Evidence | Section 3.1.1 |
| | | of RFC 9999 |
+-----------------+-------------------------+---------------+
| 3 | Attestation Results | Section 3.1.1 |
| | | of RFC 9999 |
+-----------------+-------------------------+---------------+
| 4 | Appraisal Policy | Section 3.1.1 |
| | | of RFC 9999 |
+-----------------+-------------------------+---------------+
| 5-31 | Unassigned | |
+-----------------+-------------------------+---------------+
Table 1: Initial Contents of the RATS CMW Indicators Registry
表 1: RATS CMW インジケーター レジストリの初期内容
IANA has added the following media types to the "Media Types" registry [IANA.media-types]:
IANA は、次のメディア タイプを「メディア タイプ」レジストリ [IANA.media-types] に追加しました。
+==========+======================+=====================+
| Name | Template | Reference |
+==========+======================+=====================+
| cmw+cbor | application/cmw+cbor | Sections 3.1, 3.2, |
| | | and 3.3 of RFC 9999 |
+----------+----------------------+---------------------+
| cmw+json | application/cmw+json | Sections 3.1 and |
| | | 3.3 of RFC 9999 |
+----------+----------------------+---------------------+
| cmw+cose | application/cmw+cose | Section 4.1 of RFC |
| | | 9999 |
+----------+----------------------+---------------------+
| cmw+jws | application/cmw+jws | Section 4.2 of RFC |
| | | 9999 |
+----------+----------------------+---------------------+
Table 2: CMW Media Types
表 2: CMW メディア タイプ
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
cmw+cbor
cmw+cbor
Required parameters:
必須パラメータ:
N/A
該当なし
Optional parameters:
オプションのパラメータ:
cmwc_t (Collection CMW type in string format. OIDs must use the dotted-decimal notation. The parameter value is case-insensitive. It must not be used for CMWs that are not collections.)
cmwc_t (文字列形式のコレクション CMW タイプ。OID はドット付き 10 進表記を使用する必要があります。パラメータ値は大文字と小文字を区別しません。コレクションではない CMW には使用しないでください。)
Encoding considerations:
エンコーディングに関する考慮事項:
binary (CBOR)
バイナリ (CBOR)
Security considerations:
セキュリティに関する考慮事項:
Section 8 of RFC 9999
RFC 9999 のセクション 8
Interoperability considerations:
相互運用性に関する考慮事項:
N/A
該当なし
Published specification:
公開された仕様:
RFC 9999
RFC 9999
Applications that use this media type:
このメディア タイプを使用するアプリケーション:
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer CMW payloads over HTTP(S), CoAP(S), and other transports.
HTTP(S)、CoAP(S)、およびその他のトランスポート経由で CMW ペイロードを転送する必要がある認証者、検証者、エンドーサーおよび参照値プロバイダー、および信頼当事者。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
The syntax and semantics of fragment identifiers are as specified for "application/cbor". (No fragment identification syntax is currently defined for "application/cbor".)
フラグメント識別子の構文とセマンティクスは、「application/cbor」で指定されているとおりです。(現在、「application/cbor」に対してフラグメント識別構文は定義されていません。)
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
RATS WG mailing list (rats@ietf.org)
RATS WG メーリング リスト (rats@ietf.org)
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
none
なし
Author/Change controller:
作成者/変更コントローラー:
IETF
IETF
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
cmw+json
cmw+json
Required parameters:
必須パラメータ:
N/A
該当なし
Optional parameters:
オプションのパラメータ:
cmwc_t (Collection CMW type in string format. OIDs must use the dotted-decimal notation. The parameter value is case-insensitive. It must not be used for CMWs that are not collections.)
cmwc_t (文字列形式のコレクション CMW タイプ。OID はドット付き 10 進表記を使用する必要があります。パラメータ値は大文字と小文字を区別しません。コレクションではない CMW には使用しないでください。)
Encoding considerations:
エンコーディングに関する考慮事項:
binary (JSON is UTF-8-encoded text)
バイナリ (JSON は UTF-8 でエンコードされたテキスト)
Security considerations:
セキュリティに関する考慮事項:
Section 8 of RFC 9999
RFC 9999 のセクション 8
Interoperability considerations:
相互運用性に関する考慮事項:
N/A
該当なし
Published specification:
公開された仕様:
RFC 9999
RFC 9999
Applications that use this media type:
このメディア タイプを使用するアプリケーション:
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer CMW payloads over HTTP(S), CoAP(S), and other transports.
HTTP(S)、CoAP(S)、およびその他のトランスポート経由で CMW ペイロードを転送する必要がある認証者、検証者、エンドーサーおよび参照値プロバイダー、および信頼当事者。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
The syntax and semantics of fragment identifiers are as specified for "application/json". (No fragment identification syntax is currently defined for "application/json".)
フラグメント識別子の構文とセマンティクスは、「application/json」で指定されているとおりです。(現在、「application/json」に対してフラグメント識別構文は定義されていません。)
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
RATS WG mailing list (rats@ietf.org)
RATS WG メーリング リスト (rats@ietf.org)
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
none
なし
Author/Change controller:
作成者/変更コントローラー:
IETF
IETF
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
cmw+cose
cmw+cose
Required parameters:
必須パラメータ:
N/A
該当なし
Optional parameters:
オプションのパラメータ:
cmwc_t (Collection CMW type in string format. OIDs must use the dotted-decimal notation. The parameter value is case-insensitive. It must not be used for CMWs that are not collections.) Note that the cose-type parameter is explicitly not supported, as it is understood to be "cose-sign1".
cmwc_t (文字列形式のコレクション CMW タイプ。OID ではドット 10 進表記を使用する必要があります。パラメータ値は大文字と小文字が区別されません。コレクションではない CMW には使用しないでください。) cose-type パラメータは「cose-sign1」として理解されるため、明示的にサポートされていないことに注意してください。
Encoding considerations:
エンコーディングに関する考慮事項:
binary (CBOR)
バイナリ (CBOR)
Security considerations:
セキュリティに関する考慮事項:
Section 8 of RFC 9999
RFC 9999 のセクション 8
Interoperability considerations:
相互運用性に関する考慮事項:
N/A
該当なし
Published specification:
公開された仕様:
RFC 9999
RFC 9999
Applications that use this media type:
このメディア タイプを使用するアプリケーション:
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer CMW payloads over HTTP(S), CoAP(S), and other transports.
HTTP(S)、CoAP(S)、およびその他のトランスポート経由で CMW ペイロードを転送する必要がある認証者、検証者、エンドーサーおよび参照値プロバイダー、および信頼当事者。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
N/A
該当なし
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
RATS WG mailing list (rats@ietf.org)
RATS WG メーリング リスト (rats@ietf.org)
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
none
なし
Author/Change controller:
作成者/変更コントローラー:
IETF
IETF
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
cmw+jws
cmw+jws
Required parameters:
必須パラメータ:
N/A
該当なし
Optional parameters:
オプションのパラメータ:
cmwc_t (Collection CMW type in string format. OIDs must use the dotted-decimal notation. The parameter value is case-insensitive. It must not be used for CMWs that are not collections.)
cmwc_t (文字列形式のコレクション CMW タイプ。OID はドット付き 10 進表記を使用する必要があります。パラメータ値は大文字と小文字を区別しません。コレクションではない CMW には使用しないでください。)
Encoding considerations:
エンコーディングに関する考慮事項:
8bit. Values are represented as a JSON Object or as a series of base64url-encoded values, each separated from the next by a single period ('.') character.
8ビット。値は、JSON オブジェクトとして、または Base64URL でエンコードされた一連の値として表され、それぞれの値は単一のピリオド (「.」) 文字で区切られます。
Security considerations:
セキュリティに関する考慮事項:
Section 8 of RFC 9999
RFC 9999 のセクション 8
Interoperability considerations:
相互運用性に関する考慮事項:
N/A
該当なし
Published specification:
公開された仕様:
RFC 9999
RFC 9999
Applications that use this media type:
このメディア タイプを使用するアプリケーション:
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer CMW payloads over HTTP(S), CoAP(S), and other transports.
HTTP(S)、CoAP(S)、およびその他のトランスポート経由で CMW ペイロードを転送する必要がある認証者、検証者、エンドーサーおよび参照値プロバイダー、および信頼当事者。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
N/A
該当なし
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
RATS WG mailing list (rats@ietf.org)
RATS WG メーリング リスト (rats@ietf.org)
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
none
なし
Author/Change controller:
作成者/変更コントローラー:
IETF
IETF
IANA has registered the following Content-Format IDs in the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group [IANA.core-parameters]:
IANA は、「制約付き RESTful 環境 (CoRE) パラメーター」レジストリ グループ [IANA.core-parameters] 内の「CoAP Content-Formats」レジストリに次のコンテンツ フォーマット ID を登録しました。
+======================+================+=====+=====================+
| Content-Type | Content Coding | ID | Reference |
+======================+================+=====+=====================+
| application/ | - | 273 | Sections 3.1, 3.2, |
| cmw+cbor | | | and 3.3 of RFC 9999 |
+----------------------+----------------+-----+---------------------+
| application/ | - | 274 | Sections 3.1 and |
| cmw+json | | | 3.3 of RFC 9999 |
+----------------------+----------------+-----+---------------------+
| application/ | - | 275 | Section 4.1 of RFC |
| cmw+cose | | | 9999 |
+----------------------+----------------+-----+---------------------+
| application/ | - | 276 | Section 4.2 of RFC |
| cmw+jws | | | 9999 |
+----------------------+----------------+-----+---------------------+
Table 3: CoAP Content-Formats
表 3: CoAP コンテンツ形式
New CoAP Content-Formats can be created based on parameterized instances of the application/cmw+json, application/cmw+cbor, application/cmw+cose, and application/cmw+jws media types.
新しい CoAP コンテンツ フォーマットは、application/cmw+json、application/cmw+cbor、application/cmw+cose、および application/cmw+jws メディア タイプのパラメータ化されたインスタンスに基づいて作成できます。
When assigning a new CoAP Content-Format ID for a CMW media type that utilizes the cmwc_t parameter, the registrar must check (directly or through the designated expert) the following:
cmwc_t パラメータを使用する CMW メディア タイプに新しい CoAP コンテンツ フォーマット ID を割り当てる場合、レジストラは次の点を (直接または指定された専門家を通じて) チェックする必要があります。
* The corresponding CMW is a collection (Section 3.3).
* 対応する CMW はコレクションです (セクション 3.3)。
* The cmwc_t value is either an (non-relative) OID or an absolute URI.
* cmwc_t 値は、(非相対) OID または絶対 URI のいずれかです。
Registering the CoAP Content-Formats listed in Table 3 automatically allocates CBOR tags in the range [1668546817, 1668612095] using the TN() transform defined in Appendix B of [RFC9277]. The allocated CBOR tag numbers and the corresponding data items are shown in Table 4.
表 3 にリストされている CoAP コンテンツ形式を登録すると、[RFC9277] の付録 B で定義されている TN() 変換を使用して、[1668546817、1668612095] の範囲に CBOR タグが自動的に割り当てられます。割り当てられた CBOR タグ番号と対応するデータ項目を表 4 に示します。
Note that CMWs in Tag and Record form are excluded. This is because they can already be represented as a CMW, so the extra wrapping would be redundant.
タグ形式およびレコード形式の CMW は除外されることに注意してください。これは、それらはすでに CMW として表現できるため、追加のラッピングは冗長になるためです。
+============+===============================+
| Tag Number | Tag Content |
+============+===============================+
| 1668547091 | bytes .cbor cbor-collection |
+------------+-------------------------------+
| 1668547092 | bytes .cbor signed-cbor-cmw |
+------------+-------------------------------+
| 1668547093 | bytes-wrapped json-collection |
+------------+-------------------------------+
| 1668547094 | bytes-wrapped signed-json-cmw |
+------------+-------------------------------+
Table 4: TN-Derived CBOR Tags
表 4: TN 由来の CBOR タグ
Figure 7 extends the $cbor-tag socket defined in Section 3.2 to add the definitions of the associated Tag CMWs.
図 7 は、セクション 3.2 で定義された $cbor-tag ソケットを拡張して、関連するタグ CMW の定義を追加します。
$cbor-tag /= tag-cm-cbor<1668547091, cbor-collection>
$cbor-tag /= tag-cm-cbor<1668547092, signed-cbor-cmw>
$cbor-tag /= tag-cm-data<1668547093> ; bytes(cmw+json collection)
$cbor-tag /= tag-cm-data<1668547094> ; bytes(cmw+jws)
Figure 7: Tag CMW Definitions
図 7: タグ CMW 定義
IANA has assigned an OID for the CMW extension defined in Section 4.4 in the "SMI Security for PKIX Certificate Extension" registry within the "Structure of Management Information (SMI) Numbers (MIB Module Registrations)" registry group [IANA.smi-numbers] as follows:
IANA は、「管理情報 (SMI) 番号の構造 (MIB モジュール登録)」レジストリ グループ [IANA.smi-numbers] 内の「PKIX 証明書拡張の SMI セキュリティ」レジストリのセクション 4.4 で定義されている CMW 拡張に OID を次のように割り当てました。
+=========+=============+=========================+
| Decimal | Description | Reference |
+=========+=============+=========================+
| 35 | id-pe-cmw | Section 4.4 of RFC 9999 |
+---------+-------------+-------------------------+
Table 5: CMW Extension OID
表 5: CMW 拡張 OID
IANA has assigned an OID for the ASN.1 module defined in Section 4.4.1 in the "SMI Security for PKIX Module Identifier" registry within the "Structure of Management Information (SMI) Numbers (MIB Module Registrations)" registry group [IANA.smi-numbers]:
IANA は、「管理情報 (SMI) 番号の構造 (MIB モジュール登録)」レジストリ グループ [IANA.smi-numbers] 内の「PKIX モジュール識別子の SMI セキュリティ」レジストリのセクション 4.4.1 で定義されている ASN.1 モジュールの OID を割り当てました。
+=========+=================+===========================+
| Decimal | Description | Reference |
+=========+=================+===========================+
| 123 | id-mod-cmw-extn | Section 4.4.1 of RFC 9999 |
+---------+-----------------+---------------------------+
Table 6: ASN.1 Module OID
表 6: ASN.1 モジュール OID
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE)
Parameters",
<https://www.iana.org/assignments/core-parameters>.
[IANA.cwt] IANA, "CBOR Web Token (CWT)",
<https://www.iana.org/assignments/cwt>.
[IANA.jwt] IANA, "JSON Web Token (JWT)",
<https://www.iana.org/assignments/jwt>.
[IANA.media-types]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
[IANA.rats]
IANA, "Remote Attestation Procedures (RATS)",
<https://www.iana.org/assignments/rats>.
[IANA.smi-numbers]
IANA, "Structure of Management Information (SMI) Numbers
(MIB Module Registrations)",
<https://www.iana.org/assignments/smi-numbers>.
[IANA.structured-suffixes]
IANA, "Structured Syntax Suffixes",
<https://www.iana.org/assignments/media-type-structured-
suffix>.
[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>.
[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>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
for the Cryptographic Message Syntax (CMS) and the Public
Key Infrastructure Using X.509 (PKIX)", RFC 6268,
DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/info/rfc6268>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[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>.
[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>.
[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>.
[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>.
[RFC9277] Richardson, M. and C. Bormann, "On Stable Storage for
Items in Concise Binary Object Representation (CBOR)",
RFC 9277, DOI 10.17487/RFC9277, August 2022,
<https://www.rfc-editor.org/info/rfc9277>.
[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>.
[RFC9741] Bormann, C., "Concise Data Definition Language (CDDL):
Additional Control Operators for the Conversion and
Processing of Text", RFC 9741, DOI 10.17487/RFC9741, March
2025, <https://www.rfc-editor.org/info/rfc9741>.
[STD90] Internet Standard 90,
<https://www.rfc-editor.org/info/std90>.
At the time of writing, this STD comprises the following:
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>.
[STD94] Internet Standard 94,
<https://www.rfc-editor.org/info/std94>.
At the time of writing, this STD comprises the following:
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>.
[X.680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>.
[X.690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
February 2021, <https://www.itu.int/rec/T-REC-X.690>.
[CoRIM] Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
W. Pan, "Concise Reference Integrity Manifest", Work in
Progress, Internet-Draft, draft-ietf-rats-corim-10, 2
March 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-rats-corim-10>.
[DICE-ARCH]
Trusted Computing Group, "DICE Attestation Architecture",
Version 1.1, Revision 0.18, January 2024,
<https://trustedcomputinggroup.org/wp-content/uploads/
DICE-Attestation-Architecture-Version-1.1-Revision-
18_pub.pdf>.
[EAR] Fossati, T., Voit, E., Trofimov, S., and H. Birkholz, "EAT
Attestation Results", Work in Progress, Internet-Draft,
draft-ietf-rats-ear-04, 26 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
ear-04>.
[RA-CERT-SIGN]
Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M.,
and N. Smith, "Use of Remote Attestation with
Certification Signing Requests", Work in Progress,
Internet-Draft, draft-ietf-lamps-csr-attestation-28, 16
June 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-lamps-csr-attestation-27>.
[RA-EXP-AUTH]
Sardar, M. U., Fossati, T., Reddy.K, T., Sheffer, Y.,
Tschofenig, H., and I. Mihalcea, "Remote Attestation with
Exported Authenticators", Work in Progress, Internet-
Draft, draft-fossati-seat-expat-02, 27 February 2026,
<https://datatracker.ietf.org/doc/html/draft-fossati-seat-
expat-02>.
[RA-TLS-DTLS]
Sheffer, Y., Mihalcea, I., Deshpande, Y., Fossati, T., and
T. Reddy.K, "Using Attestation in Transport Layer Security
(TLS) and Datagram Transport Layer Security (DTLS)", Work
in Progress, Internet-Draft, draft-fossati-seat-early-
attestation-04, 27 May 2026,
<https://datatracker.ietf.org/doc/html/draft-fossati-seat-
early-attestation-04>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/info/rfc3647>.
[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>.
[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>.
[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>.
[RFC9193] Keränen, A. and C. Bormann, "Sensor Measurement Lists
(SenML) Fields for Indicating Data Value Content-Format",
RFC 9193, DOI 10.17487/RFC9193, June 2022,
<https://www.rfc-editor.org/info/rfc9193>.
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/info/rfc9711>.
[RFC9781] Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A Concise Binary Object Representation (CBOR)
Tag for Unprotected CBOR Web Token Claims Sets (UCCS)",
RFC 9781, DOI 10.17487/RFC9781, May 2025,
<https://www.rfc-editor.org/info/rfc9781>.
[RFC9782] Lundblade, L., Birkholz, H., and T. Fossati, "Entity
Attestation Token (EAT) Media Types", RFC 9782,
DOI 10.17487/RFC9782, May 2025,
<https://www.rfc-editor.org/info/rfc9782>.
[RFC9876] Fossati, T. and E. Dijk, "Updates to the IANA Registration
Procedures for Constrained Application Protocol (CoAP)
Content-Formats", RFC 9876, DOI 10.17487/RFC9876, November
2025, <https://www.rfc-editor.org/info/rfc9876>.
Figure 8 describes the registration preconditions for using CMWs in either Record CMW or Tag CMW forms. When using a Collection CMW, the preconditions apply for each entry in the collection.
図 8 は、レコード CMW またはタグ CMW 形式で CMW を使用するための登録の前提条件を示しています。コレクション CMW を使用する場合、前提条件はコレクション内の各エントリに適用されます。
.---------------. .---------.
| Reuse EAT/CoRIM | | Register |
| media type(s) | | new media |
| + profile | | type |
`---+----+------' `-+----+--'
| | | |
| .-+------------+-. |
| | | Register | | |
.-(-+-' new CoAP `-+-(-.
| | | Content-Format | | |
| | `-------+--------' | |
| | | | |
| | v | |
| | .--------------. | |
| | | Automatically | | |
| | | derive CBOR | | |
| | | tag (RFC 9277) | | |
| | `------+-------' | |
| | | | |
| | | | |
| | | | |
| | v | |
| | .----------------. | |
| | / Tag CMW / | |
v v `----------------' v v
.--------------------------------------.
/ Record CMW /
`--------------------------------------'
Figure 8: How to Create a CMW
図 8: CMW の作成方法
The authors would like to thank Alexey Melnikov, Amanda Baber, Benjamin Schwartz, Brian Campbell, Carl Wallace, Carsten Bormann, Christian Amsüss, Dave Thaler, Deb Cooley, Dionna Glaze, Éric Vyncke, Ionuț Mihalcea, Mahesh Jethanandani, Michael B. Jones, Mike Ounsworth, Michael StJohns, Mike Bishop, Mohamed Boucadair, Mohit Sethi, Orie Steele, Paul Howard, Peter Yee, Russ Housley, Steven Bellock, Tim Bray, Tom Jones, and Usama Sardar for their reviews and suggestions.
著者らは、Alexey Melnikov、Amanda Baber、Benjamin Schwartz、Brian Campbell、Carl Wallace、Carsten Bormann、Christian Amsüss、Dave Thaler、Deb Cooley、Dionna Glaze、Éric Vyncke、Ionuś Mihalcea、Mahesh Jethanandani、Michael B. Jones、Mike Ounsworth、Michael StJohns、Mike Bishop、に感謝します。Mohamed Boucadair 氏、Mohit Sethi 氏、Orie Steele 氏、Paul Howard 氏、Peter Yee 氏、Russ Housley 氏、Steven Bellock 氏、Tim Bray 氏、Tom Jones 氏、Usama Sardar 氏にレビューと提案をしていただきました。
The definition of a Collection CMW has been modeled on a proposal originally made by Simon Frost for an EAT-based Evidence collection type. The Collection CMW aims at superseding it by generalizing the allowed Evidence formats.
コレクション CMW の定義は、もともと Simon Frost によって作成された EAT ベースの証拠コレクション タイプの提案に基づいてモデル化されました。Collection CMW は、許可された証拠フォーマットを一般化することでこれに取って代わることを目的としています。
Laurence Lundblade
Security Theory LLC
Email: lgl@securitytheory.com
Laurence made significant contributions to enhancing the security requirements and considerations for Collection CMWs.
Laurence は、コレクション CMW のセキュリティ要件と考慮事項の強化に大きく貢献しました。
Henk Birkholz
Fraunhofer SIT
Email: henk.birkholz@ietf.contact
Ned Smith
Independent
Email: ned.smith.ietf@outlook.com
Thomas Fossati
Linaro
Email: thomas.fossati@linaro.org
Hannes Tschofenig
University of the Bundeswehr Munich
Institute of Distributed Intelligent Systems
Werner-Heisenberg-Weg 39
85577 Neubiberg
Germany
Email: Hannes.Tschofenig@gmx.net