Internet Engineering Task Force (IETF) F. Palombini
Request for Comments: 9668 Ericsson AB
Category: Standards Track M. Tiloca
ISSN: 2070-1721 R. Höglund
RISE AB
S. Hristozov
Eriptic
G. Selander
Ericsson
November 2024
The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context.
COSE（EDHOC）を介した軽量認証キーエクスチェンジプロトコルの短命型Diffie-Hellmanを制約されたアプリケーションプロトコル（COAP）で実行し、2人のピアが使用して、制約されたRESTFUL環境（OSCORE）のセキュリティプロトコルオブジェクトセキュリティのセキュリティコンテキストを確立することができます。このドキュメントでは、EDHOCの実行と最初のOSCOREトランザクションを組み合わせるための最適化アプローチを含む、多くの追加およびオプションのメカニズムを指定することにより、EDHOCプロトコルのこの使用について詳しく説明しています。この組み合わせにより、OSCOREセキュリティコンテキストを設定し、そのセキュリティコンテキストを使用してOSCOREトランザクションを完了するために必要な往復の数が減ります。
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/rfc9668.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9668で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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. Terminology
2. EDHOC Overview
3. EDHOC Combined with OSCORE
3.1. EDHOC Option
3.2. Client Processing
3.2.1. Processing of the EDHOC + OSCORE Request
3.2.2. Supporting Block-Wise Transfers
3.3. Server Processing
3.3.1. Processing of the EDHOC + OSCORE Request
3.3.2. Supporting Block-Wise Transfers
3.4. Example of the EDHOC + OSCORE Request
4. Use of EDHOC Connection Identifiers with OSCORE
4.1. Additional Processing of EDHOC Messages
4.1.1. Initiator Processing of Message 1
4.1.2. Responder Processing of Message 2
4.1.3. Initiator Processing of Message 2
5. Extension and Consistency of Application Profiles
6. Web Linking
7. Security Considerations
8. IANA Considerations
8.1. CoAP Option Numbers Registry
8.2. Target Attributes Registry
8.3. EDHOC Authentication Credential Types Registry
8.4. Expert Review Instructions
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses
Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] is a lightweight authenticated key exchange protocol that is specifically intended for use in constrained scenarios. In particular, EDHOC messages can be transported over the Constrained Application Protocol (CoAP) [RFC7252] and used for establishing a Security Context for Object Security for Constrained RESTful Environments (OSCORE) [RFC8613].
Ephemeral Diffie-Hellman over Cose（EDHOC）[RFC9528]は、制約されたシナリオで使用することを目的とした軽量認証キーエクスチェンジプロトコルです。特に、EDHOCメッセージは、制約されたアプリケーションプロトコル（COAP）[RFC7252]を介して輸送され、制約されたRESTFUL環境（OSCORE）[RFC8613]のオブジェクトセキュリティのセキュリティコンテキストを確立するために使用できます。
This document details the use of the EDHOC protocol with CoAP and OSCORE and specifies a number of additional and optional mechanisms. These include an optimization approach that combines the EDHOC execution with the first OSCORE transaction (see Section 3). This allows for a minimum number of two round trips necessary to set up the OSCORE Security Context and complete an OSCORE transaction, e.g., when an Internet of Things (IoT) device gets configured in a network for the first time.
このドキュメントでは、EDHOCプロトコルのCOAPおよびOSCOREを使用して使用し、多くの追加およびオプションのメカニズムを指定しています。これらには、EDHOCの実行を最初のOSCOREトランザクションと組み合わせた最適化アプローチが含まれます（セクション3を参照）。これにより、OSCOREセキュリティコンテキストをセットアップし、オスコアトランザクションを完了するために必要な最低2回のラウンド旅行が可能になります。
This optimization is desirable since the number of message exchanges can have a substantial impact on the latency of conveying the first OSCORE request when using certain radio technologies.
メッセージ交換の数は、特定の無線テクノロジーを使用する際に最初のオスコア要求を伝えるレイテンシに大きな影響を与える可能性があるため、この最適化が望ましいです。
Without this optimization, it is not possible to achieve the minimum number of two round trips. This optimization makes it possible since the message_3 of the EDHOC protocol can be made relatively small (see Section 1.2 of [RFC9528]), thus allowing additional OSCORE-protected CoAP data within target MTU sizes.
この最適化がなければ、2回のラウンド旅行の最小数を達成することはできません。この最適化により、EDHOCプロトコルのMessage_3が比較的小さくなる可能性があるため（[RFC9528]セクション1.2を参照）、ターゲットMTUサイズ内の追加のオスコア保護COAPデータが可能になります。
The minimum number of two round trips can be achieved only if the default forward message flow of EDHOC is used, i.e., when a CoAP client acts as EDHOC Initiator and a CoAP server acts as EDHOC Responder. The performance advantage of using this optimization can be lost when used in combination with Block-wise transfers [RFC7959] that rely on specific parameter values and block sizes.
EDHOCのデフォルトのフォワードメッセージフローが使用されている場合、つまりCOAPクライアントがEDHOCイニシエーターとして機能し、COAPサーバーがEDHOCレスポンダーとして機能する場合にのみ、2回のラウンド旅行の最小数を達成できます。この最適化を使用するというパフォーマンスの利点は、特定のパラメーター値とブロックサイズに依存するブロックごとの転送[RFC7959]と組み合わせて使用すると失われる可能性があります。
Furthermore, this document defines a number of parameters corresponding to different information elements of an EDHOC application profile (see Section 6). These parameters can be specified as target attributes in the link to an EDHOC resource associated with that application profile, thus enabling an enhanced discovery of such a resource for CoAP clients.
さらに、このドキュメントでは、EDHOCアプリケーションプロファイルの異なる情報要素に対応する多くのパラメーターを定義します（セクション6を参照）。これらのパラメーターは、そのアプリケーションプロファイルに関連付けられたEDHOCリソースへのリンクのターゲット属性として指定することができるため、COAPクライアント向けのこのようなリソースの強化された発見を可能にします。
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.
キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The reader is expected to be familiar with terms and concepts defined in CoAP [RFC7252], Concise Binary Object Representation (CBOR) [RFC8949], OSCORE [RFC8613], and EDHOC [RFC9528].
読者は、COAP [RFC7252]、簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]、OSCORE [RFC8613]、およびEDHOC [RFC9528]で定義されている用語と概念に精通していることが期待されています。
This section is not normative and summarizes what is specified in [RFC9528] (specifically Appendix A.2 of [RFC9528]). Thus, it provides a baseline for the enhancements in the subsequent sections.
このセクションは規範的ではなく、[RFC9528]で指定されているものを要約します（具体的には[RFC9528]の付録A.2）。したがって、後続のセクションの強化のベースラインを提供します。
The EDHOC protocol specified in [RFC9528] allows two peers to agree on a cryptographic secret in a mutually-authenticated way and achieves forward secrecy by using Diffie-Hellman ephemeral keys. The two peers are denoted as the "Initiator" and "Responder", as the one sending or receiving the initial EDHOC message_1, respectively.
[RFC9528]で指定されているEDHOCプロトコルは、2人のピアが相互に認識された方法で暗号化の秘密に同意することを可能にし、Diffie-Hellman Ephemeral Keysを使用して前進する秘密を達成します。2人のピアは、それぞれ「イニシエーター」および「レスポンダー」として示され、それぞれ最初のEDHOCメッセージ_1を送信または受信します。
After successful processing of EDHOC message_3, both peers agree on a cryptographic secret that can be used to derive further security material and establish an OSCORE Security Context [RFC8613]. The Responder can also send an optional EDHOC message_4 in order for the Initiator to achieve key confirmation, e.g., in deployments where no protected application message is sent from the Responder to the Initiator.
EDHOC Message_3の処理に成功した後、両方のピアは、さらなるセキュリティ資料を導き出し、OSCOREセキュリティコンテキストを確立するために使用できる暗号化の秘密に同意します[RFC8613]。レスポンダーは、イニシエーターが主要な確認を達成するために、オプションのEDHOC Message_4を送信することもできます。
Appendix A.2 of [RFC9528] specifies how to transfer EDHOC over CoAP. That is, the EDHOC data (i.e., the EDHOC message possibly with a prepended connection identifier) is transported in the payload of CoAP requests and responses. The default forward message flow of EDHOC consists in the CoAP client acting as Initiator and the CoAP server acting as Responder (see Appendix A.2.1 of [RFC9528]). Alternatively, the two roles can be reversed as per the reverse message flow of EDHOC (see Appendix A.2.2 of [RFC9528]). In the rest of this document, EDHOC messages are considered to be transferred over CoAP.
[RFC9528]の付録A.2は、EDHOCをCOAPで転送する方法を指定しています。つまり、EDHOCデータ（つまり、おそらくPrearended Connection Identifierを使用したEDHOCメッセージ）は、COAPリクエストと応答のペイロードで輸送されます。EDHOCのデフォルトのフォワードメッセージフローは、イニシエーターとして機能するCOAPクライアントと、レスポンダーとして機能するCOAPサーバーで構成されています（[RFC9528]の付録A.2.1を参照）。あるいは、EDHOCの逆メッセージフローに従って2つの役割を逆転させることができます（[RFC9528]の付録A.2.2を参照）。このドキュメントの残りの部分では、EDHOCメッセージはCOAPを介して転送されると見なされます。
Figure 1 shows a successful execution of EDHOC, with a CoAP client and a CoAP server running EDHOC as Initiator and Responder, respectively. In particular, it extends Figure 10 from Appendix A.2.1 of [RFC9528] by highlighting when the two peers perform EDHOC verification and establish the OSCORE Security Context, and by adding an exchange of OSCORE-protected CoAP messages after completing the EDHOC execution.
図1は、EDHOCの実行の成功を示しています。COAPクライアントとCOAPサーバーが、それぞれイニシエーターとレスポンダーとしてEDHOCを実行しています。特に、2人のピアがEDHOC検証を実行し、OSCOREセキュリティコンテキストを確立したときに強調し、EDHOC実行を完了した後にオスコア保護されたCOAPメッセージの交換を追加することにより、図10を[RFC9528]の付録A.2.1から拡張します。
That is, the client sends a POST request to a reserved EDHOC resource at the server, by default at the Uri-Path "/.well-known/edhoc". The request payload consists of the CBOR simple value true (0xf5) concatenated with EDHOC message_1, which also includes the EDHOC connection identifier C_I of the client encoded as per Section 3.3 of [RFC9528]. The request has Content-Format application/cid-edhoc+cbor-seq.
つまり、クライアントは、デフォルトでURI-Path「/.Well-Nownedhoc」で、サーバーの予約されたEDHOCリソースにPOSTリクエストを送信します。リクエストペイロードは、EDHOC Message_1に合わせたCbor Simple値True（0xf5）で構成されています。リクエストには、コンテンツフォーマットアプリケーション/CID-EDHOC+CBOR-SEQがあります。
This triggers the EDHOC execution at the server, which replies with a 2.04 (Changed) response. The response payload consists of EDHOC message_2, which also includes the EDHOC connection identifier C_R of the server encoded as per Section 3.3 of [RFC9528]. The response has Content-Format application/edhoc+cbor-seq.
これにより、サーバーでのEDHOC実行がトリガーされ、2.04（変更）応答で応答します。応答ペイロードは、[RFC9528]のセクション3.3に従ってエンコードされたサーバーのEDHOC接続識別子C_Rも含まれるEDHOC Message_2で構成されています。応答には、コンテンツフォーマットアプリケーション/EDHOC+CBOR-seqがあります。
Finally, the client sends a POST request to the same EDHOC resource used earlier when it sent EDHOC message_1. The request payload consists of the EDHOC connection identifier C_R encoded as per Section 3.3 of [RFC9528] concatenated with EDHOC message_3. The request has Content-Format application/cid-edhoc+cbor-seq.
最後に、クライアントは、Edhoc Message_1を送信したときに以前に使用された同じEDHOCリソースにPOSTリクエストを送信します。リクエストペイロードは、EDHOC Message_3と連結された[RFC9528]のセクション3.3に従ってエンコードされたEDHOC接続識別子C_Rで構成されています。リクエストには、コンテンツフォーマットアプリケーション/CID-EDHOC+CBOR-SEQがあります。
After this exchange takes place, and after successful verifications as specified in the EDHOC protocol, the client and server can derive an OSCORE Security Context as defined in Appendix A.1 of [RFC9528]. After that, the client and server can use OSCORE to protect their communications as per [RFC8613]. Note that the EDHOC connection identifier C_R is used as the OSCORE Sender ID of the client (see Appendix A.1 of [RFC9528]). Therefore, C_R is transported in the 'kid' field of the OSCORE option of the OSCORE Request (see Section 6.1 of [RFC8613]).
この交換が行われた後、EDHOCプロトコルで指定された評価が成功した後、クライアントとサーバーは[RFC9528]の付録A.1で定義されているようにオスコアセキュリティコンテキストを導き出すことができます。その後、クライアントとサーバーは、[RFC8613]に従ってOSCOREを使用して通信を保護できます。EDHOC接続識別子C_Rは、クライアントのオスコア送信者IDとして使用されていることに注意してください（[RFC9528]の付録A.1を参照）。したがって、C_Rは、OSCOREリクエストのOSCOREオプションの「KID」フィールドで輸送されます（[RFC8613]のセクション6.1を参照）。
The client and server are required to agree in advance on certain information and parameters describing how they should use EDHOC. These are specified in an application profile associated with the EDHOC resource addressed (see Section 3.9 of [RFC9528]).
クライアントとサーバーは、EDHOCを使用する方法を説明する特定の情報とパラメーターについて事前に同意する必要があります。これらは、アドレス指定されたEDHOCリソースに関連付けられたアプリケーションプロファイルで指定されています（[RFC9528]のセクション3.9を参照）。
CoAP client CoAP server
(EDHOC Initiator) (EDHOC Responder)
| |
| |
| ----------------- EDHOC Request -----------------> |
| Header: 0.02 (POST) |
| Uri-Path: "/.well-known/edhoc" |
| Content-Format: application/cid-edhoc+cbor-seq |
| Payload: true, EDHOC message_1 |
| |
| <---------------- EDHOC Response------------------ |
| Header: 2.04 (Changed) |
| Content-Format: application/edhoc+cbor-seq |
| Payload: EDHOC message_2 |
| |
EDHOC verification |
| |
| ----------------- EDHOC Request -----------------> |
| Header: 0.02 (POST) |
| Uri-Path: "/.well-known/edhoc" |
| Content-Format: application/cid-edhoc+cbor-seq |
| Payload: C_R, EDHOC message_3 |
| |
| EDHOC verification
| +
| OSCORE Sec Ctx
| Derivation
| |
| <---------------- EDHOC Response------------------ |
| Header: 2.04 (Changed) |
| Content-Format: application/edhoc+cbor-seq |
| Payload: EDHOC message_4 |
| |
OSCORE Sec Ctx |
Derivation |
| |
| ---------------- OSCORE Request -----------------> |
| Header: 0.02 (POST) |
| OSCORE: { ... ; kid: C_R } |
| Payload: OSCORE-protected data |
| |
| <--------------- OSCORE Response ----------------- |
| Header: 2.04 (Changed) |
| OSCORE: { ... } |
| Payload: OSCORE-protected data |
| |
Figure 1: Sequential Flow of EDHOC and OSCORE with the Optional message_4 Included
図1：オプションのmessage_4を含むedhocとoscoreの連続的な流れ
The sequential flow of EDHOC and OSCORE (where EDHOC runs first and OSCORE is used after) takes three round trips to complete, as shown in Figure 1.
図1に示すように、EdhocとOscore（Edhocが最初に実行され、Oscoreが使用された後、Oscoreが使用される）は3回のラウンド旅行が必要です。
Section 3 defines an optimization for combining EDHOC with the first OSCORE transaction. This reduces the number of round trips required to set up an OSCORE Security Context and complete an OSCORE transaction using that Security Context.
セクション3では、EDHOCを最初のOSCOREトランザクションと組み合わせるための最適化を定義します。これにより、OSCOREセキュリティコンテキストを設定し、そのセキュリティコンテキストを使用してOSCOREトランザクションを完了するために必要な往復の数が減ります。
This section defines an optimization for combining the EDHOC message exchange with the first OSCORE transaction, thus minimizing the number of round trips between the two peers to the absolute possible minimum of two round trips.
このセクションでは、EDHOCメッセージ交換を最初のOSCOREトランザクションと組み合わせるための最適化を定義し、2つのピア間のラウンド旅行の数を最小限に抑えて、2回のラウンド旅行の絶対的な可能性のある最低旅行です。
To this end, this approach can be used only if the default forward message flow of EDHOC is used, i.e., when the client acts as Initiator and the server acts as Responder. The same is not possible in the case with reversed roles as per the reverse message flow of EDHOC.
この目的のために、このアプローチは、EDHOCのデフォルトのフォワードメッセージフローが使用される場合にのみ使用できます。つまり、クライアントがイニシエーターとして機能し、サーバーがレスポンダーとして機能する場合です。EDHOCの逆メッセージフローに従って、逆の役割が逆の場合の場合、同じことは不可能です。
When running the sequential flow of Section 2, the client has all the information to derive the OSCORE Security Context already after receiving EDHOC message_2 and before sending EDHOC message_3.
セクション2のシーケンシャルフローを実行するとき、クライアントは、EDHOC Message_2を受信した後、EDHOC Message_3を送信する前に、オスコアセキュリティコンテキストを既に導き出すためのすべての情報を持っています。
Hence, the client can potentially send both EDHOC message_3 and the subsequent OSCORE Request at the same time. On a semantic level, this requires sending two REST requests at once as shown in Figure 2.
したがって、クライアントは、EDHOC Message_3とその後のOSCOREリクエストの両方を同時に送信する可能性があります。セマンティックレベルでは、図2に示すように、2つのRESTリクエストを一度に送信する必要があります。
CoAP client CoAP server
(EDHOC Initiator) (EDHOC Responder)
| |
| ------------------ EDHOC Request -----------------> |
| Header: 0.02 (POST) |
| Uri-Path: "/.well-known/edhoc" |
| Content-Format: application/cid-edhoc+cbor-seq |
| Payload: true, EDHOC message_1 |
| |
| <----------------- EDHOC Response------------------ |
| Header: 2.04 (Changed) |
| Content-Format: application/edhoc+cbor-seq |
| Payload: EDHOC message_2 |
| |
EDHOC verification |
+ |
OSCORE Sec Ctx |
Derivation |
| |
| -------------- EDHOC + OSCORE Request ------------> |
| Header: 0.02 (POST) |
| OSCORE: { ... ; kid: C_R } |
| Payload: EDHOC message_3 + OSCORE-protected data |
| |
| EDHOC verification
| +
| OSCORE Sec Ctx
| Derivation
| |
| <--------------- OSCORE Response ------------------ |
| Header: 2.04 (Changed) |
| OSCORE: { ... } |
| Payload: OSCORE-protected data |
| |
Figure 2: EDHOC and OSCORE Combined
図2：EdhocとOscoreを組み合わせた
To this end, the specific approach defined in this section consists of sending a single EDHOC + OSCORE request, which conveys the pair (C_R, EDHOC message_3) within an OSCORE-protected CoAP message.
この目的のために、このセクションで定義されている特定のアプローチは、OSCOREで保護されたCOAPメッセージ内でペア（C_R、EDHOC Message_3）を伝える単一のEDHOC + OSCOREリクエストを送信することで構成されています。
That is, the EDHOC + OSCORE request is composed of the following two parts combined together in a single CoAP message. The steps for processing the EDHOC + OSCORE request and the two parts combined in the request itself are defined in Sections 3.2.1 and 3.3.1.
つまり、EDHOC + OSCOREリクエストには、単一のCOAPメッセージで一緒に組み合わされた次の2つの部分で構成されています。EDHOC + OSCORE要求とリクエスト自体で組み合わされた2つの部分を処理する手順は、セクション3.2.1および3.3.1で定義されています。
* The OSCORE Request from Figure 1, which, in this case, is also sent to a protected resource with the correct CoAP method and options intended for accessing that resource.
* 図1からのオスコアリクエストは、この場合、そのリソースへのアクセスを目的とした正しいCOAPメソッドとオプションを備えた保護されたリソースにも送信されます。
* EDHOC data consisting of the pair (C_R, EDHOC message_3) required for completing the EDHOC session transported as follows:
* ペア（C_R、EDHOC Message_3）で構成されるEDHOCデータは、次のように輸送されるEDHOCセッションを完了するために必要です。
- C_R is the OSCORE Sender ID of the client; hence, it is transported in the 'kid' field of the OSCORE option (see Section 6.1 of [RFC8613]). Unlike the sequential workflow shown in Figure 1, C_R is not transported in the payload of the EDHOC + OSCORE request.
- C_Rは、クライアントのオスコア送信者IDです。したがって、オスコアオプションの「子供」フィールドに輸送されます（[RFC8613]のセクション6.1を参照）。図1に示すシーケンシャルワークフローとは異なり、C_RはEDHOC + OSCOREリクエストのペイロードでは輸送されません。
- EDHOC message_3 is transported in the payload of the EDHOC + OSCORE request and prepended to the payload of the OSCORE Request. This is because EDHOC message_3 may be too large to be included in a CoAP option, e.g., when conveying a large public key certificate chain in the ID_CRED_I field (see Section 3.5.3 of [RFC9528]), or when conveying large External Authorization Data in the EAD_3 field (see Section 3.8 of [RFC9528]).
- EDHOC Message_3は、EDHOC + OSCOREリクエストのペイロードで輸送され、OSCOREリクエストのペイロードに加えられます。これは、EDHOC Message_3がCOAPオプションに含まれるには大きすぎる可能性があるためです。たとえば、ID_CRED_Iフィールドで大きな公開キーの証明書チェーンを伝えるとき（[RFC9528]のセクション3.5.3を参照）、または大規模な外部認証データを伝えるときですEAD_3フィールドで（[RFC9528]のセクション3.8を参照）。
The rest of this section specifies how to transport the data in the EDHOC + OSCORE request and their processing order. In particular, the use of this approach is explicitly signalled by including an EDHOC option (Section 3.1) in the EDHOC + OSCORE request. The processing of the EDHOC + OSCORE request is specified in Section 3.2 for the client side and in Section 3.3 for the server side.
このセクションの残りの部分では、EDHOC + OSCOREリクエストとその処理順序でデータを輸送する方法を指定します。特に、このアプローチの使用は、EDHOC + OSCOREリクエストにEDHOCオプション（セクション3.1）を含めることにより、明示的にシグナル付けされます。EDHOC + OSCOREリクエストの処理は、クライアント側のセクション3.2とサーバー側のセクション3.3で指定されています。
This section defines the EDHOC option. This option is used in a CoAP request to signal that the request payload conveys both an EDHOC message_3 and OSCORE-protected data combined together.
このセクションでは、EDHOCオプションを定義します。このオプションは、COAPリクエストで使用され、要求のペイロードがEDHOC Message_3とOSCORE保護データの両方を組み合わせて伝えることを信号します。
The EDHOC option has the properties summarized in Table 1, which extends Table 4 of [RFC7252]. The option is Critical, Safe-to-Forward, and part of the Cache-Key. The option MUST occur at most once and MUST be empty. If any value is sent, the recipient MUST ignore it. (Future documents may update the definition of the option by expanding its semantics and specifying admitted values.) The option is intended only for CoAP requests and is of Class U for OSCORE [RFC8613].
EDHOCオプションには、[RFC7252]の表4を拡張する表1にまとめたプロパティがあります。オプションは重要で、安全で、キャッシュキーの一部です。オプションはせいぜい1回発生する必要があり、空でなければなりません。値が送信された場合、受信者はそれを無視する必要があります。（将来のドキュメントは、セマンティクスを拡張し、認められた値を指定することにより、オプションの定義を更新する場合があります。）オプションはCOAP要求のみを目的とし、OSCORE [RFC8613]のクラスUのものです。
+=====+===+===+===+===+=======+========+========+=========+
| No. | C | U | N | R | Name | Format | Length | Default |
+=====+===+===+===+===+=======+========+========+=========+
| 21 | x | | | | EDHOC | Empty | 0 | (none) |
+-----+---+---+---+---+-------+--------+--------+---------+
Table 1: The EDHOC Option. C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
表1：EDHOCオプション。c =クリティカル、u = unsafe、n = nocachekey、r =繰り返し可能
The presence of this option means that the message payload also contains EDHOC data that must be extracted and processed as defined in Section 3.3 before the rest of the message can be processed.
このオプションの存在は、メッセージペイロードに、メッセージの残りの部分を処理する前にセクション3.3で定義されているように抽出および処理する必要があるEDHOCデータも含まれることを意味します。
Figure 3 shows an example of a CoAP message that is transported over UDP and that contains both the EDHOC data and the OSCORE ciphertext using the newly defined EDHOC option for signalling.
図3は、UDPを介して輸送されるCOAPメッセージの例を示しています。これは、新たに定義されたEDHOCオプションを使用してEDHOCデータとOSCORE暗号文を含むものです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observe Option| OSCORE Option ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EDHOC Option | Other Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Example of a CoAP Message Containing the Combined EDHOC and OSCORE Data, Signalled by the EDHOC Option and Transported over UDP
図3：EDHOCオプションによって合図され、UDPを介して輸送されたEDHOCとOSCOREデータを組み合わせたCOAPメッセージの例
This section describes the processing on the client side.
このセクションでは、クライアント側の処理について説明します。
The client prepares an EDHOC + OSCORE request as follows.
クライアントは、次のようにEDHOC + OSCOREリクエストを準備します。
Step 1. Compose EDHOC message_3 into EDHOC_MSG_3 as per Section 5.4.2 of [RFC9528].
ステップ1。[RFC9528]のセクション5.4.2に従って、EDHOC Message_3をEDHOC_MSG_3に構成します。
Step 2. Establish the new OSCORE Security Context and use it to encrypt the original CoAP request as per Section 8.1 of [RFC8613].
ステップ2。[RFC8613]のセクション8.1に従って、新しいOSCOREセキュリティコンテキストを確立し、それを使用して元のCOAP要求を暗号化します。
Note that the OSCORE ciphertext is not computed over EDHOC message_3, which is not protected by OSCORE. That is, the result of this step is the OSCORE Request as in Figure 1.
OSCORE暗号文は、OSCOREによって保護されていないEDHOC Message_3を介して計算されていないことに注意してください。つまり、このステップの結果は、図1のようにオスコアリクエストです。
Step 3. Build COMB_PAYLOAD as the concatenation of EDHOC_MSG_3 and OSCORE_PAYLOAD in the order of COMB_PAYLOAD = EDHOC_MSG_3 | OSCORE_PAYLOAD, where | denotes byte string concatenation and:
ステップ3. comb_payload = edhoc_msg_3の順序でのedhoc_msg_3とoscore_payloadの連結としてcomb_payloadを構築する|oscore_payload、ここで|バイト文字列の連結と：
* EDHOC_MSG_3 is the binary encoding of EDHOC message_3 resulting from Step 1. As per Section 5.4.1 of [RFC9528], EDHOC message_3 consists of one CBOR data item CIPHERTEXT_3, which is a CBOR byte string. Therefore, EDHOC_MSG_3 is the binary encoding of CIPHERTEXT_3.
* EDHOC_MSG_3は、[RFC9528]のセクション5.4.1によると、ステップ1から生じるEDHOC Message_3のバイナリエンコーディングです。EDHOCメッセージ_3は、Cborバイト文字列である1つのCborデータ項目Ciphertext_3で構成されています。したがって、EDHOC_MSG_3はCiphertext_3のバイナリエンコードです。
* OSCORE_PAYLOAD is the OSCORE ciphertext of the OSCORE-protected CoAP request resulting from Step 2.
* OSCORE_PAYLOADは、ステップ2から生じるOSCORE保護のCOAP要求のOSCORE暗号です。
Step 4. Compose the EDHOC + OSCORE request, as the OSCORE-protected CoAP request resulting from Step 2, where the payload is replaced with COMB_PAYLOAD built at Step 3.
ステップ4。EDHOC + OSCOREリクエストを作成します。これは、ステップ2でペイロードがcomb_payloadに置き換えられたステップ2から生じるオスコア保護のCOAPリクエストとして構成します。
Note that the new payload includes EDHOC message_3, but it does not include the EDHOC connection identifier C_R. As the client is the EDHOC Initiator, C_R is the OSCORE Sender ID of the client, which is already specified as the value of the 'kid' field in the OSCORE option of the request from Step 2; hence, C_R is specified as the value of the 'kid' field of the EDHOC + OSCORE request.
新しいペイロードにはEDHOC Message_3が含まれていますが、EDHOC接続識別子C_Rは含まれていません。クライアントはEDHOCイニシエーターであるため、C_Rはクライアントのオスコア送信者IDであり、ステップ2からのリクエストのオスコアオプションの「KID」フィールドの値として既に指定されています。したがって、C_Rは、EDHOC + OSCOREリクエストの「KID」フィールドの値として指定されています。
Step 5. Include the new EDHOC option defined in Section 3.1 into the EDHOC + OSCORE request.
ステップ5。EDHOC + OSCOREリクエストにセクション3.1で定義されている新しいEDHOCオプションを含めます。
The application/cid-edhoc+cbor-seq media type does not apply to this message, whose media type is unnamed.
アプリケーション/CID-EDHOC+CBOR-SEQメディアタイプは、メディアタイプが名前が付けられていないこのメッセージには適用されません。
Step 6. Send the EDHOC + OSCORE request to the server.
ステップ6。EDHOC + OSCOREリクエストをサーバーに送信します。
With the same server, the client SHOULD NOT have multiple simultaneous outstanding interactions (see Section 4.7 of [RFC7252]), such that they consist of an EDHOC + OSCORE request and their EDHOC data pertains to the EDHOC session with the same connection identifier C_R.
同じサーバーを使用すると、クライアントは複数の同時の未解決の相互作用を持たないように（[RFC7252]のセクション4.7を参照）、EDHOC + OSCOREリクエストで構成され、EDHOCデータは同じ接続識別子C_Rを使用してEDHOCセッションに関係しています。
An exception might apply for clients that operate under particular time constraints over particularly unreliable networks, thus raising the chances to promptly complete the EDHOC execution with the server through multiple simultaneous EDHOC + OSCORE requests. As discussed in Section 7, this does not have any impact in terms of security.
特に信頼性の低いネットワーク上の特定の時間制約の下で動作するクライアントには例外が適用される場合があります。そのため、複数の同時のEDHOC + OSCOREリクエストを介してサーバーでEDHOCの実行を迅速に完了する可能性が高くなります。セクション7で説明したように、これはセキュリティの面で影響を与えません。
If Block-wise transfers [RFC7959] are supported, the client may fragment the first CoAP application request before protecting it as an original message with OSCORE as defined in Section 4.1.3.4.1 of [RFC8613].
ブロックごとの転送[RFC7959]がサポートされている場合、クライアントは、[RFC8613]のセクション4.1.3.4.1で定義されているように、オスコアとの元のメッセージとして保護する前に、最初のCOAPアプリケーションリクエストを断片化する場合があります。
In such a case, the OSCORE processing in Step 2 of Section 3.2.1 is performed on each inner block of the first CoAP application request. The following also applies.
このような場合、セクション3.2.1のステップ2のオスコア処理は、最初のCOAPアプリケーションリクエストの各内部ブロックで実行されます。以下も適用されます。
* The client takes the following additional step between Steps 2 and 3 of Section 3.2.1.
* クライアントは、セクション3.2.1の手順2と3の間に次の追加ステップを踏みます。
Step 2.1. If the OSCORE-protected request from Step 2 conveys a non-first inner block of the first CoAP application request (i.e., the Block1 option processed at Step 2 had NUM different than 0), then the client skips the following steps and sends the OSCORE-protected request to the server. In particular, the client MUST NOT include the EDHOC option in the OSCORE-protected request.
ステップ2.1。ステップ2からのOSCORE保護リクエストが、最初のCoAPアプリケーションリクエストの非ファースト内部ブロック（つまり、ステップ2で処理されたBlock1オプションが0よりも異なる場合）を伝えた場合、クライアントは次の手順をスキップしてOSCOREを送信します- サーバーへの保護されたリクエスト。特に、クライアントはOSCORE保護リクエストにEDHOCオプションを含めてはなりません。
* The client takes the following additional step between Steps 3 and 4 of Section 3.2.1.
* クライアントは、セクション3.2.1のステップ3と4の間に次の追加ステップを踏みます。
Step 3.1. If the size of COMB_PAYLOAD exceeds MAX_UNFRAGMENTED_SIZE (see Section 4.1.3.4.2 of [RFC8613]), the client MUST stop processing the request and MUST abandon the Block-wise transfer. Then, the client can continue by switching to the sequential workflow shown in Figure 1. That is, the client first sends EDHOC message_3 prepended by the EDHOC connection identifier C_R encoded as per Section 3.3 of [RFC9528]. Then, the client sends the OSCORE-protected CoAP request once the EDHOC execution is completed.
ステップ3.1。comb_payloadのサイズがmax_unfragmented_sizeを超える場合（[rfc8613]のセクション4.1.3.4.2を参照）、クライアントは要求の処理を停止する必要があり、ブロックごとの転送を放棄する必要があります。次に、クライアントは、図1に示すシーケンシャルワークフローに切り替えて続行できます。つまり、クライアントは最初に[RFC9528]のセクション3.3に従ってエンコードされたEDHOC接続識別子C_RによってPREACEDED EDHOC Message_3を送信します。次に、EDHOCの実行が完了すると、クライアントはオスコア保護のCOAP要求を送信します。
The performance advantage of using the EDHOC + OSCORE request can be lost when used in combination with Block-wise transfers that rely on specific parameter values and block sizes. Application policies at the CoAP client can define when and how to detect whether the performance advantage is lost. If that is the case, they can also define whether to appropriately adjust the parameter values and block sizes or to fall back on the sequential workflow of EDHOC.
EDHOC + OSCOREリクエストを使用するというパフォーマンスの利点は、特定のパラメーター値とブロックサイズに依存するブロックごとの転送と組み合わせて使用すると失われる可能性があります。COAPクライアントのアプリケーションポリシーは、パフォーマンスの優位性が失われるかどうかをいつ、どのように検出するかを定義できます。その場合、パラメーター値とブロックサイズを適切に調整するか、EDHOCのシーケンシャルワークフローに頼るかを定義することもできます。
This section describes the processing on the server side.
このセクションでは、サーバー側の処理について説明します。
In order to process a request containing the EDHOC option, i.e., an EDHOC + OSCORE request, the server MUST perform the following steps.
EDHOCオプション、つまりEDHOC + OSCOREリクエストを含むリクエストを処理するには、サーバーは次の手順を実行する必要があります。
Step 1. Check that the EDHOC + OSCORE request includes the OSCORE option and that the request payload has the format defined at Step 3 of Section 3.2.1 for COMB_PAYLOAD. If this is not the case, the server MUST stop processing the request and MUST reply with a 4.00 (Bad Request) error response.
ステップ1。EDHOC + OSCOREリクエストにOSCOREオプションが含まれていること、およびリクエストペイロードにComb_Payloadのセクション3.2.1のステップ3で定義されている形式があることを確認します。そうでない場合、サーバーはリクエストの処理を停止する必要があり、4.00（悪い要求）エラー応答で返信する必要があります。
Step 2. Extract EDHOC message_3 from the payload COMB_PAYLOAD of the EDHOC + OSCORE request as the first element EDHOC_MSG_3 (see Step 3 of Section 3.2.1).
ステップ2。edhoc + oscore要求のペイロードcomb_payloadからedhoc message_3を抽出します。
Step 3. Take the value of the 'kid' field from the OSCORE option of the EDHOC + OSCORE request (i.e., the OSCORE Sender ID of the client), and use it as the EDHOC connection identifier C_R.
ステップ3。EDHOC + OSCOREリクエスト（つまり、クライアントのOSCORE SENDER ID）のOSCOREオプションから「KID」フィールドの値を取得し、EDHOC接続識別子C_Rとして使用します。
Step 4. Retrieve the correct EDHOC session by using the connection identifier C_R from Step 3.
ステップ4。ステップ3の接続識別子C_Rを使用して、正しいEDHOCセッションを取得します。
If the application profile used in the EDHOC session specifies that EDHOC message_4 shall be sent, the server MUST stop the EDHOC processing and consider it failed due to a client error.
EDHOCセッションで使用されるアプリケーションプロファイルがEDHOC Message_4を送信することを指定する場合、サーバーはEDHOC処理を停止し、クライアントエラーのために失敗したと考える必要があります。
Otherwise, perform the EDHOC processing on the EDHOC message_3 extracted at Step 2 as per Section 5.4.3 of [RFC9528] based on the protocol state of the retrieved EDHOC session.
それ以外の場合は、取得したEDHOCセッションのプロトコル状態に基づいて、[RFC9528]のセクション5.4.3に従って、ステップ2で抽出されたEDHOC Message_3でEDHOC処理を実行します。
The application profile used in the EDHOC session is the same one associated with the EDHOC resource where the server received the request conveying EDHOC message_1 that started the session. This is relevant in case the server provides multiple EDHOC resources that may generally refer to different application profiles.
EDHOCセッションで使用されるアプリケーションプロファイルは、セッションを開始したEDHOC Message_1を伝達するリクエストをサーバーが受信したEDHOCリソースに関連付けられているものと同じです。これは、サーバーが一般に異なるアプリケーションプロファイルを参照する可能性のある複数のEDHOCリソースを提供する場合に関連しています。
Step 5. Establish a new OSCORE Security Context associated with the client as per Appendix A.1 of [RFC9528] using the EDHOC output from Step 4.
ステップ5。ステップ4からのEDHOC出力を使用して、[RFC9528]の付録A.1に従って、クライアントに関連付けられた新しいオスコアセキュリティコンテキストを確立します。
Step 6. Extract the OSCORE ciphertext from the payload COMB_PAYLOAD of the EDHOC + OSCORE request as the second element OSCORE_PAYLOAD (see Step 3 of Section 3.2.1).
ステップ6。EDHOC + OSCORE要求のペイロードComb_PayloadからOSCORE暗号文を抽出してください。
Step 7. Rebuild the OSCORE-protected CoAP request as the EDHOC + OSCORE request, where the payload is replaced with the OSCORE ciphertext extracted at Step 6. Then, remove the EDHOC option.
ステップ7。OSCOREで保護されたCOAP要求をEDHOC + OSCOREリクエストとして再構築します。ここで、ステップ6で抽出されたOSCORE暗号文にペイロードを置き換えます。次に、EDHOCオプションを削除します。
Step 8. Decrypt and verify the OSCORE-protected CoAP request rebuilt at Step 7 as per Section 8.2 of [RFC8613] by using the OSCORE Security Context established at Step 5.
ステップ8。ステップ5で確立されたOSCOREセキュリティコンテキストを使用して、[RFC8613]のセクション8.2に従って、ステップ7で再建されたOSCORE保護のCOAPリクエストを復号化および検証します。
When the decrypted request is checked for any critical CoAP options (as it is during regular CoAP processing), the presence of an EDHOC option MUST be regarded as an unprocessed critical option unless it is processed by some further mechanism.
復号化されたリクエストに重要なCOAPオプションが（通常のCOAP処理中）にチェックされる場合、EDHOCオプションの存在は、さらなるメカニズムによって処理されない限り、未処理の重要なオプションと見なされなければなりません。
Step 9. Deliver the CoAP request resulting from Step 8 to the application.
ステップ9。ステップ8からアプリケーションまでのCOAPリクエストを配信します。
If Steps 4 (EDHOC processing) and 8 (OSCORE processing) are both successfully completed, the server MUST reply with an OSCORE-protected response (see Section 5.4.3 of [RFC9528]). The usage of EDHOC message_4 as defined in Section 5.5 of [RFC9528] is not applicable to the approach defined in this document.
ステップ4（EDHOC処理）と8（OSCORE処理）が両方とも正常に完了した場合、サーバーはオスコア保護された応答で返信する必要があります（[RFC9528]のセクション5.4.3を参照）。[RFC9528]のセクション5.5で定義されているEDHOC Message_4の使用は、このドキュメントで定義されているアプローチには適用されません。
If Step 4 (EDHOC processing) fails, the server aborts the session as per Section 5.4.3 of [RFC9528] and responds with an EDHOC error message with error code 1, which is formatted as defined in Section 6.2 of [RFC9528]. The server MUST NOT establish a new OSCORE Security Context from the present EDHOC session with the client. The CoAP response conveying the EDHOC error message is not protected with OSCORE. As per Section 9.5 of [RFC9528], the server has to make sure that the error message does not reveal sensitive information. The CoAP response conveying the EDHOC error message MUST have Content-Format set to application/edhoc+cbor-seq registered in Section 10.9 of [RFC9528].
ステップ4（EDHOC処理）が失敗した場合、サーバーは[RFC9528]のセクション5.4.3に従ってセッションを中止し、[RFC9528]のセクション6.2で定義されているようにフォーマットされているエラーコード1のEDHOCエラーメッセージで応答します。サーバーは、クライアントとの現在のEDHOCセッションから新しいOSCOREセキュリティコンテキストを確立してはなりません。EDHOCエラーメッセージを伝えるCOAP応答は、OSCOREで保護されていません。[RFC9528]のセクション9.5によると、サーバーはエラーメッセージが機密情報を明らかにしないことを確認する必要があります。EDHOCエラーメッセージを伝えるCOAP応答には、[RFC9528]のセクション10.9に登録されているApplication/EDHOC+CBOR-SEQに設定されている必要があります。
If Step 4 (EDHOC processing) is successfully completed but Step 8 (OSCORE processing) fails, the same OSCORE error handling as defined in Section 8.2 of [RFC8613] applies.
ステップ4（EDHOC処理）が正常に完了したが、ステップ8（OSCORE処理）が失敗した場合、[RFC8613]のセクション8.2で定義されているのと同じオスコアエラー処理が適用されます。
If Block-wise transfers [RFC7959] are supported, the server takes the additional following step before any other in Section 3.3.1.
ブロックごとの転送[RFC7959]がサポートされている場合、サーバーはセクション3.3.1で他の段階で追加の次のステップを実行します。
Step 0. If a Block option is present in the request, then process the Outer Block options according to [RFC7959] until all blocks of the request have been received (see Section 4.1.3.4 of [RFC8613]).
ステップ0。要求にブロックオプションが存在する場合、リクエストのすべてのブロックが受信されるまで[RFC7959]に従って外側ブロックオプションを処理します（[RFC8613]のセクション4.1.3.4を参照）。
Figure 4 shows an example of an EDHOC + OSCORE request transported over UDP. In particular, the example assumes that:
図4は、UDPを介して輸送されたEDHOC + OSCOREリクエストの例を示しています。特に、例は次のとおりです。
* The OSCORE Partial IV in use is 0 consistently with the first request protected with the new OSCORE Security Context.
* 使用中のオスコア部分IVは、新しいOSCOREセキュリティコンテキストで保護された最初の要求と一貫して0です。
* The OSCORE Sender ID of the client is 0x01.
* クライアントのオスコア送信者IDは0x01です。
As per Section 3.3.3 of [RFC9528], this straightforwardly corresponds to the EDHOC connection identifier C_R 0x01.
[RFC9528]のセクション3.3.3によると、これはEDHOC接続識別子C_R 0x01に簡単です。
As per Section 3.3.2 of [RFC9528], when using the sequential flow shown in Figure 1, the same C_R with a value of 0x01 would be encoded on the wire as the CBOR integer 1 (0x01 in CBOR encoding) and prepended to EDHOC message_3 in the payload of the second EDHOC request.
[RFC9528]のセクション3.3.2に従って、図1に示すシーケンシャルフローを使用すると、0x01の値を持つ同じC_RがCbor整数1（CBORエンコーディングでは0x01）としてワイヤ上にエンコードされ、edhocに就任します。2番目のEDHOCリクエストのペイロードのmessage_3。
This results in the following components shown in Figure 4:
これにより、図4に示す次のコンポーネントが得られます。
OSCORE option value:
OSCOREオプション値：
0x090001 (3 bytes)
0x090001（3バイト）
EDHOC option value:
EDHOCオプション値：
- (0 bytes)
- （0バイト）
EDHOC message_3:
edhoc message_3：
0x52d5535f3147e85f1cfacd9e78abf9e0a81bbf (19 bytes)
0x52D5535F3147E85F1CFACD9E78ABF9E0A81BBF（19バイト）
OSCORE ciphertext:
Oscore ciphertext：
0x612f1092f1776f1c1668b3825e (13 bytes)
0x612F1092F1776F1C1668B3825E（13バイト）
0x44025d1f ; CoAP 4-byte Header
00003974 ; Token
93 090001 ; OSCORE Option
c0 ; EDHOC Option
ff 52d5535f3147e85f1cfacd9e78abf9e0a81bbf
612f1092f1776f1c1668b3825e
(46 bytes)
Figure 4: Example of a Protected CoAP Request Combining EDHOC and OSCORE Data
図4：EDHOCとOSCOREデータを組み合わせた保護されたCOAP要求の例
The OSCORE Sender/Recipient IDs are the EDHOC connection identifiers (see Section 3.3.3 of [RFC9528]). This applies also to the optimized workflow defined in Section 3 of this document.
OSCORE送信者/受信者IDは、EDHOC接続識別子です（[RFC9528]のセクション3.3.3を参照）。これは、このドキュメントのセクション3で定義されている最適化されたワークフローにも適用されます。
Note that the value of the 'kid' field in the OSCORE option of the EDHOC + OSCORE request is both the server's Recipient ID (i.e., the client's Sender ID) and the EDHOC connection identifier C_R of the server at Step 3 of Section 3.3.1.
EDHOC + OSCORE要求のOSCOREオプションの「KID」フィールドの値は、セクション3.3のステップ3のサーバーのサーバーの受信者ID（つまり、クライアントの送信者ID）とサーバーのEDHOC接続識別子C_Rの両方であることに注意してください。1。
When using EDHOC to establish an OSCORE Security Context, the client and server MUST perform the following additional steps during an EDHOC execution, thus extending Section 5 of [RFC9528].
EDHOCを使用してOSCOREセキュリティコンテキストを確立する場合、クライアントとサーバーは、EDHOCの実行中に次の追加手順を実行する必要があり、[RFC9528]のセクション5を拡張する必要があります。
The Initiator selects an EDHOC connection identifier C_I as follows.
イニシエーターは、EDHOC接続識別子C_Iを次のように選択します。
The Initiator MUST choose a C_I that is neither used in any current EDHOC session as this peer's EDHOC connection identifier nor the Recipient ID in a current OSCORE Security Context where the ID Context is not present.
イニシエーターは、IDコンテキストが存在しない現在のオスコアセキュリティコンテキストで、このピアのEDHOC接続識別子または受信者IDとして、現在のEDHOCセッションでは使用されないC_Iを選択する必要があります。
The chosen C_I SHOULD NOT be the Recipient ID of any current OSCORE Security Context. Note that, unless the two peers concurrently use alternative methods to establish OSCORE Security Contexts, this allows the Responder to always omit the 'kid context' in the OSCORE option of its messages sent to the Initiator when protecting those with an OSCORE Security Context where C_I is the Responder's OSCORE Sender ID (see Section 6.1 of [RFC8613]).
選択されたC_Iは、現在のOSCOREセキュリティコンテキストの受信者IDであってはなりません。2人のピアが代替方法を同時に使用してオスコアセキュリティコンテキストを確立しない限り、これにより、c_iがあるオスコアセキュリティコンテキストでそれらを保護するときに、イニシエーターに送信されたメッセージのオスコアオプションの「子供のコンテキスト」を常に省略することができることに注意してください。ResponderのOSCORE送信者IDです（[RFC8613]のセクション6.1を参照）。
The Responder selects an EDHOC connection identifier C_R as follows.
レスポンダーは、次のようにEDHOC接続識別子C_Rを選択します。
The Responder MUST choose a C_R that is none of the following:
応答者は、次のいずれでもないC_Rを選択する必要があります。
* used in any current EDHOC session as this peer's EDHOC connection identifier,
* このピアのEDHOC接続識別子として現在のEDHOCセッションで使用されています。
* equal to the EDHOC connection identifier C_I specified in the EDHOC message_1 of the present EDHOC session, or
* 現在のEDHOCセッションのEDHOC Message_1で指定されたEDHOC接続識別子C_Iに等しい、または
* the Recipient ID in a current OSCORE Security Context where the ID Context is not present.
* IDコンテキストが存在しない現在のOSCOREセキュリティコンテキストの受信者ID。
The chosen C_R SHOULD NOT be the Recipient ID of any current OSCORE Security Context. Note that, for a reason analogous to the one given in Section 4.1.1 with C_I, this allows the Initiator to always omit the 'kid context' in the OSCORE option of its messages sent to the Responder when protecting those with an OSCORE Security Context where C_R is the Initiator's OSCORE Sender ID (see Section 6.1 of [RFC8613]).
選択されたC_Rは、現在のOSCOREセキュリティコンテキストの受信者IDであってはなりません。C_Iを使用してセクション4.1.1に記載されている理由に類似した理由で、これにより、イニシエーターは、オスコアセキュリティコンテキストを持つ人を保護するときに、応答者に送信されたメッセージのオスコアオプションの「子供のコンテキスト」を常に省略できることに注意してください。ここで、C_Rはイニシエーターのオスコア送信者IDです（[RFC8613]のセクション6.1を参照）。
If the EDHOC connection identifier C_I is equal to the EDHOC connection identifier C_R specified in EDHOC message_2, then the Initiator MUST abort the session and reply with an EDHOC error message with error code 1 formatted as defined in Section 6.2 of [RFC9528].
EDHOC接続識別子C_IがEDHOC Message_2で指定されたEDHOC接続識別子C_Rに等しい場合、イニシエーターはセッションを中止し、[RFC9528]のセクション6.2で定義されたエラーコード1を使用してEDHOCエラーメッセージで返信する必要があります。
It is possible to include the information below in the application profile referred by the client and server according to the specified consistency rules.
指定された一貫性ルールに従って、クライアントとサーバーが紹介するアプリケーションプロファイルに以下の情報を含めることができます。
If the server supports the EDHOC + OSCORE request within an EDHOC execution started at a certain EDHOC resource, then the application profile associated with that resource SHOULD explicitly specify support for the EDHOC + OSCORE request.
サーバーが特定のEDHOCリソースで開始されたEDHOC実行内のEDHOC + OSCORE要求をサポートする場合、そのリソースに関連付けられたアプリケーションプロファイルは、EDHOC + OSCOREリクエストのサポートを明示的に指定する必要があります。
In the case where the application profile indicates that the server supports the optional EDHOC message_4 (see Section 5.5 of [RFC9528]), it is still possible to use the optimized workflow based on the EDHOC + OSCORE request. However, this means that the server is not going to send EDHOC message_4 since it is not applicable to the optimized workflow (see Section 3.3.1).
アプリケーションプロファイルが、サーバーがオプションのEDHOC Message_4をサポートしていることを示している場合（[RFC9528]のセクション5.5を参照）、EDHOC + OSCOREリクエストに基づいて最適化されたワークフローを使用することができます。ただし、これは、最適化されたワークフローに適用できないため、サーバーがEDHOC Message_4を送信しないことを意味します（セクション3.3.1を参照）。
Also, in the case where the application profile indicates that the server shall send EDHOC message_4, the application profile MUST NOT specify support for the EDHOC + OSCORE request. There is no point for the client to use the optimized workflow that is bound to fail (see Section 3.3.1).
また、アプリケーションプロファイルがサーバーがEDHOC Message_4を送信することを示している場合、アプリケーションプロファイルはEDHOC + OSCOREリクエストのサポートを指定してはなりません。クライアントが故障する最適化されたワークフローを使用することは意味がありません（セクション3.3.1を参照）。
Section 10.10 of [RFC9528] registers the resource type "core.edhoc", which can be used as target attribute in a web link [RFC8288] to an EDHOC resource, e.g., using a link-format document [RFC6690]. This enables clients to discover the presence of EDHOC resources at a server, possibly using the resource type as a filter criterion.
[RFC9528]のセクション10.10は、リソースタイプ「core.edhoc」を登録します。これは、リンクフォーマットドキュメント[RFC6690]を使用して、Webリンク[RFC8288]のターゲット属性[RFC8288]としてEDHOCリソースに使用できます。これにより、クライアントはサーバーでEDHOCリソースの存在を発見することができ、おそらくリソースタイプをフィルター基準として使用することができます。
At the same time, the application profile associated with an EDHOC resource provides information describing how the EDHOC protocol can be used through that resource. A client may become aware of the application profile, e.g., by obtaining its information elements upon discovering the EDHOC resources at the server. This allows the client to discover the EDHOC resources whose associated application profile denotes a way of using EDHOC that is most suitable to the client, e.g., with EDHOC cipher suites or authentication methods that the client also supports or prefers.
同時に、EDHOCリソースに関連付けられたアプリケーションプロファイルは、そのリソースを介してEDHOCプロトコルを使用する方法を説明する情報を提供します。クライアントは、たとえば、サーバーでEDHOCリソースを発見したときに情報要素を取得することにより、アプリケーションプロファイルを認識することができます。これにより、クライアントは、クライアントがサポートまたは好みのEDHOC Cipherスイートまたは認証方法など、クライアントに最も適したEDHOCを使用する方法を示すAssative Applicationプロファイルを示すEDHOCリソースを発見できます。
That is, while discovering an EDHOC resource, a client can contextually obtain relevant pieces of information from the application profile associated with that resource. The resource discovery can occur by means of a direct interaction with the server or by means of the CoRE Resource Directory [RFC9176] where the server may have registered the links to its resources.
つまり、EDHOCリソースを発見しながら、クライアントはそのリソースに関連付けられたアプリケーションプロファイルから関連する情報を文脈的に取得できます。リソースの発見は、サーバーとの直接的な相互作用によって、またはサーバーがリソースへのリンクを登録した可能性のあるコアリソースディレクトリ[RFC9176]によって発生する可能性があります。
In order to enable the above, this section defines a number of parameters, each of which can be optionally specified as a target attribute with the same name in the link to the respective EDHOC resource or as filter criterion in a discovery request from the client. When specifying these parameters in a link to an EDHOC resource, the target attribute rt="core.edhoc" MUST be included and the same consistency rules defined in Section 5 for the corresponding information elements of an application profile MUST be followed.
上記を有効にするために、このセクションでは、それぞれがそれぞれのエドホックリソースへのリンクに同じ名前を持つターゲット属性として、またはクライアントからのディスカバリーリクエストのフィルター基準としてオプションとして指定できます。EDHOCリソースへのリンクでこれらのパラメーターを指定する場合、ターゲット属性rt = "core.edhoc"を含める必要があり、アプリケーションプロファイルの対応する情報要素についてセクション5で定義されている同じ一貫性ルールを守る必要があります。
The following parameters are defined.
次のパラメーターが定義されています。
'ed-i':
'ed-i'：
If present, specifies that the server supports the EDHOC Initiator role, hence the reverse message flow of EDHOC. A value MUST NOT be given to this parameter and any present value MUST be ignored by the recipient.
存在する場合、サーバーがEDHOCイニシエーターの役割をサポートすることを指定するため、EDHOCの逆メッセージフローがあります。このパラメーターに値を与えてはならず、現在の値は受信者が無視する必要があります。
'ed-r':
'ed-r'：
If present, specifies that the server supports the EDHOC Responder role, hence the forward message flow of EDHOC. A value MUST NOT be given to this parameter and any present value MUST be ignored by the recipient.
存在する場合、サーバーがEDHOCレスポンダーの役割をサポートすることを指定します。このパラメーターに値を与えてはならず、現在の値は受信者が無視する必要があります。
'ed-method':
「ed-method」：
Specifies an authentication method supported by the server. This parameter MUST specify a single value, which is taken from the 'Value' column of the "EDHOC Method Type" registry defined in Section 10.3 of [RFC9528]. This parameter MAY occur multiple times, with each occurrence specifying an authentication method.
サーバーがサポートする認証方法を指定します。このパラメーターは、[RFC9528]のセクション10.3で定義されている「EDHOCメソッドタイプ」レジストリの「値」列から取得される単一の値を指定する必要があります。このパラメーターは複数回発生する可能性があり、それぞれが認証方法を指定します。
'ed-csuite':
「ed-csuite」：
Specifies an EDHOC cipher suite supported by the server. This parameter MUST specify a single value, which is taken from the 'Value' column of the "EDHOC Cipher Suites" registry defined in Section 10.2 of [RFC9528]. This parameter MAY occur multiple times, with each occurrence specifying a cipher suite.
サーバーでサポートされているEDHOC Cipherスイートを指定します。このパラメーターは、[RFC9528]のセクション10.2で定義されている「Edhoc Cipher Suites」レジストリの「値」列から取得される単一の値を指定する必要があります。このパラメーターは複数回発生する可能性があり、各発生は暗号スイートを指定します。
'ed-cred-t':
'ed-cred-t'：
Specifies a type of authentication credential supported by the server. This parameter MUST specify a single value, which is taken from the 'Value' column of the "EDHOC Authentication Credential Types" Registry defined in Section 8.3 of this document. This parameter MAY occur multiple times, with each occurrence specifying a type of authentication credential.
サーバーがサポートするタイプの認証資格情報を指定します。このパラメーターは、このドキュメントのセクション8.3で定義されている「EDHOC認証資格型タイプ」レジストリの「値」列から取得される単一の値を指定する必要があります。このパラメーターは複数回発生する可能性があり、各発生は認証資格情報のタイプを指定します。
'ed-idcred-t':
'ed-idcred-t'：
Specifies a type of identifier supported by the server for identifying authentication credentials. This parameter MUST specify a single value, which is taken from the 'Label' column of the "COSE Header Parameters" registry [COSE.Header.Parameters]. This parameter MAY occur multiple times, with each occurrence specifying a type of identifier for authentication credentials.
認証資格情報を識別するためにサーバーがサポートするタイプの識別子を指定します。このパラメーターは、「coseヘッダーパラメーター」レジストリ[cose.header.parameters]の「ラベル」列から取得される単一の値を指定する必要があります。このパラメーターは複数回発生する可能性があり、各発生は認証資格情報の識別子のタイプを指定します。
Note that the values in the 'Label' column of the "COSE Header Parameters" registry are strongly typed. On the contrary, CoRE Link Format is weakly typed; thus, it does not distinguish between, for instance, the string value "-10" and the integer value -10. Therefore, if responses in CoRE Link Format are returned, string values that look like an integer are not supported. Thus, such values MUST NOT be used in the 'ed-idcred-t' parameter.
「COSEヘッダーパラメーター」レジストリの「ラベル」列の値が強く入力されていることに注意してください。それどころか、コアリンク形式は弱く入力されます。したがって、たとえば、文字列値 "-10"と整数値-10を区別しません。したがって、コアリンク形式の応答が返される場合、整数のように見える文字列値はサポートされていません。したがって、そのような値は、「ed-idcred-t」パラメーターで使用してはなりません。
'ed-ead':
'ed-ead'：
Specifies the support of the server for an External Authorization Data (EAD) item (see Section 3.8 of [RFC9528]). This parameter MUST specify a single value, which is taken from the 'Label' column of the "EDHOC External Authorization Data" registry defined in Section 10.5 of [RFC9528]. This parameter MAY occur multiple times, with each occurrence specifying the ead_label of an EAD item that the server supports.
外部認証データ（EAD）アイテムに対してサーバーのサポートを指定します（[RFC9528]のセクション3.8を参照）。このパラメーターは、[RFC9528]のセクション10.5で定義されている「EDHOC外部認証データ」レジストリの「ラベル」列から取得される単一の値を指定する必要があります。このパラメーターは複数回発生する可能性があり、各発生はサーバーがサポートするEADアイテムのEAD_LABELを指定します。
'ed-comb-req':
'ed-comb-req'：
If present, specifies that the server supports the EDHOC + OSCORE request defined in Section 3. A value MUST NOT be given to this parameter and any present value MUST be ignored by the recipient.
存在する場合、サーバーはセクション3で定義されているEDHOC + OSCORE要求をサポートすることを指定します。このパラメーターに値を指定する必要はなく、現在の値は受信者が無視する必要があります。
Future documents may update the definition of the parameters 'ed-i', 'ed-r', and 'ed-comb-req' by expanding their semantics and specifying what they can take as value.
将来のドキュメントは、セマンティクスを拡大し、価値として取ることができるものを指定することにより、パラメーターのED-I '、「ED-R」、および「ED-Comb-Req」の定義を更新する場合があります。
The example in Figure 5 shows how a client discovers one EDHOC resource at a server and obtains information elements from the respective application profile. The CoRE Link Format notation from Section 5 of [RFC6690] is used.
図5の例は、クライアントがサーバーで1つのEDHOCリソースを発見し、それぞれのアプリケーションプロファイルから情報要素を取得する方法を示しています。[RFC6690]のセクション5からのコアリンク形式の表記が使用されます。
REQ: GET /.well-known/core
RES: 2.05 Content
</sensors/temp>;osc,
</sensors/light>;if=sensor,
</.well-known/edhoc>;rt=core.edhoc;ed-csuite=0;ed-csuite=2;
ed-method=0;ed-cred-t=0;ed-cred-t=1;ed-idcred-t=4;
ed-i;ed-r;ed-comb-req
Figure 5: The Web Link
図5：Webリンク
The same security considerations from OSCORE [RFC8613] and EDHOC [RFC9528] hold for this document. In addition, the following considerations apply.
OSCORE [RFC8613]とEDHOC [RFC9528]からの同じセキュリティ上の考慮事項は、このドキュメントについて保持されています。さらに、次の考慮事項が適用されます。
Section 3.2.1 specifies that a client SHOULD NOT have multiple outstanding EDHOC + OSCORE requests pertaining to the same EDHOC session. Even if a client did not fulfill this requirement, it would not have any impact in terms of security. That is, the server would still not process different instances of the same EDHOC message_3 more than once in the same EDHOC session (see Section 5.1 of [RFC9528]) and would still enforce replay protection of the OSCORE-protected request (see Sections 7.4 and 8.2 of [RFC8613]).
セクション3.2.1は、クライアントが同じEDHOCセッションに関連するEDHOC + OSCOREリクエストを複数持ってはならないことを指定します。クライアントがこの要件を満たしていなくても、セキュリティの点で影響はありません。つまり、サーバーは、同じEDHOCセッションで同じEDHOC Message_3の異なるインスタンスを1回以上処理せず（[RFC9528]のセクション5.1を参照）、オスコアで保護されたリクエストのリプレイ保護を強制します（セクション7.4およびセクション7.4およびを参照[RFC8613]の8.2）。
When using the optimized workflow in Figure 2, a minimum of 128-bit security against online brute-force attacks is achieved after the client receives and successfully verifies the first OSCORE-protected response (see Sections 9.1 and 9.4 of [RFC9528]). As an example, if EDHOC is used with method 3 (see Section 3.2 of [RFC9528]) and cipher suite 2 (see Section 3.6 of [RFC9528]), then the following holds:
図2で最適化されたワークフローを使用する場合、クライアントが最初のオスコアで保護された応答を受信し、正常に検証した後、オンラインブルートフォース攻撃に対する最低128ビットセキュリティが達成されます（[RFC9528]のセクション9.1および9.4を参照）。例として、EDHOCが方法3（[RFC9528]のセクション3.2を参照）および暗号スイート2（[RFC9528]のセクション3.6を参照）で使用している場合、次のとおりです。
* The Initiator is authenticated with 128-bit security against online attacks. As per Section 9.1 of [RFC9528], this results from the combination of the strength of the 64-bit Message Authentication Code (MAC) in EDHOC message_3 and of the 64-bit MAC in the Authenticated Encryption with Associated Data (AEAD) of the first OSCORE-protected CoAP request as rebuilt at Step 7 of Section 3.3.1.
* イニシエーターは、オンライン攻撃に対して128ビットのセキュリティで認証されます。[RFC9528]のセクション9.1によると、これは、EDHOC Message_3の64ビットメッセージ認証コード（MAC）と、関連するデータ（AEAD）の認証された暗号化の64ビットMACの強度（AEAD）の組み合わせの組み合わせに起因します。セクション3.3.1のステップ7で再構築された最初のオスコア保護COAPリクエスト。
* The Responder is authenticated with 128-bit security against online attacks. As per Section 9.1 of [RFC9528], this results from the combination of the strength of the 64-bit MAC in EDHOC message_2 and of the 64-bit MAC in the AEAD of the first OSCORE-protected CoAP response.
* レスポンダーは、オンライン攻撃に対して128ビットのセキュリティで認証されます。[RFC9528]のセクション9.1によると、これは、EDHOC Message_2の64ビットMACと、最初のOSCORE保護COAP応答のAEADの64ビットMACの強度の組み合わせに起因します。
With reference to the sequential workflow in Figure 1, the OSCORE request might have to undergo access-control checks at the server before being actually executed for accessing the target protected resource. The same MUST hold when the optimized workflow in Figure 2 is used, i.e., when using the EDHOC + OSCORE request.
図1のシーケンシャルワークフローを参照すると、OSCOREリクエストは、ターゲット保護されたリソースに実際に実行される前に、サーバーでアクセス制御チェックを受ける必要がある場合があります。図2の最適化されたワークフローが使用されている場合、つまりEDHOC + OSCOREリクエストを使用する場合も同じことが当てはまる必要があります。
That is, the rebuilt OSCORE-protected application request from Step 7 in Section 3.3.1 MUST undergo the same access-control checks that would be performed on a traditional OSCORE-protected application request sent individually as shown in Figure 1.
つまり、セクション3.3.1のステップ7からの再構築されたオスコア保護のアプリケーションリクエストは、図1に示すように個別に送信された従来のオスコア保護アプリケーションリクエストで実行される同じアクセス制御チェックを受ける必要があります。
To this end, validated information to perform access-control checks (e.g., an access token issued by a trusted party) has to be available at the server before starting to process the rebuilt OSCORE-protected application request. Such information may have been provided to the server separately before starting the EDHOC execution altogether, or instead as External Authorization Data during the EDHOC execution (see Section 3.8 of [RFC9528]).
この目的のために、アクセス制御チェックを実行するための検証済みの情報（たとえば、信頼できる当事者が発行したアクセストークンなど）は、再構築されたOSCORE保護されたアプリケーションリクエストの処理を開始する前にサーバーで利用できる必要があります。このような情報は、EDHOCの実行を完全に開始する前に、またはEDHOC実行中の外部認証データとして、または代わりにサーバーに個別に提供されている可能性があります（[RFC9528]のセクション3.8を参照）。
Thus, a successful completion of the EDHOC protocol and the following derivation of the OSCORE Security Context at the server do not play a role in determining whether the rebuilt OSCORE-protected request is authorized to access the target protected resource at the server.
したがって、EDHOCプロトコルの正常に完了し、サーバーでのOSCOREセキュリティコンテキストの次の派生は、再構築されたOSCORE保護リクエストがサーバーのターゲット保護リソースにアクセスすることが許可されているかどうかを判断する際に役割を果たしません。
This document has the following actions for IANA.
このドキュメントには、IANAの次のアクションがあります。
IANA has registered the following option number in the "CoAP Option Numbers" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.
IANAは、「制約付きRESTFUL環境（CORE）パラメーター」レジストリグループ内の「COAPオプション番号」レジストリに次のオプション番号を登録しています。
+========+=======+===========+
| Number | Name | Reference |
+========+=======+===========+
| 21 | EDHOC | RFC 9668 |
+--------+-------+-----------+
Table 2: Registration in the "CoAP Option Numbers" Registry
表2：「COAPオプション番号」レジストリの登録
IANA has registered the following entries in the "Target Attributes" registry [CORE.Target.Attributes] within the "Constrained RESTful Environments (CoRE) Parameters" registry group as per [RFC9423]. For all entries, the Change Controller is IETF and the reference is RFC 9668.
IANAは、[RFC9423]に従って、「制約されたRESTFUL環境（CORE）パラメーター」レジストリグループ内で、「ターゲット属性」レジストリ[core.target.attributes]に次のエントリを登録しています。すべてのエントリについて、変更コントローラーはIETFであり、参照はRFC 9668です。
+================+=============================================+
| Attribute Name | Brief Description |
+================+=============================================+
| ed-i | Hint: support for the EDHOC Initiator role |
+----------------+---------------------------------------------+
| ed-r | Hint: support for the EDHOC Responder role |
+----------------+---------------------------------------------+
| ed-method | A supported authentication method for EDHOC |
+----------------+---------------------------------------------+
| ed-csuite | A supported cipher suite for EDHOC |
+----------------+---------------------------------------------+
| ed-cred-t | A supported type of authentication |
| | credential for EDHOC |
+----------------+---------------------------------------------+
| ed-idcred-t | A supported type of authentication |
| | credential identifier for EDHOC |
+----------------+---------------------------------------------+
| ed-ead | A supported External Authorization Data |
| | (EAD) item for EDHOC |
+----------------+---------------------------------------------+
| ed-comb-req | Hint: support for the EDHOC + OSCORE |
| | request |
+----------------+---------------------------------------------+
Table 3: Registrations in the "Target Attributes" Registry
表3：「ターゲット属性」レジストリの登録
IANA has created the "EDHOC Authentication Credential Types" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in [RFC9528].
IANAは、[RFC9528]で定義されている「COSE（EDHOC）を超える（EDHOC）（EDHOC）（EDHOC））レジストリグループ内に「EDHOC認証資格情報タイプ」レジストリを作成しました。
The registration policy is either "Private Use", "Standards Action with Expert Review", or "Specification Required" per [RFC8126]. "Expert Review" guidelines are provided in Section 8.4.
登録ポリシーは、[RFC8126]ごとに「私的使用」、「専門家のレビューを伴う標準訴訟」、または「必要な仕様」のいずれかです。「専門家のレビュー」ガイドラインは、セクション8.4に記載されています。
All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per Section 4.9 of [RFC8126] with "Expert Review" additionally required per Section 4.5 of [RFC8126]. The procedure for early IANA allocation of "standards track code points" defined in [RFC7120] also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, working group chairs are encouraged to consult the expert(s) early during the process outlined in Section 3.1 of [RFC7120].
[Expert Reviewの標準訴訟]に従ってすべての割り当ては、[RFC8126]のセクション4.9に従って「標準アクション」ベースで行われ、[RFC8126]のセクション4.5に従って「エキスパートレビュー」が追加されます。[RFC7120]で定義されている「標準追跡コードポイント」の早期IANA割り当ての手順も適用されます。そのような手順が使用される場合、IANAは指定された専門家に登録前の早期配分を承認するように依頼します。さらに、ワーキンググループチェアは、[RFC7120]のセクション3.1で概説したプロセスの早い段階で専門家に相談することをお勧めします。
The columns of this registry are:
このレジストリの列は次のとおりです。
Value:
値：
This field contains the value used to identify the type of authentication credential. These values MUST be unique. The value can be an unsigned integer or a negative integer. Different ranges of values use different registration policies:
このフィールドには、認証資格情報のタイプを識別するために使用される値が含まれています。これらの値は一意でなければなりません。値は、署名されていない整数または負の整数である場合があります。さまざまな範囲の値は、異なる登録ポリシーを使用しています。
* Integer values from -24 to 23 are designated as "Standards Action With Expert Review".
* -24から23の整数値は、「専門家のレビューを伴う標準アクション」として指定されています。
* Integer values from -65536 to -25 and from 24 to 65535 are designated as "Specification Required".
* -65536から-25、24から65535までの整数値は、「仕様が必要」として指定されています。
* Integer values smaller than -65536 and greater than 65535 are marked as "Private Use".
* -65536を超え、65535を超える整数値は「私的使用」としてマークされています。
Description:
説明：
This field contains a short description of the type of authentication credential.
このフィールドには、認証資格情報のタイプの簡単な説明が含まれています。
Reference:
参照：
This field contains a pointer to the public specification for the type of authentication credential.
このフィールドには、認証資格情報のタイプのパブリック仕様へのポインターが含まれています。
+=======+============================================+===========+
| Value | Description | Reference |
+=======+============================================+===========+
| 0 | CBOR Web Token (CWT) containing a COSE_Key | [RFC8392] |
| | in a 'cnf' claim and possibly other | |
| | claims. CWT is defined in RFC 8392. | |
+-------+--------------------------------------------+-----------+
| 1 | CWT Claims Set (CCS) containing a COSE_Key | [RFC8392] |
| | in a 'cnf' claim and possibly other | |
| | claims. CCS is defined in RFC 8392. | |
+-------+--------------------------------------------+-----------+
| 2 | X.509 certificate | [RFC5280] |
+-------+--------------------------------------------+-----------+
Table 4: Initial Entries in the "EDHOC Authentication Credential Types" Registry
表4：「EDHOC認証資格情報」レジストリの初期エントリ
"Standards Action with Expert Review" and "Specification Required" are two of the registration policies defined for the IANA registry established in Section 8.3. This section gives some general guidelines for what the experts should be looking for; however, they are being designated as experts for a reason, so they should be given substantial latitude.
「専門家のレビューを伴う標準訴訟」と「仕様が必要」は、セクション8.3で確立されたIANAレジストリに対して定義された登録ポリシーの2つです。このセクションでは、専門家が探しているものについてのいくつかの一般的なガイドラインを示します。しかし、彼らは理由で専門家として指定されているため、かなりの緯度を与えられるべきです。
Expert reviewers should take into consideration the following points:
専門家のレビュアーは、次のポイントを考慮する必要があります。
* Clarity and correctness of registrations. Experts are expected to check the clarity of purpose and use of the requested entries. Experts need to make sure that registered identifiers indicate a type of authentication credential whose format and encoding is clearly defined in the corresponding specification. Identifiers of types of authentication credentials that do not meet these objectives of clarity and completeness must not be registered.
* 登録の明快さと正確性。専門家は、要求されたエントリの目的と使用の明確さを確認することが期待されています。専門家は、登録された識別子が、対応する仕様で形式とエンコーディングが明確に定義されている認証資格情報のタイプを示すことを確認する必要があります。明確さと完全性のこれらの目的を満たさない認証資格情報の種類の識別子は登録してはなりません。
* Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as "Private Use" are intended for testing purposes and closed environments. Code points in other ranges should not be assigned for testing.
* ポイントスクワットは落胆する必要があります。レビューアは、登録要求のための十分な情報を取得して、使用が既に登録されているものを複製しないようにし、ポイントが展開で使用される可能性が高いことを確認することをお勧めします。「プライベート使用」としてタグ付けされたゾーンは、テスト目的と閉鎖環境を目的としています。他の範囲のコードポイントは、テスト用に割り当てられないでください。
* Specifications are required for the "Standards Action With Expert Review" range of point assignment. Specifications should exist for "Specification Required" ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.
* 仕様は、「エキスパートレビューによる標準アクション」のポイント割り当て範囲に必要です。「必要な仕様」範囲の仕様は存在する必要がありますが、仕様が利用可能である前の早期割り当ては許容されると見なされます。仕様が提供されていない場合、提供された説明には、ポイントが使用されているものを識別するのに十分な情報が必要です。
* Experts should take into account the expected usage of fields when approving point assignment. Documents published via Standards Action can also register points outside the Standards Action range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.
* 専門家は、ポイント割り当てを承認する際に、フィールドの予想される使用を考慮する必要があります。標準アクションを介して公開されたドキュメントは、標準アクション範囲外のポイントを登録することもできます。エンコードされた値の長さは、その長さのコードポイントの数、使用されるデバイスのサイズ、およびそのサイズにエンコードするコードポイントの数と比較して計量する必要があります。
[CORE.Target.Attributes]
IANA, "Target Attributes",
<https://www.iana.org/assignments/core-parameters>.
[COSE.Header.Parameters]
IANA, "COSE Header Parameters",
<https://www.iana.org/assignments/cose>.
[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>.
[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>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>.
[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>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>.
[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>.
[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>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[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>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
[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>.
[RFC9176] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
P. van der Stok, "Constrained RESTful Environments (CoRE)
Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
2022, <https://www.rfc-editor.org/info/rfc9176>.
[RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
DOI 10.17487/RFC9528, March 2024,
<https://www.rfc-editor.org/info/rfc9528>.
[RFC9423] Bormann, C., "Constrained RESTful Environments (CoRE)
Target Attributes Registry", RFC 9423,
DOI 10.17487/RFC9423, April 2024,
<https://www.rfc-editor.org/info/rfc9423>.
The authors sincerely thank Christian Amsüss, Emmanuel Baccelli, Carsten Bormann, Roman Danyliw, Esko Dijk, Joel Halpern, Wes Hardaker, Klaus Hartke, John Preuß Mattsson, David Navarro, Shuping Peng, Jim Schaad, Jürgen Schönwälder, John Scudder, Orie Steele, Gunter Van de Velde, Mališa Vučinić, and Paul Wouters for their feedback and comments.
著者は、クリスチャン・アムズ、エマニュエル・バッケリ、カルステン・ボルマン、ローマン・ダニリウ、エスコ・ディック、ジョエル・ハルパーン、ウェス・ハーダカー、クラウス・ハートケ、ジョン・プレエ・マッツソン、デビッド・ナバロ、シュピング・ペン、ジム・シャード、ジュルゲン・シェンワルダー、ジョン・スイース、ガンター・ヴァン・デ・ヴェルデ、マリシャ・ヴィチニッチ、ポール・ウーターズのフィードバックとコメント。
The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next project CRITISEC, and by the H2020 project SIFIS-Home (Grant agreement 952652).
この文書の作業は、スウェーデンのイノベーションエージェンシーVinnovaとCeltic-Next Project Critisec、およびH2020 Project Sifis-Home（Grant Agreement 952652）によって部分的にサポートされています。
Francesca Palombini
Ericsson AB
Torshamnsgatan 23
SE-164 40 Kista
Sweden
Email: francesca.palombini@ericsson.com
Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-164 40 Kista
Sweden
Email: marco.tiloca@ri.se
Rikard Höglund
RISE AB
Isafjordsgatan 22
SE-164 40 Kista
Sweden
Email: rikard.hoglund@ri.se
Stefan Hristozov
Eriptic
Email: stefan.hristozov@eriptic.com
Göran Selander
Ericsson
Email: goran.selander@ericsson.com