Internet Engineering Task Force (IETF) F. Palombini
Request for Comments: 9594 Ericsson AB
Category: Standards Track M. Tiloca
ISSN: 2070-1721 RISE AB
September 2024
This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication. Candidate group members that act as Clients and are authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as the Resource Server, from which they obtain the keying material to communicate with other group members. While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication. Therefore, details are delegated to separate application profiles of this document as specialized instances that target a particular group communication approach and define how communications in the group are protected. Compliance requirements for such application profiles are also specified.
このドキュメントでは、安全なグループ通信のためにキーイング材料と構成パラメーターを配布するために、制約された環境（ACE）フレームワークに認証と承認を使用する方法を定義します。クライアントとして行動し、グループに参加する権限を与えられた候補グループメンバーは、リソースサーバーとして機能するキー配布センター（KDC）と対話することでそうすることができます。一般的なメッセージ形式とKDCで利用可能なインターフェイスと操作を定義しながら、このドキュメントは、安全なグループ通信のためのさまざまなアプローチとプロトコルをサポートしています。したがって、詳細は、特定のグループコミュニケーションアプローチをターゲットにし、グループ内のコミュニケーションの保護方法を定義する専門的なインスタンスとして、このドキュメントのアプリケーションプロファイルを分離するように委任されます。このようなアプリケーションプロファイルのコンプライアンス要件も指定されています。
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/rfc9594.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9594で取得できます。
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. Overview
3. Authorization to Join a Group
3.1. Authorization Request
3.2. Authorization Response
3.3. Token Transferring
3.3.1. 'sign_info' Parameter
3.3.2. 'kdcchallenge' Parameter
4. KDC Functionalities
4.1. Interface at the KDC
4.1.1. Operations Supported by Clients
4.1.2. Error Handling
4.2. /ace-group
4.2.1. FETCH Handler
4.2.1.1. Retrieve Group Names
4.3. /ace-group/GROUPNAME
4.3.1. POST Handler
4.3.1.1. Join the Group
4.3.2. GET Handler
4.3.2.1. Retrieve Group Keying Material
4.4. /ace-group/GROUPNAME/creds
4.4.1. FETCH Handler
4.4.1.1. Retrieve a Subset of Authentication Credentials in
the Group
4.4.2. GET Handler
4.4.2.1. Retrieve All Authentication Credentials in the
Group
4.5. /ace-group/GROUPNAME/kdc-cred
4.5.1. GET Handler
4.5.1.1. Retrieve the KDC's Authentication Credential
4.6. /ace-group/GROUPNAME/policies
4.6.1. GET Handler
4.6.1.1. Retrieve the Group Policies
4.7. /ace-group/GROUPNAME/num
4.7.1. GET Handler
4.7.1.1. Retrieve the Keying Material Version
4.8. /ace-group/GROUPNAME/nodes/NODENAME
4.8.1. GET Handler
4.8.1.1. Retrieve Group and Individual Keying Material
4.8.2. POST Handler
4.8.2.1. Request to Change Individual Keying Material
4.8.3. DELETE Handler
4.8.3.1. Leave the Group
4.9. /ace-group/GROUPNAME/nodes/NODENAME/cred
4.9.1. POST Handler
4.9.1.1. Uploading an Authentication Credential
5. Removal of a Group Member
6. Group Rekeying Process
6.1. Point-to-Point Group Rekeying
6.2. One-to-Many Group Rekeying
6.2.1. Protection of Rekeying Messages
6.3. Misalignment of Group Keying Material
7. Extended Scope Format
8. ACE Groupcomm Parameters
9. ACE Groupcomm Error Identifiers
10. Security Considerations
10.1. Secure Communication in the Group
10.2. Update of Group Keying Material
10.3. Block-Wise Considerations
11. IANA Considerations
11.1. Media Type Registrations
11.2. CoAP Content-Formats
11.3. OAuth Parameters
11.4. OAuth Parameters CBOR Mappings
11.5. Interface Description (if=) Link Target Attribute Values
11.6. Custom Problem Detail Keys Registry
11.7. ACE Groupcomm Parameters
11.8. ACE Groupcomm Key Types
11.9. ACE Groupcomm Profiles
11.10. ACE Groupcomm Policies
11.11. Sequence Number Synchronization Methods
11.12. ACE Groupcomm Errors
11.13. ACE Groupcomm Rekeying Schemes
11.14. Expert Review Instructions
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Requirements for Application Profiles
A.1. Mandatory-to-Address Requirements
A.2. Optional-to-Address Requirements
Appendix B. Extensibility for Future COSE Algorithms
B.1. Format of 'sign_info_entry'
Acknowledgments
Authors' Addresses
This document builds on the Authentication and Authorization for Constrained Environments (ACE) framework and defines how to request, distribute, and renew keying material and configuration parameters to protect message exchanges in a group communication environment.
このドキュメントは、制約された環境（ACE）フレームワークの認証と承認に基づいて構築され、グループ通信環境でメッセージ交換を保護するために、キーイング素材と構成パラメーターを要求、配布、および更新する方法を定義します。
Candidate group members that act as ACE Clients and are authorized to join a group can interact with the Key Distribution Center (KDC) acting as the ACE Resource Server that is responsible for that group in order to obtain the necessary keying material and parameters to communicate with other group members.
ACEクライアントとして機能し、グループに参加することを許可された候補グループメンバーは、必要なキーイング材料と通信パラメーターを取得するために、そのグループを担当するACEリソースサーバーとして機能するキー配布センター（KDC）と対話できます。他のグループメンバー。
In particular, this document defines the operations and interface available at the KDC, as well as general message formats for the interactions between Clients and the KDC. At the same time, communications in the group can rely on different approaches, e.g., based on multicast [GROUP-CoAP] or publish-subscribe (pub-sub) messaging [CoAP-PUBSUB], and can be protected in different ways.
特に、このドキュメントでは、KDCで利用可能な操作とインターフェイス、ならびにクライアントとKDC間の相互作用のための一般的なメッセージ形式を定義しています。同時に、グループ内の通信は、たとえば、マルチキャスト[グループコープ]またはパブリッシュサブスクライブ（Pub-Sub）メッセージング[Coap-PubSub]に基づいて、さまざまなアプローチに依存し、さまざまな方法で保護できます。
Therefore, this document delegates details on the communication and security approaches used in a group to separate application profiles. These are specialized instances of this document that target a particular group communication approach and define how communications in the group are protected, as well as the specific keying material and configuration parameters provided to group members.
したがって、このドキュメントは、グループで使用される通信およびセキュリティアプローチに関する詳細を委任し、アプリケーションプロファイルを分離します。これらは、特定のグループコミュニケーションアプローチをターゲットにし、グループ内の通信がどのように保護されるかを定義するこのドキュメントの特殊なインスタンスと、グループメンバーに提供される特定のキーイング材料と構成パラメーターを定義します。
In order to ensure consistency and aid the development of such application profiles, Appendix A of this document defines a number of related compliance requirements. In particular, Appendix A.1 compiles the requirements that application profiles are REQUIRED to fulfill; these are referred to by an identifier that starts with "REQ". Instead, Appendix A.2 compiles the requirements that application profiles MAY fulfill; these are referred to by an identifier that starts with "OPT".
一貫性を確保し、そのようなアプリケーションプロファイルの開発を支援するために、このドキュメントの付録Aは、多くの関連するコンプライアンス要件を定義しています。特に、付録A.1は、アプリケーションプロファイルが満たすために必要な要件をまとめます。これらは、「req」で始まる識別子によって参照されます。代わりに、付録A.2は、アプリケーションプロファイルが満たす可能性のある要件をまとめます。これらは、「OPT」から始まる識別子によって参照されます。
New keying material is intended to be generated and distributed to the group upon membership changes (rekeying). If the application requires backward security (i.e., new group members must be prevented from accessing communications in the group prior to their joining), then a rekeying has to occur every time new members join the group. If the application requires forward security (i.e., former group members must be prevented from accessing communications in the group after their leaving), then a rekeying has to occur every time current members leave or are evicted from the group.
新しいキーイング材料は、メンバーシップの変更時に生成され、グループに配布することを目的としています（再キーイング）。アプリケーションが後方セキュリティを必要とする場合（つまり、新しいグループメンバーが参加する前にグループ内の通信にアクセスすることを妨げる必要があります）、新しいメンバーがグループに参加するたびに再キーイングが発生する必要があります。アプリケーションが前方のセキュリティを必要とする場合（つまり、元グループメンバーが去った後、グループ内の通信にアクセスすることを妨げられなければなりません）、現在のメンバーが出発するか、グループから追い出されるたびに再キーイングが発生する必要があります。
A group rekeying scheme performs the actual distribution of the new keying material by rekeying the current group members when a new Client joins the group and rekeying the remaining group members when a Client leaves the group. This can rely on different approaches, including efficient group rekeying schemes such as those described in [RFC2093], [RFC2094], and [RFC2627].
グループの再キーイングスキームは、新しいクライアントがグループに参加したときに現在のグループメンバーを再キーし、クライアントがグループを去るときに残りのグループメンバーを再キーすることにより、新しいキーイング資料の実際の配布を実行します。これは、[RFC2093]、[RFC2094]、[RFC2627]に記載されているものなどの効率的なグループを再ケイするスキームを含む、さまざまなアプローチに依存する可能性があります。
Consistently with what is recommended in the ACE framework, this document uses Concise Binary Object Representation (CBOR) [RFC8949] for data encoding. However, using JSON [RFC8259] instead of CBOR is possible by relying on the conversion method specified in Sections 6.1 and 6.2 of [RFC8949].
ACEフレームワークで推奨されるものと一貫して、このドキュメントは、データエンコーディングに簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]を使用しています。ただし、[RFC8949]のセクション6.1および6.2で指定されている変換方法に依存することにより、CBORの代わりにJSON [RFC8259]を使用することが可能です。
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」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Readers are expected to be familiar with the following:
読者は以下に精通していることが期待されています。
* The terms and concepts described in the ACE framework [RFC9200] and in the Authorization Information Format (AIF) [RFC9237] to express authorization information. The terminology for entities in the considered architecture is defined in OAuth 2.0 [RFC6749]. In particular, this includes Client (C), Resource Server (RS), and Authorization Server (AS).
* ACEフレームワーク[RFC9200]および認証情報形式（AIF）[RFC9237]で説明されている用語と概念は、認証情報を表現します。考慮されたアーキテクチャのエンティティの用語は、OAUTH 2.0 [RFC6749]で定義されています。特に、これにはクライアント（c）、リソースサーバー（RS）、および認証サーバー（AS）が含まれます。
* The terms and concepts described in the Constrained Application Protocol (CoAP) [RFC7252]. The term "endpoint" is used here following its OAuth definition, aimed at denoting resources such as /token and /introspect at the AS and /authz-info at the RS. This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol".
* 制約付きアプリケーションプロトコル（COAP）[RFC7252]で説明されている用語と概念。「エンドポイント」という用語は、ASなどの /トークンなどのリソースとRSのAuthz-infoなどのリソースを示すことを目的としたOAuth定義に従って使用されます。このドキュメントでは、「エンドポイント」のCOAP定義は「COAPプロトコルに参加しているエンティティ」ではありません。
* The terms and concepts described in Concise Data Definition Language (CDDL) [RFC8610], CBOR [RFC8949], and CBOR Object Signing and Encryption (COSE) [RFC9052] [RFC9053] [RFC9338].
* 簡潔なデータ定義言語（CDDL）[RFC8610]、CBOR [RFC8949]、およびCBORオブジェクトの署名と暗号化（COSE）[RFC9052] [RFC9053] [RFC9338]で説明されている用語と概念。
A node interested in participating in group communication, as well as one that is already participating as a group member, is interchangeably denoted as "Client".
グループコミュニケーションへの参加に関心のあるノードと、グループメンバーとしてすでに参加しているノードは、「クライアント」として互換性があると考えられます。
This document also uses the following terms.
このドキュメントでは、次の用語も使用します。
Group:
グループ：
A set of nodes that share common keying material and security parameters used to protect their communications with one another. That is, the term refers to a "security group".
コミュニケーションを互いに保護するために使用される一般的なキーイング素材とセキュリティパラメーターを共有する一連のノード。つまり、この用語は「セキュリティグループ」を指します。
This term is not to be confused with an "application group", which has relevance at the application level and whose members share a common pool of resources or content. Examples of application groups are the set of all nodes deployed in a same physical room or the set of nodes registered to a pub-sub topic.
この用語は、アプリケーションレベルで関連性があり、そのメンバーがリソースまたはコンテンツの共通プールを共有する「アプリケーショングループ」と混同されるべきではありません。アプリケーショングループの例は、同じ物理ルームに展開されているすべてのノードのセットまたはPUB-SUBトピックに登録されているノードのセットです。
This term is also not to be confused with a "multicast group", which has relevance at the network level and whose members all listen to a group network address for receiving messages sent to that group. An example of a multicast group is the set of nodes that are configured to receive messages that are sent to the group's associated IP multicast address.
また、この用語は、ネットワークレベルで関連性があり、メンバー全員がそのグループに送信されたメッセージを受信するためのグループネットワークアドレスを聴く「マルチキャストグループ」と混同されることもありません。マルチキャストグループの例は、グループに関連するIPマルチキャストアドレスに送信されるメッセージを受信するように構成されたノードのセットです。
The same security group might be associated with multiple application groups. Also, the same application group might be associated with multiple security groups. Further details and considerations on the mapping between the three types of groups are out of the scope of this document.
同じセキュリティグループが複数のアプリケーショングループに関連付けられている可能性があります。また、同じアプリケーショングループが複数のセキュリティグループに関連付けられている可能性があります。3つのタイプのグループ間のマッピングに関する詳細と考慮事項は、このドキュメントの範囲外です。
Key Distribution Center (KDC):
キーディストリビューションセンター（KDC）：
The entity responsible for managing one or multiple groups, with particular reference to the group membership and the keying material to use for protecting group communications.
グループメンバーシップとグループコミュニケーションの保護に使用するキーイング資料を特に参照して、1つまたは複数のグループの管理を担当するエンティティ。
Furthermore, this document uses "names" or "identifiers" for groups and nodes. Their different meanings are summarized below.
さらに、このドキュメントでは、グループとノードに「名前」または「識別子」を使用します。それらのさまざまな意味を以下に要約します。
Group name:
グループ名：
The identifier of a group as a text string encoded as UTF-8 [RFC3629]. Once established, it is invariant. It is used in the interactions between the Client, AS, and RS to identify a group. A group name is always unique among the group names of the existing groups under the same KDC.
UTF-8 [RFC3629]としてエンコードされたテキスト文字列としてのグループの識別子。一度確立されると、不変になります。グループを識別するために、クライアントとRS間の相互作用に使用されます。グループ名は、同じKDCの下の既存のグループのグループ名の間で常にユニークです。
GROUPNAME:
GroupName：
The text string used in URIs to identify a group. Once established, it is invariant. GROUPNAME uniquely maps to the group name of a group, although they do not necessarily coincide.
Groupを識別するためにURIで使用されるテキスト文字列。一度確立されると、不変になります。GroupNameは、グループのグループ名にユニークにマップしますが、必ずしも一致するわけではありません。
Group identifier:
グループ識別子：
The identifier of the group keying material used in a group. Unlike group name and GROUPNAME, this identifier changes over time when the group keying material is updated.
グループで使用されるグループキーイングマテリアルの識別子。グループ名やグループ名とは異なり、この識別子は、グループキーイング素材が更新されると時間とともに変化します。
Node name:
ノード名：
The identifier of a node as a text string encoded as UTF-8 [RFC3629] and consistent with the semantics of URI path segments (see Section 3.3 of [RFC3986]). Once established, it is invariant. It is used in the interactions between the Client and RS, as well as to identify a member of a group. A node name is always unique among the node names of the current nodes within a group.
Nodeの識別子は、UTF-8 [RFC3629]としてエンコードされ、URIパスセグメントのセマンティクスと一致しています（[RFC3986]のセクション3.3を参照）。一度確立されると、不変になります。これは、クライアントとRS間の相互作用に使用され、グループのメンバーを識別するために使用されます。ノード名は、グループ内の現在のノードのノード名の間で常に一意です。
NODENAME:
nodename：
The text string used in URIs to identify a member of a group. Once established, it is invariant. Its value coincides with the node name of the associated group member.
Groupのメンバーを識別するためにURIで使用されるテキスト文字列。一度確立されると、不変になります。その値は、関連するグループメンバーのノード名と一致します。
This document additionally uses the following terminology:
このドキュメントはさらに、次の用語を使用しています。
Transport profile:
トランスポートプロファイル：
A profile of the ACE framework as per Section 5.8.4.3 of [RFC9200]. A transport profile specifies the communication protocol and communication security protocol between an ACE Client and Resource Server, as well as proof-of-possession methods if it supports proof-of-possession access tokens. Transport profiles of ACE include, for instance, those described in [RFC9202], [RFC9203], and [RFC9431].
[RFC9200]のセクション5.8.4.3に従って、ACEフレームワークのプロファイル。トランスポートプロファイルは、ACEクライアントとリソースサーバー間の通信プロトコルと通信セキュリティプロトコルと、プルーフオブポッセッションアクセストークンをサポートする場合のプルーフオブポッセッション方法を指定します。ACEの輸送プロファイルには、たとえば、[RFC9202]、[RFC9203]、および[RFC9431]に記載されているものが含まれます。
Application profile:
アプリケーションプロファイル：
A profile that defines how applications enforce and use supporting security services they require. These services may include, for instance, provisioning, revocation, and distribution of keying material. An application profile may define specific procedures and message formats.
アプリケーションが必要なサポートセキュリティサービスを実施および使用する方法を定義するプロファイル。これらのサービスには、たとえば、キーイング材料のプロビジョニング、取り消し、配布が含まれる場合があります。アプリケーションプロファイルは、特定の手順とメッセージ形式を定義できます。
Authentication credential:
認証資格情報：
The set of information associated with an entity, including that entity's public key and parameters associated with the public key. Examples of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) [RFC8392], X.509 certificates [RFC5280], and C509 certificates [C509-CERT].
エンティティの公開鍵や公開鍵に関連付けられたパラメーターを含む、エンティティに関連する情報のセット。認証資格情報の例は、CBOR Webトークン（CWTS）およびCWTクレームセット（CCSS）[RFC8392]、X.509証明書[RFC5280]、およびC509証明書[C509-CERT]です。
Individual keying material:
個々のキーイング素材：
Information pertaining exclusively to a group member, as associated with its group membership and related to other keying material and parameters used in the group. For example, this can be an identifier that the secure communication protocol employs to uniquely identify a node as a group member (e.g., a cryptographic key identifier uniquely associated with the group member in question). The specific nature and format of individual keying material used in a group is defined in the application profiles of this specification. The individual keying material of a group member is not related to the secure association between that group member and the KDC.
グループメンバーシップに関連付けられ、グループで使用されている他のキーイング素材とパラメーターに関連するグループメンバーのみに関連する情報。たとえば、これは、安全な通信プロトコルがグループメンバーとしてノードを一意に識別するために採用する識別子です（例えば、問題のグループメンバーに一意に関連する暗号化キー識別子）。グループで使用される個々のキーイング素材の特定の性質と形式は、この仕様のアプリケーションプロファイルで定義されています。グループメンバーの個々のキーイング資料は、そのグループメンバーとKDCの間の安全な関連性とは関係ありません。
Throughout this document, examples for CBOR data items are expressed in CBOR extended diagnostic notation as defined in Section 8 of [RFC8949] and Appendix G of [RFC8610] ("diagnostic notation"), unless noted otherwise. We often use diagnostic notation comments to provide a textual representation of the parameters' keys and values.
このドキュメント全体で、CBORデータ項目の例は、[RFC8949]のセクション8および[RFC8610]の付録G（「診断表記」）の付録Gで定義されているように、CBOR拡張診断表記で表されます。診断表記コメントを使用して、パラメーターのキーと値のテキスト表現を提供することがよくあります。
At a high level, the key provisioning process is separated in two phases: the first one follows the ACE framework between the Client, AS, and KDC, while the second one is the actual key distribution between the Client and KDC. After the two phases are completed, the Client is able to participate in the group communication via a Dispatcher entity.
高レベルでは、主要なプロビジョニングプロセスは2つのフェーズで分離されます。最初のフェーズは、クライアントとKDCの間のACEフレームワークに従いますが、2番目のプロセスはクライアントとKDCの間の実際の重要な分布です。2つのフェーズが完了した後、クライアントはディスパッチャーエンティティを介してグループコミュニケーションに参加できます。
.------------. .------------.
| AS | .----->| KDC |
'------------' | '------------'
^ |
| |
v |
.------------. | .-----------.
| Client |<-------' .------------. | .---------+-.
| |<------------->| Dispatcher |<----->| | .---------+-.
'------------' '------------' '-+ | Group |
'-+ members |
'-----------'
Figure 1: Key Distribution Participants
図1：キーディストリビューション参加者
The following participants (see Figure 1) take part in the authorization and key distribution.
次の参加者（図1を参照）は、承認と重要な分布に参加します。
* Client (C): A node that wants to join a group and take part in group communication with other group members. Within the group, the Client can have different roles.
* クライアント（c）：グループに参加し、他のグループメンバーとのグループコミュニケーションに参加したいノード。グループ内では、クライアントは異なる役割を持つことができます。
* Authorization Server (AS): As per the AS defined in the ACE framework [RFC9200], it enforces access policies that prescribe whether a node is allowed to join a given group or not and with what roles and rights (e.g., write and/or read).
* Authorization Server（AS）：ACE Framework [RFC9200]で定義されているように、ノードが特定のグループに参加できるかどうかを規定するアクセスポリシーを実施します。読む）。
* Key Distribution Center (KDC): An entity that maintains the keying material to protect group communications and provides it to Clients authorized to join a given group. During the first phase of the process (Section 3), the KDC takes the role of the RS in the ACE framework. During the second phase of the process (Section 4), which is not based on the ACE framework, the KDC distributes the keying material. In addition, the KDC provides the latest keying material to group members when requested or, if required by the application, when group membership changes.
* Key Distribution Center（KDC）：グループコミュニケーションを保護するためのキーイング資料を維持し、特定のグループに参加することを許可されたクライアントに提供するエンティティ。プロセスの第1フェーズ（セクション3）で、KDCはACEフレームワークでRSの役割を担います。ACEフレームワークに基づいていないプロセスの第2フェーズ（セクション4）では、KDCはキーイング材料を分配します。さらに、KDCは、要求されたとき、またはアプリケーションで要求された場合、グループメンバーシップが変更されたときにグループメンバーに最新のキーイン素材を提供します。
* Group members: Nodes that have joined a group where they take part in group communication with one another, protecting it with the group keying material obtained from the KDC.
* グループメンバー：グループコミュニケーションに参加し、KDCから得られたグループキーイング素材でそれを保護するグループに参加したノード。
* Dispatcher: An entity through which the Clients communicate with the group when sending a message intended for multiple group members. That is, the Dispatcher distributes such a one-to-many message to the group members as intended recipients. The Dispatcher does not have access to the group keying material. A single-recipient message intended for only one group member may be delivered by alternative means, i.e., with no assistance from the Dispatcher.
* ディスパッチャー：複数のグループメンバー向けのメッセージを送信するときに、クライアントがグループと通信するエンティティ。つまり、ディスパッチャーは、意図した受信者としてグループメンバーにこのような1対多様なメッセージを配布します。ディスパッチャーは、グループキーイングマテリアルにアクセスできません。1人のグループメンバーのみを対象とした単一の相性メッセージは、代替手段、つまりディスパッチャーからの支援なしで配信できます。
Examples of a Dispatcher are: the Broker in a pub-sub setting; a relayer for group communication that delivers group messages as multiple unicast messages to all group members; and an implicit entity as in a multicast communication setting, where messages are transmitted to a multicast IP address and delivered on the transport channel.
ディスパッチャーの例は次のとおりです。パブサブ設定のブローカー。すべてのグループメンバーに複数のユニキャストメッセージとしてグループメッセージを配信するグループコミュニケーション用の中継。そして、メッセージがマルチキャストIPアドレスに送信され、輸送チャネルで配信されるマルチキャスト通信設定のような暗黙のエンティティ。
If it consists of an explicit entity, such as a pub-sub Broker or a message relayer, the Dispatcher is comparable to an untrusted on-path intermediary; as such, it is able to see the messages sent by Clients in the group but not able to decrypt them and read their plain content.
Pub-Subブローカーやメッセージの中継などの明示的なエンティティで構成されている場合、ディスパッチャーは信頼できないパス中の仲介者に匹敵します。そのため、グループ内のクライアントから送信されたメッセージを表示できますが、それらを復号化してプレーンコンテンツを読むことはできません。
This document specifies a mechanism for:
このドキュメントは、次のメカニズムを指定します。
* Authorizing a Client to join the group (Section 3) and providing it with the group keying material to communicate with the other group members (Section 4),
* クライアントがグループに参加することを許可し（セクション3）、他のグループメンバーと通信するためのグループキーイング資料（セクション4）を提供することを許可します。
* Allowing a group member to retrieve group keying material (Sections 4.3.2.1 and 4.8.1.1),
* グループメンバーがグループキーイングマテリアルを取得できるようにする（セクション4.3.2.1および4.8.1.1）、
* Allowing a group member to retrieve authentication credentials of other group members (Section 4.4.1.1) and to provide an updated authentication credential (Section 4.9.1.1),
* グループメンバーが他のグループメンバーの認証資格情報を取得できるようにし（セクション4.4.1.1）、更新された認証資格情報（セクション4.9.1.1）を提供することを許可します。
* Allowing a group member to leave the group (Section 4.8.3.1),
* グループメンバーがグループを離れることを許可します（セクション4.8.3.1）、
* Evicting a group member from the group (Section 5), and
* グループからグループメンバーを追い出し（セクション5）、
* Renewing and redistributing the group keying material (rekeying), e.g., upon a membership change in the group (Section 6).
* たとえば、グループのメンバーシップの変更（セクション6）に基づいて、グループキーイングマテリアル（再キーイング）を更新および再配布します。
Rekeying the group may result in a temporary misalignment of the keying material stored by the different group members. Different situations where this can happen and how they can be handled are discussed in Section 6.3.
グループを再キーすると、さまざまなグループメンバーによって保存されたキーイング素材の一時的な不整合が発生する可能性があります。これが起こる可能性があり、それらをどのように処理できるかは、セクション6.3で説明されています。
Figure 2 provides a high-level overview of the message flow for a node joining a group. The message flow can be expanded as follows.
図2は、グループに参加するノードのメッセージフローの高レベルの概要を示しています。メッセージフローは次のように拡張できます。
1. The joining node requests an access token from the AS in order to access one or more group-membership resources at the KDC and hence join the associated groups.
1. 結合ノードは、KDCで1つ以上のグループメンバーシップリソースにアクセスし、関連するグループに参加するために、ASからアクセストークンを要求します。
This exchange between the Client and AS MUST be secured, as specified by the transport profile of ACE used between the Client and KDC. Based on the response from the AS, the joining node will establish or continue using a secure communication association with the KDC.
クライアントとKDCの間で使用されるACEの輸送プロファイルによって指定されているように、クライアントとASの間のこの交換は保護する必要があります。ASからの応答に基づいて、結合ノードはKDCとの安全な通信関連を確立または継続します。
2. The joining node transfers authentication and authorization information to the KDC by transferring the obtained access token. This is typically achieved by including the access token in a request sent to the /authz-info endpoint at the KDC.
2. 結合ノードは、取得したアクセストークンを転送することにより、認証と認証情報をKDCに転送します。これは通常、KDCの /authz-infoエンドポイントに送信されたリクエストにアクセストークンを含めることによって達成されます。
Once this exchange is completed, the joining node MUST have a secure communication association established with the KDC before joining a group under that KDC.
この交換が完了すると、結合ノードには、そのKDCの下でグループに参加する前に、KDCとの安全な通信協会が確立されている必要があります。
This exchange and the following secure communications between the Client and the KDC MUST occur in accordance with the transport profile of ACE used between the Client and KDC, such as the DTLS transport profile of ACE [RFC9202] or the OSCORE transport profile of ACE [RFC9203].
この交換とクライアントとKDCの間の次の安全な通信は、ACE [RFC9202]のDTLS輸送プロファイルやACE [RFC9203]のオスコア輸送プロファイルなど、クライアントとKDCの間で使用されるACEの輸送プロファイルに従って発生する必要があります。]。
3. The joining node starts the joining process to become a member of the group by sending a request to the related group-membership resource at the KDC. Based on the application requirements and policies, the KDC may perform a group rekeying by generating new group keying material and distributing it to the current group members through the rekeying scheme used in the group.
3. 結合ノードは、KDCの関連グループメンバーシップリソースにリクエストを送信することにより、グループのメンバーになるための参加プロセスを開始します。アプリケーションの要件とポリシーに基づいて、KDCは、グループで使用されている再キーイングスキームを通じて、新しいグループキーイングマテリアルを生成し、現在のグループメンバーに配布することにより、再キーイングを実行することができます。
At the end of the joining process, the joining node has received the parameters and group keying material from the KDC to securely communicate with the other group members. Also, the KDC has stored the association between the authorization information from the access token and the secure communication association with the joining node.
結合プロセスの最後に、参加ノードはKDCからパラメーターとグループキーイング素材を受信して、他のグループメンバーと安全に通信します。また、KDCは、アクセストークンからの承認情報と、結合ノードとの安全な通信協会との間の関連性を保存しています。
4. The joining node and the KDC maintain the secure communication association to support possible future communications. These especially include key management operations, such as the retrieval of updated keying material or the participation in a group rekeying process.
4. 結合ノードとKDCは、将来のコミュニケーションの可能性をサポートするために、安全な通信協会を維持します。これらには、特に、更新されたキーイング素材の検索やグループの再キーイングプロセスへの参加など、主要な管理操作が含まれます。
5. The joining node can communicate securely with the other group members by using the keying material obtained in step 3.
5. 結合ノードは、ステップ3で得られたキーイング材料を使用して、他のグループメンバーと安全に通信できます。
C AS KDC Group
| | | Members
/ | | | |
| |--- Authorization Request -->| | |
| | | | |
| |<-- Authorization Response --| | |
(*) < | | | |
| | | | |
| |--- Token Transfer Request ---->| |
| | | |
| |<--- Token Transfer Response-----| |
\ | | | |
| | | |
|--------- Join Request --------->| |
| | | |
| | | -- Group rekeying -->|
| | | (optional) |
|<-------- Join Response ---------| |
| | | |
| | | |
| | | Dispatcher |
| | |
|<======= Secure group communication =========|=========>|
| | |
(*) Defined in the ACE framework
Figure 2: Message Flow upon a New Node's Joining
図2：新しいノードの結合に対するメッセージフロー
This section describes in detail the format of messages exchanged by the participants when a node requests access to a given group. This exchange is based on ACE [RFC9200].
このセクションでは、ノードが特定のグループへのアクセスを要求したときに参加者が交換するメッセージの形式について詳しく説明します。この交換は、ACE [RFC9200]に基づいています。
As defined in [RFC9200], the Client asks the AS for the authorization to join the group through the KDC (see Section 3.1). If the request is approved and authorization is granted, the AS provides the Client with a proof-of-possession access token and parameters to securely communicate with the KDC (see Section 3.2).
[RFC9200]で定義されているように、クライアントは、ASにKDCを介してグループに参加する許可を求めます（セクション3.1を参照）。リクエストが承認され、許可が付与された場合、ASはクライアントに入力証明アクセストークンとKDCと安全に通信するパラメーターを提供します（セクション3.2を参照）。
Communications between the Client and the AS MUST be secured according to what is defined by the used transport profile of ACE. The Content-Format used in the message also depends on the used transport profile of ACE. For example, it can be "application/ ace+cbor" for the first two messages and "application/cwt" for the third message, which are defined in the ACE framework.
クライアントとASの間の通信は、ACEの使用済み輸送プロファイルによって定義されるものに従って保護する必要があります。メッセージで使用されるコンテンツフォーマットは、ACEの使用済み輸送プロファイルにも依存します。たとえば、最初の2つのメッセージの「アプリケーション/ ACE+CBOR」、ACEフレームワークで定義されている3番目のメッセージの「アプリケーション/ CWT」にすることができます。
The transport profile of ACE also defines a number of details, such as the communication and security protocols used with the KDC (see Appendix C of [RFC9200]).
ACEの輸送プロファイルは、KDCで使用される通信およびセキュリティプロトコルなど、多くの詳細も定義しています（[RFC9200]の付録Cを参照）。
Figure 3 gives an overview of the exchange described above.
図3に、上記の交換の概要を示します。
Client AS KDC
| | |
|---- Authorization Request: POST /token ------->| |
| | |
|<--- Authorization Response: 2.01 (Created) ----| |
| | |
|---- Token Transfer Request: POST /authz-info ------->|
| | |
|<--- Token Transfer Response: 2.01 (Created) -------->|
| | |
Figure 3: Message Flow of Join Authorization
図3：結合承認のメッセージフロー
The Authorization Request sent from the Client to the AS is defined in Section 5.8.1 of [RFC9200] and MAY contain the following parameters, which, if included, MUST have the format and value as specified below.
[RFC9200]のセクション5.8.1で定義されているASにクライアントから送信された承認要求には、以下のパラメーターが含まれている場合があります。
* 'scope': specifying the names of the groups that the Client requests to access and optionally the roles that the Client requests to have in those groups.
* 「スコープ」：クライアントがアクセスすることを要求するグループの名前を指定し、オプションではクライアントがそれらのグループで持つことを要求する役割を指定します。
This parameter is encoded as a CBOR byte string, which wraps a CBOR array of scope entries. All the scope entries are specified according to the same format, i.e., either the Authorization Information Format (AIF) or the textual format defined below.
このパラメーターは、CBORバイト文字列としてエンコードされており、SCOPEエントリのCBOR配列をラップします。すべてのスコープエントリは、同じ形式、つまり、承認情報形式（AIF）または以下に定義されているテキスト形式のいずれかに従って指定されます。
- If AIF is used, each scope entry is encoded as per [RFC9237], i.e., as a CBOR array [Toid, Tperm]. If a scope entry expresses a set of roles to take in a group as per this document, the object identifier "Toid" specifies the group name and MUST be encoded as a CBOR text string, while the permission set "Tperm" specifies the roles that the Client wishes to take in the group.
- AIFを使用すると、各スコープエントリは[RFC9237]、つまりCBORアレイ[TOID、TPERM]としてエンコードされます。スコープエントリがこのドキュメントに従ってグループを取り入れるロールのセットを表している場合、オブジェクト識別子「TOID」はグループ名を指定し、CBORテキスト文字列としてエンコードする必要があり、許可セット「TPERM」は、クライアントはグループに参加したいと考えています。
AIF is the default format for application profiles of this specification and is preferable for those that aim for a compact encoding of scope. This is especially desirable for application profiles defining several roles, with the Client possibly asking for multiple roles combined.
AIFは、この仕様のアプリケーションプロファイルのデフォルト形式であり、スコープのコンパクトなエンコードを目指しているものよりも好ましいものです。これは、いくつかの役割を定義するアプリケーションプロファイルで特に望ましいものであり、クライアントは複数のロールを組み合わせることを要求する可能性があります。
Figure 4 shows an example in CDDL notation [RFC8610] where scope uses AIF.
図4は、ScopeがAIFを使用するCDDL表記[RFC8610]の例を示しています。
- If the textual format is used, each scope entry is a CBOR array formatted as follows.
- テキスト形式が使用される場合、各スコープエントリは次のようにフォーマットされたCBORアレイです。
o As the first element, the group name, encoded as a CBOR text string.
o 最初の要素として、CBORテキスト文字列としてエンコードされたグループ名。
o Optionally, as the second element, the role or CBOR array of roles that the Client wishes to take in the group. This element is optional since roles may have been pre-assigned to the Client, as associated with its verifiable identity credentials. Alternatively, the application may have defined a single, well-known role for the target resource(s) and audience(s).
o オプションでは、2番目の要素として、クライアントがグループに取り入れたい役割の役割またはCBORアレイ。この要素は、その検証可能なID資格情報に関連付けられているように、役割がクライアントに事前に割り当てられている可能性があるため、オプションです。あるいは、アプリケーションは、ターゲットリソースと視聴者の単一のよく知られた役割を定義した可能性があります。
Figure 5 shows an example in CDDL notation where scope uses the textual format with the group name and role identifiers encoded as CBOR text strings.
図5は、ScopeがCBORテキスト文字列としてエンコードされたグループ名とロール識別子を使用してテキスト形式を使用するCDDL表記の例を示しています。
It is REQUIRED for application profiles of this specification to specify the exact format and encoding of scope (REQ1). This includes defining the set of possible roles and their identifiers, as well as the corresponding encoding to use in the scope entries according to the used scope format.
この仕様のアプリケーションプロファイルには、スコープの正確な形式とエンコード（REQ1）を指定することが必要です。これには、可能な役割のセットとその識別子の定義、および使用するスコープ形式に従ってスコープエントリで使用する対応するエンコードが含まれます。
If the application profile uses AIF, it is also REQUIRED to register its specific instance of "Toid" and "Tperm", as well as the corresponding media type and Content-Format, as per the guidelines in [RFC9237] (REQ2).
アプリケーションプロファイルがAIFを使用する場合、[RFC9237]（REQ2）のガイドラインに従って、「TOID」と「TPERM」の特定のインスタンス、および対応するメディアタイプとコンテンツフォーマットを登録することも必要です。
If the application profile uses the textual format, it MAY additionally specify CBOR values to use for abbreviating the role identifiers (OPT1).
アプリケーションプロファイルがテキスト形式を使用する場合、役割識別子（OPT1）を略すために使用するCBOR値をさらに指定する場合があります。
* 'audience': with an identifier of the KDC.
* 「オーディエンス」：KDCの識別子を使用。
As defined in [RFC9200], other additional parameters can be included if necessary.
[RFC9200]で定義されているように、必要に応じて他の追加パラメーターを含めることができます。
;# include rfc9237
gname = tstr
permissions = uint .bits roles
roles = &(
Requester: 1,
Responder: 2,
Monitor: 3,
Verifier: 4
)
scope_entries = AIF-Generic<gname, permissions>
scope = bstr .cbor scope_entries
Figure 4: Example of scope Using AIF
図4：AIFを使用した範囲の例
gname = tstr
role = tstr
scope_entry = [gname, ? ( role / [2* role] )]
scope_entries = [* scope_entry]
scope = bstr .cbor scope_entries
Figure 5: Example of scope Using the Textual Format, with the Role Identifiers Encoded as Text Strings
図5：テキスト識別子がテキスト文字列としてエンコードされたテキスト形式を使用したスコープの例
The AS processes the Authorization Request as defined in Section 5.8.2 of [RFC9200], especially verifying that the Client is authorized to access the specified groups with the requested roles or possibly a subset of those.
ASは、[RFC9200]のセクション5.8.2で定義されている許可要求を処理します。特に、クライアントが要求された役割またはおそらくそれらのサブセットで指定されたグループにアクセスすることを許可されていることを確認します。
In case of successful verification, the Authorization Response sent from the AS to the Client is also defined in Section 5.8.2 of [RFC9200]. Note that the 'expires_in' parameter MAY be omitted if the application defines how the expiration time is communicated to the Client via other means or if it establishes a default value.
検証が成功した場合、クライアントに送信された承認応答は、[RFC9200]のセクション5.8.2でも定義されています。「Expires_in」パラメーターは、有効期限が他の手段を介してクライアントに通信する方法を定義する場合、またはデフォルト値を確立する場合、「Expires_in」パラメーターを省略することができることに注意してください。
Additionally, when included, the following parameter MUST have the corresponding values:
さらに、含まれる場合、次のパラメーターには対応する値が必要です。
* 'scope' has the same format and encoding of 'scope' in the Authorization Request, as defined in Section 3.1. If this parameter is not present, the granted scope is equal to the one requested in Section 3.1.
* 「Scope」には、セクション3.1で定義されているように、承認要求における「スコープ」の形式とエンコードが同じです。このパラメーターが存在しない場合、付与されたスコープはセクション3.1で要求されたスコープと等しくなります。
The proof-of-possession access token in the 'access_token' parameter MUST contain the following:
「Access_Token」パラメーターのProof-of-Possession Accessトークンには、以下を含める必要があります。
* a confirmation claim (for example, see 'cnf' defined in Section 3.1 of [RFC8747] for CWTs)
* 確認請求（たとえば、CWTSの[RFC8747]のセクション3.1で定義されている「CNF」を参照）
* an expiration time claim (for example, see 'exp' defined in Section 3.1.4 of [RFC8392] for CWTs)
* 有効期限の請求（たとえば、CWTSの[RFC8392]のセクション3.1.4で定義されている「Exp」を参照）
* a scope claim (for example, see 'scope' registered in Section 8.14 of [RFC9200] for CWTs)
* スコープクレーム（たとえば、CWTSの[RFC9200]のセクション8.14に登録されている「スコープ」を参照）
If the 'scope' parameter is present in the Authorization Response, this claim specifies the same access control information as in the 'scope' parameter. Instead, if the 'scope' parameter is not present in the Authorization Response, this claim specifies the same access control information as in the 'scope' parameter of the Authorization Request, if the parameter is present therein, or the default scope that the AS is granting the Client otherwise.
「スコープ」パラメーターが承認応答に存在する場合、このクレームは「スコープ」パラメーターと同じアクセス制御情報を指定します。代わりに、「スコープ」パラメーターが承認応答に存在しない場合、このクレームは、許可要求の「スコープ」パラメーターと同じアクセス制御情報を指定します。それ以外の場合はクライアントに付与しています。
By default, this claim has the same encoding as the 'scope' parameter in the Authorization Request, as defined in Section 3.1.
デフォルトでは、このクレームは、セクション3.1で定義されているように、承認要求の「スコープ」パラメーターと同じエンコードを持っています。
Optionally, an alternative extended format of scope defined in Section 7 can be used. This format explicitly signals the semantics used to express the actual access control information, which has to be parsed. This enables a Resource Server to correctly process a received access token, also in case:
オプションで、セクション7で定義された範囲の代替拡張形式を使用できます。この形式は、実際のアクセス制御情報を表すために使用されるセマンティクスを明示的に信号します。これは解析する必要があります。これにより、リソースサーバーが受信したアクセストークンを正しく処理できます。
- The Resource Server implements a KDC that supports multiple application profiles of this specification using different scope semantics and/or
- リソースサーバーは、異なるスコープセマンティクスおよび/または
- The Resource Server implements further services beyond a KDC for group communication using different scope semantics.
- リソースサーバーは、さまざまなスコープセマンティクスを使用して、グループ通信のためにKDCを超えたさらなるサービスを実装しています。
If the Authorization Server is aware that this applies to the Resource Server for which the access token is issued, the Authorization Server SHOULD use the extended format of scope defined in Section 7.
Authorization Serverがアクセストークンが発行されるリソースサーバーに適用されることを認識している場合、Authorization Serverはセクション7で定義されている範囲の拡張形式を使用する必要があります。
The access token MAY additionally contain other claims that the transport profile of ACE or other optional parameters require.
アクセストークンには、ACEまたは他のオプションパラメーターの輸送プロファイルが必要とする他の主張がさらに含まれる場合があります。
When receiving an Authorization Request from a Client that was previously authorized and for which the AS still stores a valid non-expired access token, the AS MAY reply with that token. Note that it is up to application profiles of ACE to make sure that reposting the same access token does not cause reuse of keying material between nodes (for example, that is accomplished with the use of random nonces in [RFC9203]).
以前に許可されていたクライアントから承認要求を受け取った場合、ASが有効な既存のアクセストークンを保存している場合、ASはそのトークンで返信します。同じアクセストークンを再投稿しても、ノード間のキーイング材料の再利用を引き起こさないことを確認するのは、ACEのアプリケーションプロファイル次第であることに注意してください（たとえば、[RFC9203]でランダムなノンセスを使用して達成されます）。
The Client sends a Token Transfer Request to the KDC, i.e., a CoAP POST request including the access token and targeting the /authz-info endpoint (see Section 5.10.1 of [RFC9200]).
クライアントは、トークン転送要求をKDCに送信します。つまり、アクセストークンを含むCOAP POSTリクエストと /authz-infoエンドポイントをターゲットにします（[RFC9200]のセクション5.10.1を参照）。
Note that this request deviates from the one defined in [RFC9200], since it allows asking the KDC for additional information concerning the authentication credentials used in the group to ensure source authentication, as well as for possible additional group parameters.
このリクエストは、[RFC9200]で定義されたものから逸脱していることに注意してください。これは、グループで使用される認証資格に関する追加情報と、ソース認証を確保するために、および追加のグループパラメーターを確保することができるためです。
The joining node MAY ask for this information from the KDC through the same Token Transfer Request. In this case, the message MUST have Content-Format "application/ace+cbor" registered in Section 8.16 of [RFC9200], and the message payload MUST be formatted as a CBOR map, which MUST include the access token. The CBOR map MAY additionally include the following parameter, which, if included, MUST have the format and value as specified below.
結合ノードは、同じトークン転送要求を介してKDCからこの情報を要求する場合があります。この場合、メッセージには[RFC9200]のセクション8.16に登録されているコンテンツフォーマット「アプリケーション/ACE+CBOR」が必要であり、メッセージペイロードはCBORマップとしてフォーマットする必要があります。CBORマップには、以下のパラメーターが追加される場合があります。これには、以下に指定されている形式と値が必要です。
* 'sign_info': defined in Section 3.3.1, specifying the CBOR simple value null (0xf6) to request information about the signature algorithm, the signature algorithm parameters, the signature key parameters, and the exact format of authentication credentials used in the groups that the Client has been authorized to join.
* 'SIGN_INFO'：セクション3.3.1で定義されており、CBOR Simple Value Null（0xf6）を指定して、署名アルゴリズム、署名アルゴリズムパラメーター、署名キーパラメーター、およびグループで使用される認証資格情報の正確な形式に関する情報を要求します。クライアントは参加する権限があります。
Alternatively, such information may be pre-configured on the joining node or may be retrieved by alternative means. For example, the joining node may have performed an early group discovery process and obtained the link to the associated group-membership resource at the KDC, along with attributes that describe the group configuration (e.g., see [OSCORE-DISCOVERY]).
あるいは、そのような情報は、結合ノードで事前に構成されているか、代替手段によって取得される場合があります。たとえば、結合ノードは初期のグループ発見プロセスを実行し、KDCの関連グループメンバーシップリソースへのリンクを取得した可能性があり、グループ構成を説明する属性（たとえば、[Oscore-Discovery]を参照）。
After successful verification, the Client is authorized to receive the group keying material from the KDC and join the group. Hence, the KDC replies to the Client with a Token Transfer Response, i.e., a CoAP 2.01 (Created) response.
検証が成功した後、クライアントはKDCからグループキーイング資料を受け取り、グループに参加することを許可されます。したがって、KDCはトークン転送応答、つまりCoap 2.01（作成）応答でクライアントに応答します。
The Token Transfer Response MUST have Content-Format "application/ ace+cbor", and its payload is a CBOR map. Note that this deviates from what is defined in the ACE framework, where the response from the /authz-info endpoint is defined as conveying no payload (see Section 5.10.1 of [RFC9200]).
トークン転送応答には、コンテンツフォーマット「Application/ ACE+CBOR」が必要であり、そのペイロードはCBORマップです。これは、 /authz-infoエンドポイントからの応答がペイロードを伝えないと定義されているACEフレームワークで定義されているものから逸脱していることに注意してください（[RFC9200]のセクション5.10.1を参照）。
If a scope entry in the access token specifies a role that requires the Client to send its own authentication credential to the KDC when joining the related group, then the CBOR map MUST include the 'kdcchallenge' parameter defined in Section 3.3.2, specifying a dedicated challenge N_S generated by the KDC.
アクセストークンのスコープエントリが、関連するグループに参加するときにクライアントが独自の認証資格をKDCに送信することを要求する役割を指定する場合、CBORマップにはセクション3.3.2で定義されている「KDCChallenge」パラメーターを含める必要があります。KDCによって生成された専用のチャレンジN_S。
Later, when joining the group (see Section 4.3.1.1), the Client uses the 'kdcchallenge' value and additional information to build a proof-of-possession (PoP) input. In turn, this is used to compute the PoP evidence that the Client also provides to the KDC, in order to prove possession of its own private key (see the 'client_cred_verify' parameter in Section 4.3.1).
その後、グループに参加すると（セクション4.3.1.1を参照）、クライアントは「KDCChallenge」値と追加情報を使用して、Proof-of-Possession（POP）入力を構築します。次に、これは、クライアントがKDCに提供するポップエビデンスを計算するために使用され、独自の秘密鍵の所有を証明するために（セクション4.3.1の「client_cred_verify」パラメーターを参照）。
While storing the access token, the KDC MUST store the 'kdcchallenge' value associated with the Client at least until it receives a Join Request from the Client (see Section 4.3.1.1) to be able to verify the PoP evidence provided during the join process and thus that the Client possesses its own private key. The KDC deletes the 'kdcchallenge' value associated with the Client upon deleting the access token (e.g., upon its expiration, see Section 5.10.3 of [RFC9200]).
アクセストークンを保存する際、KDCは、クライアントからの参加要求を受信するまで（セクション4.3.1.1を参照）、クライアントに関連付けられた「KDCChallenge」値を保存する必要があります。したがって、クライアントが独自の秘密鍵を所有していること。KDCは、アクセストークンを削除したときにクライアントに関連付けられた「KDCChallenge」値を削除します（例：その有効期限は、[RFC9200]のセクション5.10.3を参照）。
The same 'kdcchallenge' value MAY be reused several times by the Client to generate new PoP evidence, e.g., in case the Client provides the KDC with a new authentication credential while being a group member (see Section 4.9.1.1) or joins a different group where it intends to use a different authentication credential. Therefore, it is RECOMMENDED that the KDC keeps storing the 'kdcchallenge' value after the first join is processed as well. If, upon receiving a Join Request from a Client, the KDC has already discarded the 'kdcchallenge' value, that will trigger an error response with a newly generated 'kdcchallenge' value that the Client can use to restart the join process, as specified in Section 4.3.1.1.
同じ「kdcchallenge」値は、クライアントが新しいポップエビデンスを生成するためにクライアントが数回再利用することができます。別の認証資格情報を使用するつもりであるグループ。したがって、最初の結合も処理された後、KDCが「KDCChallenge」値を保存し続けることをお勧めします。クライアントからの結合要求を受信すると、KDCがすでに「KDCChallenge」値を破棄している場合、それはクライアントが指定されているように、クライアントが参加プロセスを再起動するために使用できる新しく生成された「KDCChallenge」値でエラー応答をトリガーします。セクション4.3.1.1。
If 'sign_info' is included in the Token Transfer Request, the KDC SHOULD include the 'sign_info' parameter in the Token Transfer Response, as per the format defined in Section 3.3.1. Note that the field 'id' of each 'sign_info_entry' specifies the name or array of group names to which that 'sign_info_entry' applies. As an exception, the KDC MAY omit the 'sign_info' parameter in the Token Transfer Response even if 'sign_info' is included in the Token Transfer Request in case none of the groups that the Client is authorized to join use signatures to achieve source authentication.
「sign_info」がトークン転送要求に含まれている場合、KDCはセクション3.3.1で定義されている形式に従って、トークン転送応答に「sight_info」パラメーターを含める必要があります。各「sight_info_entry」のフィールド「id」は、「sight_info_entry」が適用されるグループ名の名前または配列を指定することに注意してください。例外として、KDCは、クライアントが参加しているグループが署名を使用してソース認証を実現することを許可されているグループのいずれにも備えて、「sign_info」がトークン転送要求に含まれている場合でも、トークン転送応答の「sight_info」パラメーターを省略する場合があります。
Note that the CBOR map specified as payload of the 2.01 (Created) response may include further parameters, e.g., according to the used transport profile of ACE. Application profiles of this specification MAY define additional parameters to use within this exchange (OPT2).
2.01（作成）応答のペイロードとして指定されたCBORマップには、ACEの使用済み輸送プロファイルに従って、さらなるパラメーターが含まれる場合があることに注意してください。この仕様のアプリケーションプロファイルは、この交換（OPT2）内で使用する追加のパラメーターを定義する場合があります。
Application profiles of this specification MAY define alternative specific negotiations of parameter values for the signature algorithm and signature keys if 'sign_info' is not used (OPT3).
この仕様のアプリケーションプロファイルでは、「Sign_Info」が使用されていない場合、署名アルゴリズムのパラメーター値の代替特定の交渉と署名キーを定義できます（OPT3）。
If allowed by the used transport profile of ACE, the Client may provide the access token to the KDC by other means than the Token Transfer Request. An example is the DTLS transport profile of ACE, where the Client can provide the access token to the KDC during the secure session establishment (see Section 3.3.2 of [RFC9202]).
ACEの使用済み輸送プロファイルによって許可されている場合、クライアントは、トークン転送要求以外の手段でKDCへのアクセストークンを提供できます。例としては、ACEのDTLS輸送プロファイルがあり、クライアントは安全なセッションの確立中にKDCにアクセストークンを提供できます（[RFC9202]のセクション3.3.2を参照）。
The 'sign_info' parameter is an OPTIONAL parameter of the request and response messages exchanged between the Client and the /authz-info endpoint at the RS (see Section 5.10.1 of [RFC9200]).
「sign_info」パラメーターは、クライアントとRSの /authz-infoエンドポイントの間で交換されるリクエストと応答メッセージのオプションパラメーターです（[RFC9200]のセクション5.10.1を参照）。
This parameter allows the Client and the RS to exchange information about a signature algorithm and about authentication credentials to accordingly use for signature verification. Its exact semantics and content are application specific.
このパラメーターにより、クライアントとRSは、署名アルゴリズムに関する情報と、署名検証にそれに応じて使用する認証資格情報に関する情報を交換できます。その正確なセマンティクスとコンテンツはアプリケーション固有です。
In this specification and in application profiles building on it, this parameter is used to exchange information about the signature algorithm and about authentication credentials to be used with it in the groups indicated by the transferred access token as per its 'scope' claim (see Section 3.2).
この仕様とその上に構築するアプリケーションプロファイルでは、このパラメーターは、署名アルゴリズムに関する情報と、「スコープ」クレームに従って転送されたアクセストークンによって示されるグループで使用される認証資格情報を交換するために使用されます（セクションを参照3.2）。
When used in the Token Transfer Request sent to the KDC (see Section 3.3), the 'sign_info' parameter specifies the CBOR simple value null (0xf6). This is done to ask for information about the signature algorithm and about the authentication credentials used in the groups that, as per the granted roles, the Client has been authorized to join or interact with (e.g., as an external signature verifier).
KDCに送信されたトークン転送要求で使用される場合（セクション3.3を参照）、「SIGN_INFO」パラメーターはCBOR Simple Value Null（0xf6）を指定します。これは、署名アルゴリズムに関する情報と、付与された役割に従って、クライアントが参加または対話することが許可されているグループ（例：外部署名検証者として）で使用されるグループで使用される認証資格情報を求めるために行われます。
When used in the following Token Transfer Response from the KDC (see Section 3.3), the 'sign_info' parameter is a CBOR array of one or more elements. The number of elements is at most the number of groups that the Client has been authorized to join or interact with. Each element contains information about signing parameters and about authentication credentials for one or more groups and is formatted as follows.
KDCからの次のトークン転送応答（セクション3.3を参照）で使用する場合、「SIGN_INFO」パラメーターは1つ以上の要素のCBOR配列です。要素の数は、せいぜいクライアントが参加または対話することを許可されているグループの数です。各要素には、1つ以上のグループの署名パラメーターと認証資格情報に関する情報が含まれており、次のようにフォーマットされています。
* The first element 'id' is a group name or a CBOR array of group names, which is associated with groups for which the next four elements apply. Each specified group name is a CBOR text string and is hereafter referred to as 'gname'.
* 最初の要素「ID」は、グループ名またはグループ名のCBOR配列であり、次の4つの要素が適用されるグループに関連付けられています。指定された各グループ名はCBORテキスト文字列であり、以下「GNAME」と呼ばれます。
* The second element 'sign_alg' is a CBOR integer or a text string that indicates the signature algorithm used in the groups identified by the 'gname' values. It is REQUIRED for application profiles to define specific values that this parameter can take (REQ3), which are selected from the set of signing algorithms of the "COSE Algorithms" registry [COSE.Algorithms].
* 2番目の要素「Sign_Alg」は、「GNAME」値で識別されたグループで使用される署名アルゴリズムを示すCBOR整数またはテキスト文字列です。アプリケーションプロファイルには、「COSEアルゴリズム」レジストリ[COSE.ALGORITHMS]の署名アルゴリズムのセットから選択されたこのパラメーターが取得できる特定の値を定義するために必要です。
* The third element 'sign_parameters' is a CBOR array that indicates the parameters of the signature algorithm used in the groups identified by the 'gname' values. Its content depends on the value of 'sign_alg'. It is REQUIRED for application profiles to define the possible values and structure for the elements of this parameter (REQ4).
* 3番目の要素「Sign_Parameters」は、「GNAME」値で識別されるグループで使用される署名アルゴリズムのパラメーターを示すCBORアレイです。そのコンテンツは、「sign_alg」の値に依存します。アプリケーションプロファイルがこのパラメーターの要素（REQ4）の可能な値と構造を定義するために必要です。
* The fourth element 'sign_key_parameters' is a CBOR array that indicates the parameters of the key used with the signature algorithm in the groups identified by the 'gname' values. Its content depends on the value of 'sign_alg'. It is REQUIRED for application profiles to define the possible values and structure for the elements of this parameter (REQ5).
* 4番目の要素「SIGN_KEY_PARAMETERS」は、「GNAME」値で識別されたグループの署名アルゴリズムで使用されるキーのパラメーターを示すCBORアレイです。そのコンテンツは、「sign_alg」の値に依存します。アプリケーションプロファイルがこのパラメーターの要素（REQ5）の可能な値と構造を定義するために必要です。
* The fifth element 'cred_fmt' either is a CBOR integer indicating the format of authentication credentials used in the groups identified by the 'gname' values or is the CBOR simple value null (0xf6), which indicates that the KDC does not act as a repository of authentication credentials for group members. Its acceptable integer values are taken from the "Label" column of the "COSE Header Parameters" registry [COSE.Header.Parameters], with some of those values also indicating the type of container to use for exchanging the authentication credentials with the KDC (e.g., a chain or bag of certificates). It is REQUIRED for application profiles to define specific values to use for this parameter, consistently with the acceptable formats of authentication credentials (REQ6).
* 5番目の要素 'cred_fmt'は、「gname」値で識別されたグループで使用される認証資格情報の形式を示すcbor整数であるか、またはkdcがリポジトリとして機能しないことを示すCbor単純値null（0xf6）です。グループメンバーの認証資格情報の。その許容可能な整数値は、「COSEヘッダーパラメーター」レジストリ[cose.header.parameters]の「ラベル」列から取得されます。これらの値の一部は、認証資格情報をKDCと交換するために使用するコンテナのタイプを示しています（例えば、証明書のチェーンまたは袋）。アプリケーションプロファイルが、認証資格情報の許容形式（REQ6）と一貫して、このパラメーターに使用する特定の値を定義するために必要です。
The CDDL notation [RFC8610] of the 'sign_info' parameter is given below.
「sign_info」パラメーターのCDDL表記[RFC8610]を以下に示します。
sign_info = sign_info_req / sign_info_resp
sign_info_req = null ; in the Token Transfer
; Request to the KDC
sign_info_resp = [+ sign_info_entry] ; in the Token Transfer
; Response from the KDC
sign_info_entry =
[
id: gname / [+ gname],
sign_alg: int / tstr,
sign_parameters: [any],
sign_key_parameters: [+ parameter: any],
cred_fmt: int / null
]
gname = tstr
This format is consistent with every signature algorithm currently defined in [RFC9053], i.e., with algorithms that have only the COSE key type as their COSE capability. Appendix B describes how the format of each 'sign_info_entry' can be generalized for possible future registered algorithms having a different set of COSE capabilities.
この形式は、[RFC9053]で現在定義されているすべての署名アルゴリズム、つまりCOSEキータイプのみをCOSE機能として持つアルゴリズムと一致しています。付録Bでは、各「sight_info_entry」の形式を、COSE機能の異なるセットを持つ可能性のある登録アルゴリズムの可能性にどのように一般化できるかについて説明します。
The 'kdcchallenge' parameter is an OPTIONAL parameter of the response message returned from the /authz-info endpoint at the RS, as defined in Section 5.10.1 of [RFC9200]. This parameter contains a challenge generated by the RS and provided to the Client.
「KDCChallenge」パラメーターは、[RFC9200]のセクション5.10.1で定義されているように、RSの /authz-infoエンドポイントから返される応答メッセージのオプションパラメーターです。このパラメーターには、RSによって生成され、クライアントに提供される課題が含まれています。
In this specification and in application profiles building on it, the Client can use this challenge to prove possession of its own private key in the Join Request (see the 'client_cred_verify' parameter in Section 4.3.1).
この仕様とその上に構築されるアプリケーションプロファイルでは、クライアントはこの課題を使用して、参加要求に独自の秘密鍵を所有することを証明できます（セクション4.3.1の「client_cred_verify」パラメーターを参照）。
This section describes the functionalities provided by the KDC, as related to the provisioning of the keying material as well as to the group membership management.
このセクションでは、KDCが提供する機能性について、キーイングマテリアルのプロビジョニングとグループメンバーシップ管理に関連しています。
In particular, this section defines the interface available at the KDC, specifies the handlers of each resource provided by the KDC interface, and describes how Clients interact with those resources to join a group and to perform additional operations as group members.
特に、このセクションでは、KDCで利用可能なインターフェイスを定義し、KDCインターフェイスによって提供される各リソースのハンドラーを指定し、クライアントがグループに参加し、グループメンバーとして追加の操作を実行するためにそれらのリソースと対話する方法について説明します。
A key operation that the Client can perform after transferring the access token to the KDC is a Join Request-Response exchange with the KDC. In the Join Request, the Client specifies the group it requests to join (see Section 4.3.1.1). The KDC will then check the stored access token associated with the Client and verify that the Client is accordingly authorized to join the specified group. In case of successful verification, the KDC provides the Client with the keying material to securely communicate with the other members of the group.
アクセストークンをKDCに転送した後にクライアントが実行できる重要な操作は、KDCとの結合リクエスト応答交換です。参加要求では、クライアントは参加するよう要求するグループを指定します（セクション4.3.1.1を参照）。KDCは、クライアントに関連付けられた保存されたアクセストークンをチェックし、クライアントが指定されたグループに参加することを許可されていることを確認します。検証が成功した場合、KDCは、グループの他のメンバーと安全に通信するためのキーリング資料をクライアントに提供します。
Later on as a group member, the Client can also rely on the interface at the KDC to perform additional operations consistent with the roles it has in the group.
後でグループメンバーとして、クライアントはKDCのインターフェイスに依存して、グループ内の役割に沿った追加の操作を実行することもできます。
The KDC provides its interface by hosting the following resources. Note that the root url-path "ace-group" used hereafter is a default name; implementations are not required to use this name and can define their own instead.
KDCは、次のリソースをホストすることにより、インターフェイスを提供します。今後使用されているルートURLパス「エースグループ」はデフォルト名であることに注意してください。実装はこの名前を使用する必要はなく、代わりに独自の名前を定義できます。
If request messages sent to the KDC as well as success response messages from the KDC include a payload and specify a Content-Format, those messages MUST have Content-Format "application/ace-groupcomm+cbor", which is registered in Section 11.2. CBOR map keys used for the message parameters are defined in Section 8.
KDCに送信された要求メッセージとKDCからの成功応答メッセージにはペイロードが含まれ、コンテンツフォーマットが指定されている場合、それらのメッセージにはセクション11.2に登録されているコンテンツフォーマット「Application/ACE-GroupComm+CBOR」が必要です。メッセージパラメーターに使用されるCBORマップキーは、セクション8で定義されています。
* /ace-group : the path of this root resource is invariant once the resource is established. Its employment indicates that this specification is used. If other applications run on a KDC implementing this specification and use this same path, those applications will collide, and a mechanism will be needed to differentiate the endpoints.
* /ACE-GROUP：リソースが確立されると、このルートリソースのパスは不変です。その雇用は、この仕様が使用されていることを示しています。この仕様を実装するKDCで他のアプリケーションが実行され、この同じパスを使用すると、それらのアプリケーションが衝突し、エンドポイントを区別するためにメカニズムが必要になります。
A Client can access this resource in order to retrieve a set of group names, each corresponding to one of the specified group identifiers. This operation is described in Section 4.2.1.1.
クライアントは、指定されたグループ識別子の1つに対応する一連のグループ名を取得するために、このリソースにアクセスできます。この操作については、セクション4.2.1.1で説明します。
Clients may be authorized to access this resource even without being members of any group managed by the KDC and even if they are not authorized to become group members (e.g., when authorized to be external signature verifiers).
クライアントは、KDCが管理するグループのメンバーでなくても、グループメンバーになることを許可されていなくても（例：外部署名検証剤として許可されている場合）、このリソースにアクセスする権限を与えられる場合があります。
The Interface Description (if=) Link Target Attribute value "ace.groups" is registered in Section 11.5 and can be used to describe the interface provided by this root resource.
インターフェイスの説明（if =）リンクターゲット属性値「ace.groups」はセクション11.5に登録されており、このルートリソースによって提供されるインターフェイスを記述するために使用できます。
The example below shows an exchange with a KDC with address 2001:db8::ab that hosts the resource /ace-group and returns a link to such a resource in link-format [RFC6690].
以下の例は、リソース /ACE-Groupをホストし、リンクフォーマット[RFC6690]のこのようなリソースへのリンクを返すDB8 :: ABを備えたKDCとの交換を示しています[RFC6690]。
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: ".well-known"
Uri-Path: "core"
Uri-Query: "if=ace.groups"
Response:
Header: Content (Code=2.05)
Content-Format: 40 (application/link-format)
Payload:
<coap://[2001:db8::ab]/ace-group>;if="ace.groups"
* /ace-group/GROUPNAME : one such sub-resource to /ace-group is hosted for each group with the name GROUPNAME that the KDC manages. In particular, it is the group-membership resource associated with that group, and it contains the symmetric group keying material of that group.
* /ACE-GROUP /GROUPNAME：そのようなサブリソースへの1つは、KDCが管理する名前グループ名を持つ各グループに対してホストされています。特に、それはそのグループに関連するグループメンバーシップリソースであり、そのグループの対称グループキーイング素材が含まれています。
A Client can access this resource in order to join the group with name GROUPNAME or later as a group member to retrieve the current group keying material. These operations are described in Sections 4.3.1.1 and 4.3.2.1, respectively.
クライアントは、このリソースにアクセスして、GroupNameまたは後でグループメンバーとしてグループに参加して、現在のグループキーイングマテリアルを取得することができます。これらの操作については、それぞれセクション4.3.1.1と4.3.2.1で説明します。
The Interface Description (if=) Link Target Attribute value "ace.group" is registered in Section 11.5 and can be used to describe the interface provided by a group-membership resource.
インターフェイスの説明（if =）リンクターゲット属性値 "ace.group"はセクション11.5に登録されており、グループメンバーシップリソースによって提供されるインターフェイスを記述するために使用できます。
The example below shows an exchange with a KDC with address 2001:db8::ab that hosts the group-membership resource /ace-group/ gp1 and returns a link to such a resource in link-format [RFC6690].
以下の例は、Groupメンバーシップリソース / ACE-Group / GP1をホストし、リンクフォーマットのそのようなリソースへのリンクを返す[rfc6690]にリンクを返す、アドレス2001：db8 :: abを含むKDCとの交換を示しています[RFC6690]。
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: ".well-known"
Uri-Path: "core"
Uri-Query: "if=ace.group"
Response:
Header: Content (Code=2.05)
Content-Format: 40 (application/link-format)
Payload:
<coap://[2001:db8::ab]/ace-group/gp1>;if="ace.group"
If it is not required that the value of the GROUPNAME URI path and the group name in the access token scope ('gname' in Section 3.1) coincide, the KDC MUST implement a mechanism to map the GROUPNAME value in the URI to the group name in order to refer to the correct group (REQ7).
GroupName URIパスの値とアクセストークンスコープ（セクション3.1の「GNAME」）のグループ名が一致する必要がない場合、KDCはURIのグループ名をグループ名にマッピングするメカニズムを実装する必要があります。正しいグループ（REQ7）を参照するため。
* /ace-group/GROUPNAME/creds : the path of this resource is invariant once the resource is established. This resource contains the authentication credentials of all the members of the group with the name GROUPNAME.
* /ACE-GROUP/GROUPNAME/CREDS：このリソースのパスは、リソースが確立されると不変です。このリソースには、GroupNameという名前のグループのすべてのメンバーの認証資格情報が含まれています。
This resource is created only in case the KDC acts as a repository of authentication credentials for group members.
このリソースは、KDCがグループメンバーの認証資格情報のリポジトリとして機能する場合にのみ作成されます。
As a group member, a Client can access this resource in order to retrieve the authentication credentials of other group members. That is, the Client can retrieve the authentication credentials of all the current group members or a subset of them by specifying filter criteria. These operations are described in Sections 4.4.2.1 and 4.4.1.1, respectively.
グループメンバーとして、クライアントは他のグループメンバーの認証資格情報を取得するためにこのリソースにアクセスできます。つまり、クライアントは、フィルター基準を指定することにより、現在のすべてのグループメンバーまたはそれらのサブセットの認証資格情報を取得できます。これらの操作は、それぞれセクション4.4.2.1と4.4.1.1で説明されています。
Clients may be authorized to access this resource even without being group members, e.g., if authorized to be external signature verifiers for the group.
クライアントは、グループメンバーでなくても、このリソースにアクセスする権限を与えられる場合があります。
* /ace-group/GROUPNAME/kdc-cred : the path of this resource is invariant once the resource is established. This resource contains the authentication credential of the KDC for the group with the name GROUPNAME.
* /ACE-GROUP/GROUPNAME/KDC-CRED：このリソースのパスは、リソースが確立されると不変です。このリソースには、GroupNameという名前のグループのKDCの認証資格が含まれています。
This resource is created only in case the KDC has an associated authentication credential and this is required for the correct group operation. It is REQUIRED for application profiles to define whether the KDC has such an associated authentication credential (REQ8).
このリソースは、KDCが関連する認証資格情報を持っている場合にのみ作成され、これは正しいグループ操作に必要です。アプリケーションプロファイルには、KDCがこのような関連する認証資格情報（REQ8）を持っているかどうかを定義するために必要です。
As a group member, a Client can access this resource in order to retrieve the current authentication credential of the KDC. This operation is described in Section 4.5.1.1.
グループメンバーとして、クライアントはKDCの現在の認証資格情報を取得するためにこのリソースにアクセスできます。この操作については、セクション4.5.1.1で説明します。
Clients may be authorized to access this resource even without being group members, e.g., if authorized to be external signature verifiers for the group.
クライアントは、グループメンバーでなくても、このリソースにアクセスする権限を与えられる場合があります。
* /ace-group/GROUPNAME/policies : the path of this resource is invariant once the resource is established. This resource contains the group policies of the group with the name GROUPNAME.
* /ACE-GROUP/GROUPNAME/ポリシー：このリソースのパスは、リソースが確立されると不変です。このリソースには、GroupNameという名前のグループのグループポリシーが含まれています。
A Client can access this resource as a group member in order to retrieve the group policies. This operation is described in Section 4.6.1.1.
クライアントは、グループポリシーを取得するために、グループメンバーとしてこのリソースにアクセスできます。この操作については、セクション4.6.1.1で説明します。
* /ace-group/GROUPNAME/num : the path of this resource is invariant once the resource is established. This resource contains the current version number for the symmetric group keying material of the group with the name GROUPNAME.
* /ace-group/groupName/num：このリソースのパスは、リソースが確立されると不変です。このリソースには、GroupNameという名前のグループの対称グループキーイングマテリアルの現在のバージョン番号が含まれています。
A Client can access this resource as a group member in order to retrieve the version number of the keying material currently used in the group. This operation is described in Section 4.7.1.1.
クライアントは、グループで現在使用されているキーイング素材のバージョン番号を取得するために、グループメンバーとしてこのリソースにアクセスできます。この操作については、セクション4.7.1.1で説明します。
* /ace-group/GROUPNAME/nodes/NODENAME : one such sub-resource of /ace-group/GROUPNAME is hosted for each group member of the group with the name GROUPNAME. Each such resource is identified by the node name NODENAME of the associated group member and contains the group keying material and the individual keying material for that group member.
* /ace-group/groupName/nodes/nodename：/ace-group/groupNameのそのようなサブリソースの1つは、グループの名前NameNameを使用してグループの各グループメンバーに対してホストされています。このようなリソースはそれぞれ、関連するグループメンバーのノード名Nodenameによって識別され、グループキーイング素材とそのグループメンバーの個々のキーイング素材が含まれています。
A Client as a group member can access this resource in order to retrieve the current group keying material together with its individual keying material, request new individual keying material to use in the group, and leave the group. These operations are described in Sections 4.8.1.1, 4.8.2.1, and 4.8.3.1, respectively.
グループメンバーとしてのクライアントは、このリソースにアクセスして、個々のキーイング素材と一緒に現在のグループキーイング素材を取得し、グループで使用する新しい個々のキーイング素材を要求し、グループを離れることができます。これらの操作は、それぞれセクション4.8.1.1、4.8.2.1、および4.8.3.1で説明されています。
* /ace-group/GROUPNAME/nodes/NODENAME/cred : the path of this resource is invariant once the resource is established. This resource contains the individual authentication credential for the node with the name NODENAME as a group member of the group with the name GROUPNAME.
* /ace-group/groupName/nodes/nodename/cred：このリソースのパスは、リソースが確立されると不変です。このリソースには、ノードの個々の認証資格情報が含まれています。NODENAMEという名前のグループのグループメンバーとして、NAME GROUPNAMEのグループメンバーが含まれています。
A Client can access this resource in order to upload at the KDC a new authentication credential to use in the group. This operation is described in Section 4.9.1.1.
クライアントは、グループで使用する新しい認証資格情報をKDCにアップロードするために、このリソースにアクセスできます。この操作については、セクション4.9.1.1で説明します。
This resource is not created if the group member does not have an authentication credential to use in the group or if the KDC does not store the authentication credentials of group members.
グループメンバーがグループで使用する認証資格情報を持っていない場合、またはKDCがグループメンバーの認証資格情報を保存しない場合、このリソースは作成されません。
The KDC is expected to fully provide the interface defined above. It is otherwise REQUIRED for the application profiles of this specification to indicate which resources are not hosted, i.e., which parts of the interface defined in this section are not supported by the KDC (REQ9). Application profiles of this specification MAY extend the KDC interface by defining additional handlers, as well as defining additional resources and their handlers.
KDCは、上記のインターフェイスを完全に提供することが期待されています。それ以外の場合は、この仕様のアプリケーションプロファイルがホストされていないリソース、つまりこのセクションで定義されているインターフェイスの一部がKDC（REQ9）でサポートされていないことを示すために必要です。この仕様のアプリケーションプロファイルは、追加のハンドラーを定義するだけでなく、追加のリソースとそのハンドラーを定義することにより、KDCインターフェイスを拡張する場合があります。
It is REQUIRED for application profiles of this specification to register a Resource Type for the group-membership resources (REQ10). This Resource Type can be used to discover the correct URL for sending a Join Request to the KDC. This Resource Type can also be used to indicate which specific application profile of this specification is used by a specific group-membership resource at the KDC.
この仕様のアプリケーションプロファイルには、グループメンバーシップリソース（REQ10）のリソースタイプを登録するために必要です。このリソースタイプを使用して、KDCに参加要求を送信するための正しいURLを発見できます。このリソースタイプは、KDCの特定のグループメンバーシップリソースによって使用されるこの仕様の特定のアプリケーションプロファイルを示すためにも使用できます。
It is REQUIRED for application profiles of this specification to define what specific actions (e.g., CoAP methods) are allowed on each resource provided by the KDC interface, depending on whether the Client is a current group member, the roles that a Client is authorized to take as per the obtained access token (see Section 3.1), and the roles that the Client has as current group member (REQ11).
この仕様のアプリケーションプロファイルには、クライアントが現在のグループメンバーであるかどうかに応じて、KDCインターフェイスが提供する各リソースで特定のアクション（COAPメソッドなど）を定義するために必要です。取得したアクセストークン（セクション3.1を参照）と、クライアントが現在のグループメンバーとして持っている役割（REQ11）に従って取得します。
It is expected that a Client minimally supports the following set of primary operations and corresponding interactions with the KDC.
クライアントは、次の一次操作セットとKDCとの対応する相互作用を最小限にサポートすることが期待されています。
* FETCH request to /ace-group/ in order to retrieve group names associated with group identifiers.
* グループ識別子に関連付けられたグループ名を取得するために、 / ace-group / in to / ace-group /を取得します。
* POST and GET requests to /ace-group/GROUPNAME/ in order to join a group (POST) and later retrieve the current group keying material as a group member (GET).
* グループに参加して（投稿）/ace-group/groupNameへのリクエストを投稿して取得し、その後、現在のグループキーイングマテリアルをグループメンバー（GET）として取得します。
* GET and FETCH requests to /ace-group/GROUPNAME/creds in order to retrieve the authentication credentials of all the other group members (GET) or only some of them by filtering (FETCH). While retrieving authentication credentials remains possible by using GET requests, retrieval by filtering allows Clients to greatly limit the size of exchanged messages.
* 他のすべてのグループメンバーの認証資格情報（取得）または一部のみフィルタリング（フェッチ）を取得するために、/ace-group/groupName/credにリクエストを取得してフェッチします。認証資格情報の取得はGet Requestsを使用して引き続き可能ですが、フィルタリングによる検索により、クライアントは交換されたメッセージのサイズを大幅に制限できます。
* GET request to /ace-group/GROUPNAME/num in order to retrieve the current version of the group keying material as a group member.
* グループメンバーとしてグループキーイングマテリアルの現在のバージョンを取得するために、/ace-group/groupName/numへのリクエストを取得します。
* DELETE request to /ace-group/GROUPNAME/nodes/NODENAME in order to leave the group.
* グループを離れるために、/ace-group/groupName/nodes/nodenameへのリクエストを削除します。
In addition, some Clients may rather not support the following set of secondary operations and corresponding interactions with the KDC. This can be specified, for instance, in compliance documents defining minimalistic Clients and their capabilities in specific deployments. In turn, these might also have to consider the used application profile of this specification.
さらに、一部のクライアントは、以下の二次操作のセットと、KDCとの対応する相互作用をサポートしない場合があります。これは、たとえば、最小限のクライアントとその機能を特定の展開に定義するコンプライアンスドキュメントで指定できます。次に、これらはこの仕様の使用されるアプリケーションプロファイルを考慮する必要がある場合もあります。
* GET request to /ace-group/GROUPNAME/kdc-cred in order to retrieve the current authentication credential of the KDC. This is relevant only if the KDC has an associated authentication credential and this is required for the correct group operation.
* KDCの現在の認証資格情報を取得するために、/ace-group/groupName/KDC-CREDへのリクエストを取得します。これは、KDCが関連する認証資格情報を持っている場合にのみ関連し、正しいグループ操作に必要です。
* GET request to /ace-group/GROUPNAME/policies in order to retrieve the current group policies as a group member.
* 現在のグループメンバーとして現在のグループポリシーを取得するために、/ace-group/groupName/ポリシーへのリクエストを取得します。
* GET request to /ace-group/GROUPNAME/nodes/NODENAME in order to retrieve the current group keying material and individual keying material. The former can also be retrieved through a GET request to /ace-group/GROUPNAME/ (see above).
* 現在のグループキーイング素材と個々のキーイング素材を取得するために、/ace-group/groupName/nodes/nodenameへのリクエストを取得します。前者は、/ace-group/groupName/（上記を参照）のGet Requestを介して取得することもできます。
* POST request to /ace-group/GROUPNAME/nodes/NODENAME in order to ask for new individual keying material. Alternatively, the Client could obtain new individual keying material by rejoining the group through a POST request to /ace-group/GROUPNAME/ (see above). Furthermore, depending on its roles in the group or on the application profile of this specification, the Client might simply not be associated with any individual keying material.
* 新しい個別のキーイング素材を要求するために、/ace-group/groupName/nodes/nodenameへのリクエストを投稿してください。あるいは、クライアントは、/ace-group/groupName/（上記参照）へのPOSTリクエストを介してグループに再び参加することにより、新しい個別のキーイング資料を取得できます。さらに、グループでのその役割またはこの仕様のアプリケーションプロファイルに応じて、クライアントは単に個々のキーイング素材に関連付けられていない場合があります。
* POST request to /ace-group/GROUPNAME/nodes/NODENAME/cred in order to provide the KDC with a new authentication credential. Alternatively, the Client could provide a new authentication credential by rejoining the group through a POST request to /ace-group/GROUPNAME/ (see above). Furthermore, depending on its roles in the group, the Client might simply not have an associated authentication credential to provide.
* KDCに新しい認証資格情報を提供するために、/ace-group/groupName/nodes/nodename/credへのリクエストを投稿します。あるいは、クライアントは、/ace-group/groupName/（上記参照）へのPOSTリクエストを介してグループに再び参加することにより、新しい認証資格情報を提供できます。さらに、グループでのその役割に応じて、クライアントは単に関連する認証資格情報を提供していない場合があります。
It is REQUIRED for application profiles of this specification to categorize possible newly defined operations for Clients into primary and secondary operations and to provide accompanying considerations (REQ12).
この仕様のアプリケーションプロファイルには、クライアントがプライマリおよびセカンダリオペレーションに可能な新たに定義された操作を分類し、それに付随する考慮事項を提供することが必要です（REQ12）。
Upon receiving a request from a Client, the KDC MUST check that it is storing a valid access token from that Client. If this is not the case, the KDC MUST reply with a 4.01 (Unauthorized) error response.
クライアントからのリクエストを受信すると、KDCはそのクライアントから有効なアクセストークンを保存していることを確認する必要があります。そうでない場合、KDCは4.01（不正な）エラー応答で返信する必要があります。
Unless the request targets the /ace-group resource, the KDC MUST check that it is storing a valid access token for that Client such that:
リクエストが /ace-groupリソースをターゲットにしない限り、KDCは、そのクライアントの有効なアクセストークンを保存していることを確認する必要があります。
* the scope specified in the access token includes a scope entry related to the group name GROUPNAME associated with the targeted resource and
* アクセストークンで指定されたスコープには、ターゲットリソースに関連付けられたグループ名グループ名に関連するスコープエントリが含まれます
* the set of roles specified in that scope entry allows the Client to perform the requested operation on the targeted resource (REQ11).
* そのスコープエントリで指定されたロールのセットにより、クライアントはターゲットリソース（REQ11）で要求された操作を実行できます。
In case the KDC stores a valid access token but the verifications above fail, the KDC MUST reply with a 4.03 (Forbidden) error response. This response MAY be an AS Request Creation Hints, as defined in Section 5.3 of [RFC9200], in which case the Content-Format MUST be "application/ace+cbor".
KDCが有効なアクセストークンを保存するが、上記の検証が失敗した場合、KDCは4.03（禁止）エラー応答で返信する必要があります。この応答は、[RFC9200]のセクション5.3で定義されているように、要求作成ヒントである可能性があります。この場合、コンテンツ形式は「アプリケーション/ACE+CBOR」でなければなりません。
If the request is not formatted correctly (e.g., required fields are not present or are not encoded as expected), the KDC MUST reply with a 4.00 (Bad Request) error response.
要求が正しくフォーマットされていない場合（たとえば、必要なフィールドが存在しないか、予想どおりエンコードされていない）、KDCは4.00（悪い要求）エラー応答で返信する必要があります。
If the request includes unknown or unexpected fields, the KDC MUST silently ignore them and continue processing the request. Application profiles of this specification MAY define optional or mandatory payload formats for specific error cases (OPT4).
リクエストに不明または予期しないフィールドが含まれている場合、KDCは静かにそれらを無視し、リクエストの処理を継続する必要があります。この仕様のアプリケーションプロファイルは、特定のエラーケース（OPT4）に対してオプションまたは必須のペイロード形式を定義する場合があります。
Some error responses from the KDC can convey error-specific information according to the problem-details format defined in [RFC9290]. Such error responses MUST have Content-Format "application/concise-problem-details+cbor". The payload of these error responses MUST be a CBOR map specifying a Concise Problem Details data item (see Section 2 of [RFC9290]). The CBOR map is formatted as follows.
KDCからのいくつかのエラー応答は、[RFC9290]で定義されている問題 - セテール形式に従ってエラー固有の情報を伝えることができます。このようなエラー応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」+CBOR」が必要です。これらのエラー応答のペイロードは、簡潔な問題の詳細データ項目を指定するCBORマップでなければなりません（[RFC9290]のセクション2を参照）。CBORマップは次のようにフォーマットされます。
* It MUST include the Custom Problem Detail entry 'ace-groupcomm-error', which is registered in Section 11.6 of this document.
* このドキュメントのセクション11.6に登録されているカスタム問題の詳細エントリ「Ace-GroupComm-Error」を含める必要があります。
This entry is formatted as a CBOR map including only one field, namely 'error-id'. The map key for 'error-id' is the CBOR unsigned integer with value 0. The value of 'error-id' is a CBOR integer specifying the error that occurred at the KDC. This value is taken from the "Value" column of the "ACE Groupcomm Errors" registry defined in Section 11.12 of this document.
このエントリは、1つのフィールド、つまり「エラーID」のみを含むCBORマップとしてフォーマットされています。「Error-ID」のマップキーは、値0のCBORなし署名整数です。「エラーID」の値は、KDCで発生したエラーを指定するCBOR整数です。この値は、このドキュメントのセクション11.12で定義されている「ACE GroupCommエラー」レジストリの「値」列から取得します。
The CDDL notation [RFC8610] of the 'ace-groupcomm-error' entry is given below.
「Ace-GroupComm-Error」エントリのCDDL表記[RFC8610]を以下に示します。
ace-groupcomm-error = {
&(error-id: 0) => int
}
* It MAY include further Standard Problem Detail entries or Custom Problem Detail entries (see [RFC9290]).
* さらに標準の問題の詳細エントリまたはカスタム問題の詳細エントリが含まれる場合があります（[RFC9290]を参照）。
In particular, it can include the Standard Problem Detail entry 'detail' (map key -2), whose value is a CBOR text string that specifies a human-readable, diagnostic description of the error occurred at the KDC. The diagnostic text is intended for software engineers as well as for device and network operators in order to aid debugging and provide context for possible intervention. The diagnostic message SHOULD be logged by the KDC. The 'detail' entry is unlikely relevant in an unattended setup where human intervention is not expected.
特に、標準の問題の詳細エントリ「詳細」（Map Key -2）を含めることができます。その値は、KDCで発生したエラーの人間が読むことができる診断的な説明を指定するCBORテキスト文字列です。診断テキストは、デバッグを支援し、介入の可能性のためのコンテキストを提供するために、ソフトウェアエンジニアとデバイスおよびネットワークオペレーターを対象としています。診断メッセージはKDCによって記録する必要があります。「詳細」エントリは、人間の介入が予想されない無人設定に関連する可能性は低いです。
An example of an error response using the problem-details format is shown in Figure 6.
問題からの問題形式を使用したエラー応答の例を図6に示します。
Response:
Header: Service Unavailable (Code=5.03)
Content-Format: 257 (application/concise-problem-details+cbor)
Payload:
{
/ title / -1: "No available individual keying material",
/ detail / -2: "Things will change after a
group rekeying; try later",
/ ace-groupcomm-error / 0: {
/ error-id / 0: 4 / "No available individual keying material" /
}
}
Figure 6: Example of an Error Response with Problem Details
図6：問題の詳細を含むエラー応答の例
The problem-details format (in general) and the Custom Problem Detail entry 'ace-groupcomm-error' (in particular) are OPTIONAL for Clients to support. A Client supporting the entry 'ace-groupcomm-error' and that can understand the specified error may use that information to determine what actions to take next.
問題は（一般的に）形式（一般的に）形式であり、カスタム問題の詳細エントリ「Ace-GroupComm-Error」（特に）は、クライアントがサポートするためのオプションです。エントリ「Ace-GroupComm-Error」をサポートするクライアントと、指定されたエラーがその情報を使用して、次に実行するアクションを決定することができます。
Section 9 of this specification defines an initial set of error identifiers as possible values for the 'error-id' field. Application profiles of this specification inherit this initial set of error identifiers and MAY define additional values (OPT5).
この仕様のセクション9では、「エラーID」フィールドの可能な値としてエラー識別子の初期セットを定義します。この仕様のアプリケーションプロファイルは、この最初のエラー識別子セットを継承し、追加の値を定義する場合があります（OPT5）。
This resource implements the FETCH handler.
このリソースはフェッチハンドラーを実装します。
The FETCH handler receives group identifiers and returns the corresponding group names and GROUPNAME URIs.
Fetch Handlerはグループ識別子を受信し、対応するグループ名とGroupName URISを返します。
The handler expects a request with the payload formatted as a CBOR map, which MUST contain the following fields:
ハンドラーは、ペイロードフォーマットがCBORマップとしてフォーマットされているリクエストを期待しています。これには、次のフィールドが含まれている必要があります。
* 'gid': its value is encoded as a CBOR array, containing one or more group identifiers. The exact encoding of the group identifier MUST be specified by the application profile (REQ13). The Client indicates that it wishes to receive the group names of all the groups having these identifiers.
* 「GID」：その値は、1つ以上のグループ識別子を含むCBORアレイとしてエンコードされています。グループ識別子の正確なエンコーディングは、アプリケーションプロファイル（REQ13）で指定する必要があります。クライアントは、これらの識別子を持つすべてのグループのグループ名を受け取ることを希望することを示します。
The handler identifies the groups where communications are secured by using the keying material identified by those group identifiers.
ハンドラーは、これらのグループ識別子によって識別されたキーイング材料を使用して、通信が確保されるグループを識別します。
If all verifications succeed, the handler replies with a 2.05 (Content) response, whose payload is formatted as a CBOR map that MUST contain the following fields:
すべての検証が成功した場合、ハンドラーは2.05（コンテンツ）応答で応答します。そのペイロードは、次のフィールドを含む必要があるCBORマップとしてフォーマットされています。
* 'gid': its value is encoded as a CBOR array, containing zero or more group identifiers. The handler indicates that those are the identifiers it is sending group names for. This CBOR array is a subset of the 'gid' array in the FETCH request.
* 「GID」：その値は、ゼロ以上のグループ識別子を含むCBORアレイとしてエンコードされています。ハンドラーは、これらがグループ名を送信している識別子であることを示しています。このCBORアレイは、フェッチリクエストの「GID」配列のサブセットです。
* 'gname': its value is encoded as a CBOR array, containing zero or more group names. The elements of this array are encoded as text strings. Each element of index i in this CBOR array is associated with the element of index i in the 'gid' array.
* 「GNAME」：その値は、ゼロ以上のグループ名を含むCBORアレイとしてエンコードされています。この配列の要素は、テキスト文字列としてエンコードされています。このCBORアレイのインデックスIの各要素は、「GID」アレイのインデックスIの要素に関連付けられています。
* 'guri': its value is encoded as a CBOR array, containing zero or more URIs, each indicating a group-membership resource. The elements of this array are encoded as text strings. Each element of index i in this CBOR array is associated with the element of index i in the 'gid' array.
* 「Guri」：その値は、ゼロ以上のURIを含むCBORアレイとしてエンコードされており、それぞれがグループメンバーシップリソースを示しています。この配列の要素は、テキスト文字列としてエンコードされています。このCBORアレイのインデックスIの各要素は、「GID」アレイのインデックスIの要素に関連付けられています。
If the KDC does not find any group associated with the specified group identifiers, the handler returns a response with the payload formatted as a CBOR byte string of zero length (0x40).
KDCが指定されたグループ識別子に関連付けられたグループを見つけられない場合、ハンドラーは、ゼロ長さ（0x40）のCBORバイト文字列としてフォーマットされたペイロードの応答を返します。
Note that the KDC only verifies that the node is authorized by the AS to access this resource. Nodes that are not members of the group but are authorized to do signature verification on the group messages may be allowed to access this resource if the application needs it.
KDCは、このリソースにアクセスするためにノードが承認されていることのみを確認することに注意してください。グループのメンバーではないが、グループメッセージの署名検証を行うことが許可されているノードは、アプリケーションが必要な場合にこのリソースにアクセスできる場合があります。
In case the joining node only knows the group identifier of the group it wishes to join or about which it wishes to get updated information from the KDC, the node can contact the KDC to request the corresponding group name and group-membership resource URI. In particular, it does so by sending a CoAP FETCH request to the /ace-group endpoint at the KDC formatted as defined in Section 4.2.1. The node can specify several group identifiers at once.
結合ノードが参加したいグループのグループ識別子のみを知っている場合、またはKDCから更新された情報を取得したいグループのグループ識別子のみを知っている場合、ノードはKDCに連絡して、対応するグループ名とグループメンバーシップリソースURIを要求できます。特に、セクション4.2.1で定義されているようにフォーマットされたKDCの /ace-groupエンドポイントにCoAPフェッチリクエストを送信することにより、そうします。ノードは、複数のグループ識別子を一度に指定できます。
Figure 7 gives an overview of the exchanges described above, and Figure 8 shows an example.
図7に、上記の交換の概要を示し、図8に例を示しています。
Client KDC
| |
|------------ Group Name and URI Retrieval Request: -------->|
| FETCH /ace-group |
| |
|<-- Group Name and URI Retrieval Response: 2.05 (Content) --|
| |
Figure 7: Message Flow of Group Name and URI Retrieval Request-Response
図7：グループ名のメッセージフローとURI検索リクエスト応答
Request:
Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ gid / 0: [1, 2]
}
Response:
Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ gid / 0: [1, 2],
/ gname / 1: ["group1", "group2"],
/ guri / 2: ["/ace-group/g1", "/ace-group/g2"]
}
Figure 8: Example of Group Name and URI Retrieval Request-Response
図8：グループ名とURI検索リクエスト応答の例
This resource implements the POST and GET handlers.
このリソースは、投稿を実装し、ハンドラーを取得します。
The POST handler processes the Join Request sent by a Client to join a group and returns a Join Response as a successful result of the joining process (see Section 4.3.1.1). At a high level, the POST handler adds the Client to the list of current group members, adds the authentication credential of the Client to the list of the group members' authentication credentials, and returns the symmetric group keying material for the group identified by GROUPNAME.
ポストハンドラーは、グループに参加するためにクライアントから送信された参加要求を処理し、参加プロセスの成功した結果として参加応答を返します（セクション4.3.1.1を参照）。高レベルで、ポストハンドラーはクライアントを現在のグループメンバーのリストに追加し、クライアントの認証資格情報をグループメンバーの認証資格情報のリストに追加し、GroupNameで識別されたグループの対称グループキーイング素材を返します。
The handler expects a request with payload formatted as a CBOR map, which MAY contain the following fields, which, if included, MUST have the format and value as specified below.
ハンドラーは、ペイロードがCBORマップとしてフォーマットされているリクエストを期待しています。これには、以下のフィールドが含まれている場合は、以下に指定された形式と値が必要です。
* 'scope': its value specifies the name of the group that the Client is attempting to join and the roles that the client wishes to have in the group. This value is encoded as a CBOR byte string wrapping one scope entry, as defined in Section 3.1.
* 「Scope」：その値は、クライアントが参加しようとしているグループの名前と、クライアントがグループに持ちたい役割を指定します。この値は、セクション3.1で定義されているように、1つのスコープエントリをラップするCBORバイト文字列としてエンコードされます。
* 'get_creds': it is included if the Client wishes to receive the authentication credentials of the current group members from the KDC. This parameter may be included in the Join Request if the KDC stores the authentication credentials of the group members, while it is not useful to include it if the Client obtains those authentication credentials through alternative means, e.g., from the AS. Note that including this parameter might result in a following Join Response of a large size, which can be inconvenient for resource-constrained devices.
* 'get_creds'：クライアントがKDCの現在のグループメンバーの認証資格情報を受信したい場合に含まれています。このパラメーターは、KDCがグループメンバーの認証資格情報を保存する場合、Joinリクエストに含めることができますが、クライアントがASからの代替手段を使用してそれらの認証資格情報を取得した場合、それを含めることは役立ちません。このパラメーターを含めると、リソース制約のあるデバイスにとっては不便な大きなサイズの結合応答が得られる可能性があることに注意してください。
If the Client wishes to retrieve the authentication credentials of all the current group members, the 'get_creds' parameter MUST encode the CBOR simple value null (0xf6). Otherwise, if the Client wishes to retrieve the authentication credentials of nodes with specific roles, the 'get_creds' parameter MUST encode a non-empty CBOR array containing the three elements 'inclusion_flag', 'role_filter', and 'id_filter', as defined below.
クライアントが現在のすべてのグループメンバーの認証資格情報を取得したい場合、「GET_CREDS」パラメーターはCBOR Simple Value Null（0xF6）をエンコードする必要があります。それ以外の場合、クライアントが特定の役割を持つノードの認証資格情報を取得したい場合、「get_creds」パラメーターは、以下に定義されているように、3つの要素「inclusion_flag」、「chole_filter」、および「id_filter」を含む非空白のCBORアレイをエンコードする必要があります。。
- The first element, namely 'inclusion_flag', encodes the CBOR simple value true (0xf5) if the Client wishes to receive the authentication credentials of the nodes having their node identifier specified in 'id_filter' (i.e., selection by inclusive filtering). Instead, this element encodes the CBOR simple value false (0xf4) if the Client wishes to receive the authentication credentials of the nodes that do not have the node identifiers specified in the third element 'id_filter' (i.e., selection by exclusive filtering). In the Join Request, this parameter encodes the CBOR simple value true (0xf5).
- 最初の要素、つまり「inclusion_flag」は、クライアントが「id_filter」で指定されているノード識別子（つまり、包括的フィルタリングによる選択）で指定されているノードの認証資格情報を受信したい場合、Cbor simple値真（0xf5）をエンコードします。代わりに、この要素は、クライアントが3番目の要素「ID_FILTER」（つまり、排他的フィルタリングによる選択）で指定されていないノード識別子を持っていないノードの認証資格情報を受け取ることを希望する場合、CBOR Simple Value False（0xf4）をコードします。参加要求では、このパラメーターはCBOR Simple値True（0xf5）をエンコードします。
- The second element, namely 'role_filter', is a CBOR array. Each element of the array contains one role or a combination of roles for the group identified by GROUPNAME. This parameter indicates that the Client wishes to receive the authentication credentials of all the group members having any of the specified roles or combination of roles (i.e., having any of those single roles or at least all the roles indicated in any of those combinations of roles).
- 2番目の要素、つまり「role_filter」はCBORアレイです。配列の各要素には、グループ名で識別されたグループの1つの役割または役割の組み合わせが含まれます。このパラメーターは、クライアントが、指定された役割または役割の組み合わせのいずれかを持っているすべてのグループメンバーの認証資格情報を受け取ることを望んでいることを示しています（つまり、それらの単一の役割または少なくともそれらの役割の組み合わせのいずれかに示されているすべての役割を持っています）。
For example, the array ["role1", "role2+role3"] indicates that the Client wishes to receive the authentication credentials of all group members that have at least "role1" or at least both "role2" and "role3". In the Join Request, this parameter is a non-empty array.
たとえば、アレイ["rofis1"、 "chole2+chole3"]は、クライアントが、少なくとも「役割1」または少なくとも「ロール2」と「ロール3」の両方を持つすべてのグループメンバーの認証資格情報を受け取ることを望んでいることを示しています。参加要求では、このパラメーターは空ではない配列です。
- The third element, namely 'id_filter', is a CBOR array. Each element of the array contains a node identifier of a group member for the group identified by GROUPNAME. This parameter indicates that the Client wishes to receive the authentication credentials of the nodes that have or do not have the specified node identifiers based on the value of 'inclusion_flag' (i.e., as a selection by inclusive or exclusive filtering). In the Join Request, the Client does not filter authentication credentials based on node identifiers, so this parameter is an empty array.
- 3番目の要素、つまり「ID_Filter」はCBORアレイです。配列の各要素には、グループ名で識別されたグループのグループメンバーのノード識別子が含まれています。このパラメーターは、クライアントが「inclusion_flag」の値に基づいて指定されたノード識別子を持っている、または持っていないノードの認証資格情報を受信したいことを示しています（つまり、包括的または排他的フィルタリングによる選択として）。参加要求では、クライアントはノード識別子に基づいて認証資格情報をフィルタリングしないため、このパラメーターは空の配列です。
In fact, when first joining the group, the Client is not expected or capable to express a filter based on node identifiers of other group members. Instead, when already a group member and sending a Join Request to rejoin, the Client is not expected to include the 'get_creds' parameter in the Join Request altogether, since it can rather retrieve authentication credentials associated with specific group identifiers as defined in Section 4.4.1.1.
実際、最初にグループに参加する場合、クライアントは他のグループメンバーのノード識別子に基づいてフィルターを予測または表現できません。代わりに、すでにグループメンバーであり、再加入するために参加要求を送信する場合、クライアントは、セクション4.4で定義されている特定のグループ識別子に関連付けられた認証資格情報を取得できるため、参加要求に「get_creds」パラメーターを完全に含めることは期待されません。.1.1。
The CDDL definition [RFC8610] of 'get_creds' is given in Figure 9; as an example, it uses node identifiers encoded as CBOR byte strings, role identifiers encoded as CBOR text strings, and combinations of roles encoded as CBOR arrays of role identifiers.
「get_creds」のCDDL定義[RFC8610]を図9に示します。例として、CBORバイト文字列としてエンコードされたノード識別子、CBORテキスト文字列としてエンコードされた役割識別子、および役割識別子のCBORアレイとしてエンコードされたロールの組み合わせを使用します。
Note that, for this handler, 'inclusion_flag' is always set to true and the array of roles 'role_filter' is always non-empty, while the array of node identifiers 'id_filter' is always empty. However, this is not necessarily the case for other handlers using the 'get_creds' parameter.
このハンドラーの場合、「inclusion_flag」は常にtrueに設定されており、ロールの配列「役割_filter」は常に空ではありませんが、ノード識別子の配列「id_filter」は常に空です。ただし、「get_creds」パラメーターを使用する他のハンドラーの場合、これは必ずしもそうではありません。
inclusion_flag = bool
role = tstr
comb_role = [2* role]
role_filter = [* ( role / comb_role )]
id = bstr
id_filter = [* id]
get_creds = null / [inclusion_flag, role_filter, id_filter]
Figure 9: CDDL Definition of 'get_creds', Using an Example Node Identifier Encoded as bstr and Role as tstr
図9：BSTRとしてエンコードされ、TSTRとして役割する例「Node識別子」を使用して、「GET_CREDS」のCDDL定義
* 'client_cred': encoded as a CBOR byte string, whose value is the original binary representation of the Client's authentication credential. This parameter MUST be present if the KDC is managing (collecting from and distributing to Clients) the authentication credentials of the group members and the Client's role in the group will require the Client to send messages to one or more group members. It is REQUIRED for application profiles to define the specific formats that are acceptable to use for authentication credentials in the group (REQ6).
* 'client_cred'：Cborバイト文字列としてエンコードされており、その値はクライアントの認証資格情報の元のバイナリ表現です。KDCがグループメンバーの認証資格情報を管理している（クライアントから収集して配布する）場合、グループにおけるクライアントの役割がクライアントにメッセージを1つ以上のグループメンバーに送信することを要求する場合、このパラメーターを存在する必要があります。アプリケーションプロファイルがグループ内の認証資格情報に使用できる特定の形式を定義するために必要です（REQ6）。
* 'cnonce': encoded as a CBOR byte string, whose value is a dedicated nonce N_C generated by the Client. This parameter MUST be present.
* 'cnonce'：CBORバイト文字列としてエンコードされており、その値はクライアントによって生成された専用のNONCE N_Cです。このパラメーターが存在する必要があります。
* 'client_cred_verify': encoded as a CBOR byte string. This parameter MUST be present if the 'client_cred' parameter is present and no authentication credential associated with the Client's access token can be retrieved for that group.
* 'client_cred_verify'：cborバイト文字列としてエンコードされています。「client_cred」パラメーターが存在し、クライアントのアクセストークンに関連付けられた認証資格情報をそのグループに対して取得できない場合、このパラメーターを存在する必要があります。
The value of the CBOR byte string is the proof-of-possession (PoP) evidence computed by the Client over the following PoP input: the scope (encoded as a CBOR byte string) concatenated with N_S (encoded as a CBOR byte string) concatenated with N_C (encoded as a CBOR byte string), where:
CBORバイト文字列の値は、次のPOP入力でクライアントによって計算されたプルーフポッセッション（POP）の証拠です。N_S（CBORバイト文字列としてエンコード）に合わせたスコープ（CBORバイト文字列としてエンコード）n_c（cborバイト文字列としてエンコード）で、ここで：
- scope is either specified in the 'scope' parameter above, if present, or a default scope entry that the handler is expected to know otherwise;
- スコープは、存在する場合は上記の「スコープ」パラメーターで指定されているか、ハンドラーが別の方法で知っていると予想されるデフォルトのスコープエントリで指定されています。
- N_S is the challenge received from the KDC in the 'kdcchallenge' parameter of the 2.01 (Created) response to the Token Transfer Request (see Section 3.3), encoded as a CBOR byte string; and
- N_Sは、CBORバイト文字列としてエンコードされたトークン転送要求（セクション3.3を参照）に対する2.01（作成）応答の「KDCChallenge」パラメーターのKDCから受け取った課題です。そして
- N_C is the nonce generated by the Client and specified in the 'cnonce' parameter above, encoded as a CBOR byte string.
- N_Cは、クライアントによって生成され、上記の「cnonce」パラメーターで指定された非CEであり、CBORバイト文字列としてエンコードされています。
An example of PoP input to compute 'client_cred_verify' using CBOR encoding is given in Figure 10.
CBORエンコードを使用して「client_cred_verify」を計算するポップ入力の例を図10に示します。
A possible type of PoP evidence is a signature that the Client computes by using its own private key, whose corresponding public key is specified in the authentication credential carried in the 'client_cred' parameter. Application profiles of this specification MUST specify the exact approaches used to compute the PoP evidence to include in 'client_cred_verify' and MUST specify which of those approaches is used in which case (REQ14).
可能なタイプのポップエビデンスは、クライアントが「client_cred」パラメーターに掲載された認証資格情報で対応する公開キーが指定されている独自の秘密鍵を使用して計算する署名です。この仕様のアプリケーションプロファイルは、「client_cred_verify」に含まれるポップエビデンスを計算するために使用される正確なアプローチを指定し、その場合にどのアプローチが使用されているかを指定する必要があります（req14）。
If the access token was not provided to the KDC through a Token Transfer Request (e.g., the access token is instead transferred during the establishment of a secure communication association), it is REQUIRED of the specific application profile to define how the challenge N_S is generated (REQ15).
アクセストークンがトークン転送要求を介してKDCに提供されなかった場合（たとえば、アクセストークンは代わりに安全な通信協会の確立中に転送されます）、チャレンジN_Sの生成方法を定義するために特定のアプリケーションプロファイルに必要です（req15）。
* 'creds_repo': it can be present if the format of the Client's authentication credential conveyed in the 'client_cred' parameter is a certificate. In such a case, this parameter has as its value the URI of the certificate. This parameter is encoded as a CBOR text string. Alternative specific encodings of this parameter MAY be defined in application profiles of this specification (OPT6).
* 'creds_repo'：「client_cred」パラメーターで伝えられるクライアントの認証資格情報の形式が証明書である場合、存在する可能性があります。そのような場合、このパラメーターには証明書のURI値があります。このパラメーターは、CBORテキスト文字列としてエンコードされています。このパラメーターの代替固有のエンコーディングは、この仕様（OPT6）のアプリケーションプロファイルで定義できます。
* 'control_uri': its value is a full URI, encoded as a CBOR text string. A default url-path is /ace-group/GROUPNAME/node, although implementations can use different ones instead. The URI MUST NOT have url-path /ace-group/GROUPNAME.
* 'Control_uri'：その値は完全なURIで、CBORテキスト文字列としてエンコードされています。デフォルトのurl-pathは/ace-group/groupName/ノードですが、実装は代わりに異なるものを使用できます。URIには、url-path /ace-group /groupNameが必要です。
If 'control_uri' is specified in the Join Request, the Client acts as a CoAP server and hosts a resource at this specific URI. The KDC MAY use this URI to send CoAP requests to the Client (acting as a CoAP server in this exchange), for example, for one-to-one provisioning of new group keying material when performing a group rekeying (see Section 6.1) or to inform the Client of its removal from the group (see Section 5).
「control_uri」がJoin Requestで指定されている場合、クライアントはCoAPサーバーとして機能し、この特定のURIでリソースをホストします。KDCは、このURIを使用してクライアントにCOAPリクエストを送信することができます（この交換でCOAPサーバーとして機能する）、たとえば、グループの再キーイング（セクション6.1を参照）またはグループを実行するときの新しいグループキーイング素材の1対1のプロビジョニング（セクション6.1を参照）またはクライアントにグループからの削除を通知するため（セクション5を参照）。
In particular, this resource is intended for communications exclusively concerning the group identified by GROUPNAME and whose group name is specified in the 'scope' parameter of the Join Request, if present therein. If the KDC does not implement mechanisms using this resource for that group, it can ignore this parameter. Other additional functionalities of this resource MAY be defined in application profiles of this specifications (OPT7).
特に、このリソースは、GroupNameで識別されたグループのみに関する通信を目的としており、そのグループ名は、存在する場合、Join Requestの「スコープ」パラメーターで指定されています。KDCがこのグループにこのリソースを使用してメカニズムを実装していない場合、このパラメーターを無視できます。このリソースの他の追加機能は、この仕様のアプリケーションプロファイル（OPT7）で定義できます。
scope, N_S, and N_C expressed in CBOR diagnostic notation:
scope = h'826667726f7570316673656e646572'
N_S = h'018a278f7faab55a'
N_C = h'25a8991cd700ac01'
scope, N_S, and N_C as CBOR encoded byte strings:
scope = 0x4f826667726f7570316673656e646572
N_S = 0x48018a278f7faab55a
N_C = 0x4825a8991cd700ac01
PoP input:
0x4f 826667726f7570316673656e646572
48 018a278f7faab55a 48 25a8991cd700ac01
Figure 10: Example of PoP Input to Compute 'client_cred_verify' Using CBOR Encoding
図10：cborエンコーディングを使用して「client_cred_verify」を計算するポップ入力の例
If the request does not include the 'scope' parameter, the KDC is expected to understand what roles the Client is requesting to join the group with. For example, as per the access token, the Client might have been granted access to the group with only one role. If the KDC cannot determine which exact roles should be considered for the Client, it MUST reply with a 4.00 (Bad Request) error response.
要求に「スコープ」パラメーターが含まれていない場合、KDCはクライアントがグループに参加することを要求している役割を理解することが期待されます。たとえば、アクセストークンによると、クライアントは1つの役割しかないグループへのアクセスを許可されている可能性があります。KDCがクライアントの正確な役割を検討する必要がある場合、4.00（悪い要求）エラー応答で返信する必要があります。
The handler considers the scope specified in the access token associated with the Client and checks the scope entry related to the group identified by the GROUPNAME associated with the endpoint. In particular, the handler checks whether the set of roles specified in that scope entry includes all the roles that the Client wishes to have in the group as per the Join Request. If this is not the case, the KDC MUST reply with a 4.03 (Forbidden) error response.
ハンドラーは、クライアントに関連付けられたアクセストークンで指定されたスコープを考慮し、エンドポイントに関連付けられたグループ名で識別されたグループに関連するスコープエントリをチェックします。特に、ハンドラーは、そのスコープエントリで指定された役割のセットに、クライアントが参加要求に応じてグループに希望するすべての役割が含まれているかどうかをチェックします。そうでない場合、KDCは4.03（禁止）エラー応答で返信する必要があります。
If the KDC manages the group members' authentication credentials, the handler checks if one is included in the 'client_cred' parameter. If so, the KDC retrieves the authentication credential and performs the following actions.
KDCがグループメンバーの認証資格情報を管理する場合、ハンドラーは「client_cred」パラメーターに含まれているかどうかを確認します。その場合、KDCは認証資格情報を取得し、次のアクションを実行します。
* If the access token was provided through a Token Transfer Request (see Section 3.3) but the KDC cannot retrieve the 'kdcchallenge' associated with this Client (see Section 3.3), the KDC MUST reply with a 4.00 (Bad Request) error response, which MUST also have Content-Format "application/ace-groupcomm+cbor". The payload of the error response is a CBOR map including a newly generated 'kdcchallenge' value, which is specified in the 'kdcchallenge' parameter. The KDC MUST store the newly generated value as the 'kdcchallenge' value associated with this Client, replacing the currently stored value (if any).
* アクセストークンがトークン転送要求を介して提供されたが、KDCはこのクライアントに関連付けられた「KDCChallenge」を取得できない場合（セクション3.3を参照）、KDCは4.00（悪い要求）エラー応答で返信する必要があります。また、コンテンツフォーマット「Application/Ace-GroupComm+Cbor」も必要です。エラー応答のペイロードは、「kdcchallenge」パラメーターで指定されている新しく生成された「kdcchallenge」値を含むcborマップです。KDCは、新しく生成された値を、このクライアントに関連付けられた「kdcchallenge」値として保存する必要があり、現在保存されている値（ある場合）を置き換えます。
* The KDC checks the authentication credential to be valid for the group identified by GROUPNAME. That is, it checks that the authentication credential has the format used in the group, is intended for the public key algorithm used in the group, and is aligned with the possible associated parameters used in the group.
* KDCは、GroupNameで識別されたグループに対して有効であることを認証資格情報をチェックします。つまり、認証資格情報がグループで使用される形式を持っていること、グループで使用される公開キーアルゴリズムを対象としており、グループで使用される可能性のある関連パラメーターと一致していることを確認します。
If this verification fails, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 2 ("Authentication credential incompatible with the group configuration").
この検証が失敗した場合、ハンドラーは4.00（悪い要求）エラー応答で返信する必要があります。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は2に設定する必要があります（「グループ構成と互換性のない認証資格情報」）。
* The KDC verifies the PoP evidence conveyed in the 'client_cred_verify' parameter. Application profiles of this specification MUST specify the exact approaches used to verify the PoP evidence and MUST specify which of those approaches is used in which case (REQ14).
* KDCは、「client_cred_verify」パラメーターで伝えられるポップエビデンスを検証します。この仕様のアプリケーションプロファイルは、ポップエビデンスを検証するために使用される正確なアプローチを指定し、どのアプローチが使用されているかを指定する必要があります（Req14）。
If the PoP evidence does not pass verification, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 3 ("Invalid proof-of-possession evidence").
ポップエビデンスが検証に合格しない場合、ハンドラーは4.00（悪い要求）エラー応答で返信する必要があります。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は3に設定する必要があります（「無効な入場証明証拠」）。
If no authentication credential is conveyed in the 'client_cred' parameter, the handler checks if the KDC currently stores an authentication credential that is associated with the access token and with the group identified by GROUPNAME (see also Section 4.3.1.1). Note that the same joining node may use different authentication credentials in different groups, and all those authentication credentials would be associated with the same access token.
「client_creded」パラメーターに認証資格情報が伝えられていない場合、ハンドラーは、KDCが現在、アクセストークンとグループ名で識別されたグループに関連付けられている認証資格情報を保存しているかどうかを確認します（セクション4.3.1.1も参照）。同じ結合ノードは、異なるグループで異なる認証資格情報を使用する場合があり、これらすべての認証資格情報は同じアクセストークンに関連付けられていることに注意してください。
If an eligible authentication credential for the Client is neither present in the 'client_cred' parameter nor retrieved from the stored ones at the KDC, it is RECOMMENDED that the handler stops the processing and replies with a 4.00 (Bad Request) error response. Application profiles MAY define alternatives (OPT8).
クライアントの適格な認証資格が「client_cred」パラメーターに存在しない場合も、KDCの保存されたパラメーターから取得していない場合、ハンドラーが処理を停止し、4.00（悪い要求）エラー応答で返信することをお勧めします。アプリケーションプロファイルは、代替案（OPT8）を定義する場合があります。
If, regardless of the reason, the KDC replies with a 4.00 (Bad Request) error response, the payload of the response MAY be a CBOR map. For instance, the CBOR map can include a 'sign_info' parameter formatted as 'sign_info_resp' defined in Section 3.3.1, with the 'cred_fmt' element set to the CBOR simple value null (0xf6) if the Client sent its own authentication credential and the KDC is not set to store authentication credentials of the group members. When the response payload is a CBOR map including such parameters, the error response has Content-Format "application/ace-groupcomm+cbor".
理由に関係なく、KDCが4.00（悪い要求）エラー応答で応答した場合、応答のペイロードはCBORマップである可能性があります。たとえば、CBORマップには、セクション3.3.1で定義された「SIGN_INFO_RESP」としてフォーマットされた「SIGN_INFO」パラメーターを含めることができます。KDCは、グループメンバーの認証資格情報を保存するようには設定されていません。応答ペイロードがそのようなパラメーターを含むCBORマップである場合、エラー応答にはコンテンツフォーマット「Application/ACE-GroupComm+CBOR」があります。
If all the verifications above succeed, the KDC proceeds as follows.
上記のすべての検証が成功した場合、KDCは次のように進行します。
First, only in case the Client is not already a group member, the handler performs the following actions:
まず、クライアントがまだグループメンバーでない場合にのみ、ハンドラーは次のアクションを実行します。
* The handler adds the Client to the list of current members of the group.
* ハンドラーは、クライアントをグループの現在のメンバーのリストに追加します。
* The handler assigns a name NODENAME to the Client and creates a sub-resource to /ace-group/GROUPNAME at the KDC, i.e., /ace-group/GROUPNAME/nodes/NODENAME.
* ハンドラーはクライアントに名前nodenameを割り当て、KDC、つまり/ace-group/groupName/nodes/nodenameで/ace-group/groupNameにサブリソースを作成します。
* The handler associates the node identifier NODENAME with the access token and the secure communication association for the Client.
* ハンドラーは、ノード識別子ノデナムをアクセストークンとクライアントの安全な通信協会に関連付けます。
Then, the handler performs the following actions.
次に、ハンドラーは次のアクションを実行します。
* If the KDC manages the group members' authentication credentials:
* KDCがグループメンバーの認証資格情報を管理する場合：
- The handler associates the retrieved Client's authentication credential with the tuple composed of the node name NODENAME, the group name GROUPNAME, and the access token.
- ハンドラーは、取得したクライアントの認証資格情報を、ノード名nodename、グループ名グループ名、およびアクセストークンで構成されるタプルと関連付けます。
- The handler adds the retrieved Client's authentication credential to the list of authentication credentials stored for the group identified by GROUPNAME. If such a list already includes an authentication credential for the Client, but a different authentication credential is specified in the 'client_cred' parameter, then the handler MUST replace the old authentication credential in the list with the one specified in the 'client_cred' parameter.
- ハンドラーは、GroupNameによって識別されたグループに保存されている認証資格情報のリストに、取得したクライアントの認証資格情報を追加します。このようなリストには、クライアントの認証資格情報が既に含まれているが、「client_cred」パラメーターで異なる認証資格情報が指定されている場合、ハンドラーはリストの古い認証資格情報を「client_creded」パラメーターで指定したものに置き換える必要があります。
* If backward security is prescribed by application policies installed at the KDC or by the used application profile of this specification, then the KDC MUST generate new group keying material and securely distribute it to the current group members (see Section 6).
* BackwardセキュリティがKDCにインストールされたアプリケーションポリシーまたはこの仕様の使用済みアプリケーションプロファイルによって規定されている場合、KDCは新しいグループキーイングマテリアルを生成し、現在のグループメンバーに安全に配布する必要があります（セクション6を参照）。
* The handler returns a successful Join Response, as defined below, which contains the symmetric group keying material, the group policies, and the authentication credentials of the current members of the group if the KDC manages those and the Client requested those.
* ハンドラーは、以下に定義するように、成功した結合応答を返します。これには、KDCがそれらを管理し、クライアントがそれらを要求した場合、対称グループキーイングマテリアル、グループのポリシー、および現在のメンバーの認証資格情報を含む。
The Join Response MUST have response code 2.01 (Created) if the Client has been added to the list of group members in this join exchange (see above) or 2.04 (Changed) otherwise, i.e., if the Client is rejoining the group without having left it.
結合応答には、クライアントがこの参加交換（上記を参照）または2.04（変更）のグループメンバーのリストにクライアントが追加された場合、つまりクライアントが去らずにグループに再加入している場合、クライアントがクライアントがグループメンバーのリストに追加された場合、応答コード2.01（作成）が必要です。それ。
The Join Response message MUST include the Location-Path CoAP Options, specifying the path to the sub-resource associated with the Client, i.e., /ace-group/GROUPNAME/nodes/NODENAME.
結合応答メッセージには、クライアントに関連付けられているサブリソースへのパス、つまり/ace-group/groupName/nodes/nodenameを指定して、ロケーションパスコップオプションを含める必要があります。
The Join Response message MUST have Content-Format "application/ace-groupcomm+cbor". The payload of the response is formatted as a CBOR map, which MUST contain the following fields with the values specified below:
Join Responseメッセージには、コンテンツフォーマット「Application/Ace-GroupComm+Cbor」が必要です。応答のペイロードはCBORマップとしてフォーマットされます。これには、以下に指定された値がある次のフィールドを含める必要があります。
* 'gkty': identifying the key type of the keying material specified in the 'key' parameter. This parameter is encoded as a CBOR integer or a CBOR text string. Possible values are taken from the "Key Type Value" column of the "ACE Groupcomm Key Types" registry defined in Section 11.8 of this specification. Implementations MUST verify that the key type specified by this parameter matches the application profile being used and, if applicable, that such an application profile is listed in the "Profile" column of the "ACE Groupcomm Key Types" registry for the key type in question.
* 「Gkty」：「キー」パラメーターで指定されたキーイング素材のキータイプを識別します。このパラメーターは、CBOR整数またはCBORテキスト文字列としてエンコードされています。可能な値は、この仕様のセクション11.8で定義されている「ACE GroupCommキータイプ」レジストリの「キータイプ値」列から取得されます。実装は、このパラメーターで指定されたキータイプが使用されているアプリケーションプロファイルと一致し、該当する場合、そのようなアプリケーションプロファイルが問題のキータイプの「ACE GroupCommキータイプ」レジストリの「プロファイル」列にリストされていることを確認する必要があります。。
* 'key': containing the keying material used for securing the group communication or information required to derive such keying material.
* 「キー」：グループのコミュニケーションまたはそのようなキーイング材料の導出に必要な情報を確保するために使用されるキーイング素材を含む。
* 'num': containing the current version number of the group keying material, encoded as a CBOR integer. The version number has a value that increases in a strictly monotonic way as the group keying material changes. The application profile MUST define the initial value of the version number (REQ16).
* 'num'：cbor整数としてエンコードされたグループキーイング素材の現在のバージョン番号を含む。バージョン番号には、グループキーイングマテリアルが変化するにつれて、厳密に単調な方法で増加する値があります。アプリケーションプロファイルは、バージョン番号（REQ16）の初期値を定義する必要があります。
The format of the keying material conveyed in the 'key' parameter MUST be defined in application profiles of this specification (REQ17), together with corresponding key types to specify as value of the 'gkty' parameter and that are accepted by the application (REQ18). Additionally, documents specifying a type of keying material MUST register an entry in the "ACE Groupcomm Key Types" registry defined in Section 11.8, including its name, the corresponding key type to specify as value for the 'gkty' parameter, and the application profile to be used with.
「キー」パラメーターで伝えられるキーイング材料の形式は、この仕様のアプリケーションプロファイル（REQ17）と、「GKTY」パラメーターの値として指定し、アプリケーションで受け入れられる（REQ18）の適用キータイプで定義する必要があります。）。さらに、キーイン素材の種類を指定するドキュメントは、名前を含むセクション11.8で定義されている「ACE GroupCommキータイプ」レジストリ、「GKTY」パラメーターの値として指定する対応するキータイプ、およびアプリケーションプロファイルにエントリを登録する必要があります。で使用する。
+==========+================+=========+=============+===========+
| Name | Key Type Value | Profile | Description | Reference |
+==========+================+=========+=============+===========+
| Reserved | 0 | | This value | RFC 9594 |
| | | | is reserved | |
+----------+----------------+---------+-------------+-----------+
Table 1: ACE Groupcomm Key Types
表1：ACE GroupCommキータイプ
The Join Response SHOULD contain the following fields with the values specified below:
結合応答には、以下に指定された値を持つ次のフィールドを含める必要があります。
* 'exp': its value specifies the expiration time of the group keying material specified in the 'key' parameter, encoded as a CBOR unsigned integer. The value is the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what is specified for NumericDate in Section 2 of [RFC7519]. After the time indicated in this parameter, group members MUST NOT use the group keying material specified in the 'key' parameter. The group members can retrieve the latest group keying material from the KDC.
* 'exp'：その値は、cbor unsigned Integerとしてエンコードされた「キー」パラメーターで指定されたグループキーイング素材の有効期限を指定します。値は、1970-01-01T00：00：00：00Z UTCから指定されたUTCの日付/時刻まで、[RFC7519]のセクション2の数値で指定されているものに類似している瞬間を無視する秒数です。このパラメーターに示された時間の後、グループメンバーは「キー」パラメーターで指定されたグループキーイング素材を使用してはなりません。グループメンバーは、KDCから最新のグループキーイングマテリアルを取得できます。
* 'exi': its value specifies the residual lifetime of the group keying material, encoded as a CBOR unsigned integer. If the 'exp' parameter is included, this parameter MUST also be included. The value represents the residual lifetime of the group keying material specified in the 'key' parameter, i.e., it is the number of seconds between the current time at the KDC and the time when the keying material expires (as specified in the 'exp' parameter, if present). A Client determines the expiration time of the keying material by adding the seconds specified in the 'exi' parameter to its current time upon receiving the Join Response containing the 'exi' parameter. After such an expiration time, the Client MUST NOT use the group keying material specified in the 'key' parameter. The Client can retrieve the latest group keying material from the KDC.
* 'exi'：その値は、CBORの署名整数としてエンコードされたグループキーイング素材の残留寿命を指定します。「Exp」パラメーターが含まれている場合、このパラメーターも含める必要があります。値は、「キー」パラメーターで指定されたグループキーイング素材の残留寿命を表します。つまり、KDCでの現在の時期とキーイング材料の有効期限が切れる（「EXP」で指定されている時の間の秒数」を表します。パラメーター、存在する場合）。クライアントは、「exi」パラメーターを含む結合応答を受信すると、「exi」パラメーターで指定された秒を現在の時刻に追加することにより、キーイング材料の有効期限を決定します。このような有効期限の後、クライアントは「キー」パラメーターで指定されたグループキーイング素材を使用してはなりません。クライアントは、KDCから最新のグループキーイング素材を取得できます。
If a Client has a reliable way to synchronize its internal clock with UTC, and both the 'exp' and 'exi' parameters are present, then the Client MUST use the 'exp' parameter value as expiration time for the group keying material. Otherwise, the Client uses the 'exi' parameter value to determine the expiration time as defined above.
クライアントがUTCと内部クロックを同期する信頼できる方法を持っている場合、および「EXP」パラメーターと「EXI」パラメーターの両方が存在する場合、クライアントはグループキーイングの材料の有効期限として「EXP」パラメーター値を使用する必要があります。それ以外の場合、クライアントは「exi」パラメーター値を使用して、上記で定義されている有効期限を決定します。
When a Client relies on the 'exi' parameter, the expiration time that it computes is offset in the future with respect to the actual expiration time as intended by the KDC and specified in the 'exp' parameter (if present). Such an offset is the amount of time between when the KDC sends the response message including the 'exi' parameter and when the Client receives that message. That is, especially if the delivery of the response to the Client is delayed, the Client will believe the keying material to be valid for a longer time than the KDC actually means. However, before approaching the actual expiration time, the KDC is expected to rekey the group and distribute new keying material (see Section 6).
クライアントが「exi」パラメーターに依存する場合、KDCが意図し、「exp」パラメーターで指定されている実際の有効期限に関して、計算する有効期限は将来オフセットされます（存在する場合）。このようなオフセットとは、KDCが「exi」パラメーターを含む応答メッセージを送信する場合と、クライアントがそのメッセージを受信するまでの間の時間です。つまり、特にクライアントへの応答の配信が遅れている場合、クライアントは、KDCが実際に意味するよりも長い時間にわたってキーイング素材が有効であると信じるでしょう。ただし、実際の有効期限に近づく前に、KDCはグループを再キーし、新しいキーイング素材を配布することが期待されています（セクション6を参照）。
Optionally, the Join Response MAY contain the following parameters, which, if included, MUST have the format and value as specified below.
オプションで、結合応答には次のパラメーターが含まれている場合があります。これには、以下に指定された形式と値が必要です。
* 'ace_groupcomm_profile': its value is encoded as a CBOR integer and MUST be used to uniquely identify the application profile for group communication. Applications of this specification MUST register an application profile identifier and the related value for this parameter in the "ACE Groupcomm Profiles" registry (REQ19).
* 'ace_groupcomm_profile'：その値はcbor整数としてエンコードされており、グループ通信のアプリケーションプロファイルを一意に識別するために使用する必要があります。この仕様のアプリケーションは、「ACE GroupCommプロファイル」レジストリ（REQ19）にアプリケーションプロファイル識別子とこのパラメーターの関連値を登録する必要があります。
+==========+========================+============+===========+
| Name | Description | CBOR Value | Reference |
+==========+========================+============+===========+
| Reserved | This value is reserved | 0 | RFC 9594 |
+----------+------------------------+------------+-----------+
Table 2: ACE Groupcomm Profiles
表2：ACE GroupCommプロファイル
* 'creds': it MUST be present if 'get_creds' was present in the Join Request; otherwise, it MUST NOT be present. Its value is encoded as a CBOR array specifying the authentication credentials of the group members, i.e., of all of them or of the ones selected according to the 'get_creds' parameter in the Join Request. In particular, each element of the array is a CBOR byte string, whose value is the original binary representation of a group member's authentication credential. It is REQUIRED for application profiles to define the specific formats of authentication credentials that are acceptable to use in the group (REQ6).
* 'creds'：Join Requestに「get_creds」が存在した場合は存在する必要があります。そうでなければ、存在してはなりません。その値は、グループメンバーの認証資格情報、つまりそれらすべての認証資格情報、または参加リクエストの「get_creds」パラメーターに従って選択されたCBORアレイとしてエンコードされています。特に、配列の各要素はCBORバイト文字列であり、その値はグループメンバーの認証資格情報の元のバイナリ表現です。アプリケーションプロファイルには、グループで使用できる特定の形式の認証資格情報を定義する必要があります（REQ6）。
* 'peer_roles': it SHOULD be present if 'creds' is also present; otherwise, it MUST NOT be present. Its value is encoded as a CBOR array of n elements, where n is the number of authentication credentials included in the 'creds' parameter (at most, the number of members in the group). The i-th element of the array specifies the role(s) that the group member associated with the i-th authentication credential in 'creds' has in the group. In particular, each array element is encoded like the role element of a scope entry, which is consistent with the used format (see Section 3.1).
* 「PEER_ROLES」：「信用」も存在する場合は存在する必要があります。そうでなければ、存在してはなりません。その値は、N要素のCBORアレイとしてエンコードされます。ここで、nは「CRED」パラメーターに含まれる認証資格情報の数（せいぜい、グループ内のメンバーの数）です。アレイのi番目の要素は、グループ内のI番目の認証資格情報に関連付けられているグループメンバーがグループ内に持っている役割を指定します。特に、各配列要素は、スコープエントリの役割要素のようにエンコードされており、使用された形式と一致しています（セクション3.1を参照）。
This parameter MAY be omitted if the Client can rely on other means to unambiguously gain knowledge of the role of each group member whose associated authentication credential is specified in the 'creds' parameter. For example, all such group members may have the same role in the group joined by the Client, and such a role can be unambiguously assumed by the Client (e.g., based on what is defined in the used application profile of this specification). As another example, each of the authentication credentials specified in the 'creds' parameter can indicate the role(s) that the corresponding group member has in the group joined by the Client.
クライアントが他の手段に依存して、関連する認証資格情報が「クレジット」パラメーターで指定されている各グループメンバーの役割に関する知識を明確に得ることができる場合、このパラメーターが省略される場合があります。たとえば、そのようなグループメンバーはすべて、クライアントが結合したグループで同じ役割を果たしている可能性があり、そのような役割は、クライアントによって明確に想定される可能性があります（例えば、この仕様の使用されるアプリケーションプロファイルで定義されているものに基づいて）。別の例として、「CREDS」パラメーターで指定されている認証資格情報のそれぞれは、クライアントが参加するグループに対応するグループメンバーが持っている役割を示すことができます。
When receiving the authentication credential of a Client in the 'client_cred' parameter of a Join Request (see Section 4.3.1.1) or of an Authentication Credential Update Request (see Section 4.9.1.1), the KDC is not expected to check that the authentication credential indicates the role(s) that the Client can have or has in the group in question. When preparing a Join Response, the KDC can decide whether to include the 'peer_roles' parameter, depending on the specific set of authentication credentials specified in the 'creds' parameter of that Join Response.
参加要求（セクション4.3.1.1を参照）または認証資格更新リクエスト（セクション4.9.1.1を参照）の「client_creded」パラメーターでクライアントの認証資格を受信する場合、KDCは認証を確認することは期待されていません資格情報は、問題のグループにクライアントが持つことができる、または持つことができる役割を示します。結合応答を準備するとき、KDCは、その結合応答の「クレジ」パラメーターで指定された特定の認証資格情報のセットに応じて、「PEER_ROLES」パラメーターを含めるかどうかを決定できます。
* 'peer_identifiers': it MUST be present if 'creds' is also present; otherwise, it MUST NOT be present. Its value is encoded as a CBOR array of n elements, where n is the number of authentication credentials included in the 'creds' parameter (at most, the number of members in the group). The i-th element of the array specifies the node identifier that the group member associated with the i-th authentication credential in 'creds' has in the group. In particular, the i-th array element is encoded as a CBOR byte string, whose value is the node identifier of the group member. The specific format of node identifiers of group members is specified by the application profile (REQ25).
* 「Peer_identifiers」：「クレジット」も存在する場合は存在する必要があります。そうでなければ、存在してはなりません。その値は、N要素のCBORアレイとしてエンコードされます。ここで、nは「CRED」パラメーターに含まれる認証資格情報の数（せいぜい、グループ内のメンバーの数）です。配列のi番目の要素は、グループ内のI番目の認証資格情報に関連付けられているグループメンバーがグループ内に持っているノード識別子を指定します。特に、i番目の配列要素は、グループメンバーのノード識別子であるCborバイト文字列としてエンコードされます。グループメンバーのノード識別子の特定の形式は、アプリケーションプロファイル（REQ25）によって指定されています。
* 'group_policies': its value is encoded as a CBOR map, whose elements specify how the group handles specific management aspects. These include, for instance, approaches to achieve synchronization of sequence numbers among group members. The possible elements of the CBOR map are registered in the "ACE Groupcomm Policies" registry defined in Section 11.10 of this specification. This specification defines the three elements "Sequence Number Synchronization Methods", "Key Update Check Interval", and "Expiration Delta", which are summarized in Table 3. Application profiles of this specification MUST specify the format and default values for the entries of the CBOR map conveyed in the 'group_policies' parameter (REQ20).
* 'Group_Policies'：その値はCBORマップとしてエンコードされ、その要素はグループが特定の管理の側面を処理する方法を指定します。これらには、たとえば、グループメンバー間のシーケンス番号の同期を実現するためのアプローチが含まれます。CBORマップの可能な要素は、この仕様のセクション11.10で定義されている「ACE GroupCommポリシー」レジストリに登録されています。この仕様では、表3に要約されている3つの要素「シーケンス番号同期メソッド」、「キーアップデートチェックインターバル」、および「有効期限デルタ」を定義します。cborマップは、「group_policies」パラメーター（req20）で伝えられます。
+=================+=======+======+===================+===========+
| Name | CBOR | CBOR | Description | Reference |
| | Label | Type | | |
+=================+=======+======+===================+===========+
| Sequence Number | 0 | int | Method for | RFC 9594 |
| Synchronization | | or | recipient group | |
| Method | | tstr | members to | |
| | | | synchronize with | |
| | | | sequence numbers | |
| | | | of sender group | |
| | | | members. Its | |
| | | | value is taken | |
| | | | from the "Value" | |
| | | | column of the | |
| | | | "Sequence Number | |
| | | | Synchronization | |
| | | | Method" | |
| | | | registry. | |
+-----------------+-------+------+-------------------+-----------+
| Key Update | 1 | int | Polling interval | RFC 9594 |
| Check Interval | | | in seconds, for | |
| | | | group members to | |
| | | | check at the KDC | |
| | | | if the latest | |
| | | | group keying | |
| | | | material is the | |
| | | | one that they | |
| | | | store. | |
+-----------------+-------+------+-------------------+-----------+
| Expiration | 2 | uint | Number of | RFC 9594 |
| Delta | | | seconds from | |
| | | | 'exp' until a | |
| | | | UTC date/time, | |
| | | | after which | |
| | | | group members | |
| | | | MUST stop using | |
| | | | the group keying | |
| | | | material that | |
| | | | they store to | |
| | | | decrypt incoming | |
| | | | messages. | |
+-----------------+-------+------+-------------------+-----------+
Table 3: ACE Groupcomm Policies
表3：ACE GroupCommポリシー
* 'kdc_cred': its value is the original binary representation of the KDC's authentication credential, encoded as a CBOR byte string. This parameter is used if the KDC has an associated authentication credential and this is required for the correct group operation. It is REQUIRED for application profiles to define whether the KDC has an authentication credential as required for the correct group operation and if this has to be provided through the 'kdc_cred' parameter (REQ8).
* 'KDC_CRED'：その値は、CBORバイト文字列としてエンコードされたKDCの認証資格情報の元のバイナリ表現です。このパラメーターは、KDCに関連する認証資格情報がある場合に使用され、これは正しいグループ操作に必要です。アプリケーションプロファイルには、正しいグループ操作に必要な認証資格情報があるかどうか、およびこれを「KDC_CRED」パラメーター（REQ8）で提供する必要があるかどうかを定義することが必要です。
If the KDC has an authentication credential as required for the correct group operation, the KDC's authentication credential MUST have the same format used for the authentication credentials of the group members. It is REQUIRED for application profiles to define the specific formats that are acceptable to use for the authentication credentials in the group (REQ6).
KDCに正しいグループ操作に必要な認証資格情報がある場合、KDCの認証資格情報は、グループメンバーの認証資格情報に同じ形式を使用する必要があります。アプリケーションプロファイルには、グループ（REQ6）の認証資格情報に使用できる特定の形式を定義するために必要です。
* 'kdc_nonce': its value is a dedicated nonce N_KDC generated by the KDC, encoded as a CBOR byte string. This parameter MUST be present if the 'kdc_cred' parameter is present.
* 'kdc_nonce'：その値は、kborバイト文字列としてエンコードされたKDCによって生成された専用のnonce n_kdcです。「KDC_CRED」パラメーターが存在する場合、このパラメーターを存在する必要があります。
* 'kdc_cred_verify': its value is as defined below and is encoded as a CBOR byte string. This parameter MUST be present if the 'kdc_cred' parameter is present.
* 'kdc_cred_verify'：その値は以下に定義されており、cborバイト文字列としてエンコードされています。「KDC_CRED」パラメーターが存在する場合、このパラメーターを存在する必要があります。
The value of this parameter is the proof-of-possession (PoP) evidence computed by the KDC over the following PoP input: the nonce N_C (encoded as a CBOR byte string) concatenated with the nonce N_KDC (encoded as a CBOR byte string), where:
このパラメーターの値は、次のPOP入力でKDCによって計算されたプルーフポッセッション（POP）証拠です。NonCeN_KDC（CBORバイト文字列としてエンコードされた）に合わせたNonCE N_C（CBORバイト文字列としてエンコード）、 どこ：
- N_C is the nonce generated by the Client and specified in the 'cnonce' parameter of the Join Request.
- N_Cは、クライアントによって生成され、JOINリクエストの「CNONCE」パラメーターで指定されているNONCEです。
- N_KDC is the nonce generated by the KDC and specified in the 'kdc_nonce' parameter.
- N_KDCは、KDCによって生成され、「KDC_NONCE」パラメーターで指定されているNONCEです。
An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is given in Figure 11.
CBORエンコードを使用して「kdc_cred_verify」を計算するポップ入力の例を図11に示します。
A possible type of PoP evidence is a signature that the KDC computes by using its own private key, whose corresponding public key is specified in the authentication credential conveyed in the 'kdc_cred' parameter. Application profiles of this specification MUST specify the approaches used by the KDC to compute the PoP evidence to include in 'kdc_cred_verify' and MUST specify which of those approaches is used in which case (REQ21).
可能なタイプのポップエビデンスは、KDCが独自の秘密鍵を使用して計算する署名であり、その対応する公開キーは「KDC_CRED」パラメーターで伝えられる認証資格情報で指定されています。この仕様のアプリケーションプロファイルは、KDCが使用するアプローチを指定して、「kdc_cred_verify」に含まれるポップエビデンスを計算し、それらのアプローチのどれがその場合（req21）を使用するかを指定する必要があります。
* 'rekeying_scheme': identifying the rekeying scheme that the KDC uses to provide new group keying material to the group members. The value of this parameter is encoded as a CBOR integer and is taken from the "Value" column of the "ACE Groupcomm Rekeying Schemes" registry defined in Section 11.13 of this specification.
* 'Rekeying_scheme'：KDCが使用する再キーイングスキームを特定するために、グループメンバーに新しいグループキーイング資料を提供します。このパラメーターの値は、CBOR整数としてエンコードされ、この仕様のセクション11.13で定義されている「ACE GroupComm Rekeing Schemes」レジストリの「値」列から取得されます。
+=======+================+===========================+===========+
| Value | Name | Description | Reference |
+=======+================+===========================+===========+
| 0 | Point-to-Point | The KDC individually | RFC 9594 |
| | | targets each node to | |
| | | rekey, using the | |
| | | pairwise secure | |
| | | communication | |
| | | association with | |
| | | that node | |
+-------+----------------+---------------------------+-----------+
Table 4: ACE Groupcomm Rekeying Schemes
表4：ACE GroupComm Rekeing Schemes
Application profiles of this specification MAY define a default group rekeying scheme to refer to in case the 'rekeying_scheme' parameter is not included in the Join Response (OPT9).
この仕様のアプリケーションプロファイルでは、「Rekeying_scheme」パラメーターがJoin Response（opt9）に含まれていない場合に参照するデフォルトのグループRekeingスキームを定義する場合があります。
* 'mgt_key_material': encoded as a CBOR byte string and containing the specific administrative keying material that the joining node requires in order to participate in the group rekeying process performed by the KDC. This parameter MUST NOT be present if the 'rekeying_scheme' parameter is not present and the application profile does not specify a default group rekeying scheme to use in the group. Some simple rekeying schemes may not require specific administrative keying material to be provided, e.g., the basic "Point-to-Point" group rekeying scheme (see Section 6.1).
* 'mgt_key_material'：cborバイト文字列としてエンコードされ、結合ノードがKDCによって実行されるグループの再キーイングプロセスに参加するために必要な特定の管理キーイン素材を含む。「Rekeying_scheme」パラメーターが存在せず、アプリケーションプロファイルがグループで使用するデフォルトのグループRekeyingスキームを指定しない場合、このパラメーターを存在しないでください。いくつかの単純な再キーイングスキームでは、特定の管理キーイング資料を提供する必要がない場合があります。たとえば、基本的な「ポイントツーポイント」グループの再キーイングスキーム（セクション6.1を参照）。
In more advanced group rekeying schemes, the administrative keying material can be composed of multiple keys organized, for instance, into a logical tree hierarchy, whose root key is the only administrative key shared by all the group members. In such a case, each group member is exclusively associated with one leaf key in the hierarchy and stores only the administrative keys from the associated leaf key all the way up along the path to the root key. That is, different group members can be provided with a different subset of the overall administrative keying material.
より高度なグループの再キーイングスキームでは、管理キーイング資料は、たとえば、すべてのグループメンバーが共有するルートキーが唯一の管理キーである論理ツリー階層に編成された複数のキーで構成できます。そのような場合、各グループメンバーは、階層の1つのリーフキーにのみ関連付けられ、関連する葉のキーからの管理キーのみがルートキーまでのパスに沿って上昇します。つまり、さまざまなグループメンバーに、管理キーイング資料全体の異なるサブセットを提供できます。
It is expected from separate documents to define how the advanced group rekeying scheme, possibly indicated in the 'rekeying_scheme' parameter, is used by an application profile of this specification. This includes defining the format of the administrative keying material to specify in 'mgt_key_material' consistently with the group rekeying scheme and the application profile in question.
別々のドキュメントから、「Rekeying_scheme」パラメーターに示されている上級グループの再キーイングスキームが、この仕様のアプリケーションプロファイルによってどのように使用されるかを定義することが期待されています。これには、「mgt_key_material」で指定する管理キーイング資料の形式の定義が含まれます。
* 'control_group_uri': its value is a full URI, encoded as a CBOR text string. The URI MUST specify addressing information intended to reach all the members in the group. For example, this can be a multicast IP address, optionally together with a port number that, if omitted, defaults to 5683, i.e., the default port number for the "coap" URI scheme (see Section 6.1 of [RFC7252]). The URI MUST include GROUPNAME in the url-path. A default url-path is /ace-group/GROUPNAME, although implementations can use different ones instead. The URI MUST NOT have url-path /ace-group/GROUPNAME/nodes.
* 'control_group_uri'：その値は完全なURIで、CBORテキスト文字列としてエンコードされています。URIは、グループ内のすべてのメンバーにリーチすることを目的としたアドレス指定情報を指定する必要があります。たとえば、これはマルチキャストIPアドレスであり、オプションでは省略された場合、5683にデフォルトで、つまり「COAP」URIスキームのデフォルトのポート番号（[RFC7252]のセクション6.1を参照）になります。URIには、URL-PathにGroupNameを含める必要があります。デフォルトのurl-pathは /ace-group /groupNameですが、実装は代わりに異なるものを使用できます。URIには、url-path/ace-group/groupName/nodesが必要です。
If 'control_group_uri' is included in the Join Response, the Clients supporting this parameter act as CoAP servers, host a resource at this specific URI, and listen to the specified addressing information.
「control_group_uri」がJoin Responseに含まれている場合、このパラメーターをサポートするクライアントはCoapサーバーとして機能し、この特定のURIでリソースをホストし、指定されたアドレス指定情報を聞きます。
The KDC MAY use this URI to send one-to-many CoAP requests to the Client group members (acting as CoAP servers in this exchange), for example, for one-to-many provisioning of new group keying material when performing a group rekeying (see Section 6.2) or to inform the Clients of their removal from the group (see Section 5).
KDCは、このURIを使用して、クライアントグループメンバー（この交換ではCOAPサーバーとして機能する）に1対Many Coapリクエストを送信することができます。たとえば、グループを実行するときに新しいグループキーイング素材を1対多でプロビジョニングする場合、（セクション6.2を参照）またはクライアントにグループからの削除を通知します（セクション5を参照）。
In particular, this resource is intended for communications exclusively concerning the group identified by GROUPNAME and whose group name was specified in the 'scope' parameter of the Join Request, if present. If the KDC does not implement mechanisms using this resource for that group, it can ignore this parameter. Other additional functionalities of this resource MAY be defined in application profiles of this specifications (OPT10).
特に、このリソースは、GroupNameで識別されたグループのみに関する通信を目的としており、そのグループ名は、存在する場合、Join Requestの「スコープ」パラメーターで指定されています。KDCがこのグループにこのリソースを使用してメカニズムを実装していない場合、このパラメーターを無視できます。このリソースの他の追加機能は、この仕様のアプリケーションプロファイル（OPT10）で定義できます。
N_C and N_KDC expressed in CBOR diagnostic notation:
N_C = h'25a8991cd700ac01'
N_KDC = h'cef04b2aa791bc6d'
N_C and N_KDC as CBOR encoded byte strings:
N_C = 0x4825a8991cd700ac01
N_KDC = 0x48cef04b2aa791bc6d
PoP input:
0x48 25a8991cd700ac01 48 cef04b2aa791bc6d
Figure 11: Example of PoP Input to Compute 'kdc_cred_verify' Using CBOR Encoding
図11：cborエンコーディングを使用して「kdc_cred_verify」を計算するポップ入力の例
After sending the Join Response, if the KDC has an associated authentication credential as required for the correct group operation, then the KDC MUST store the N_C value specified in the 'cnonce' parameter of the Join Request as a 'clientchallenge' value associated with the Client, replacing the currently stored value (if any). If, as a group member, the Client later sends a GET request to the /ace-group/GROUPNAME/kdc-cred resource for retrieving the latest KDC's authentication credential (see Section 4.5.1), then the KDC uses the stored 'clientchallenge' for computing the PoP evidence to include in the response sent to the Client, hence proving the possession of its own private key.
Join Responseを送信した後、KDCが正しいグループ操作に必要な関連認証資格情報を持っている場合、KDCは、Join Requestの「CNONCE」パラメーターで指定されたN_C値を「クライアントチャレンジ」値として保存する必要があります。クライアント、現在保存されている値を置き換えます（ある場合）。グループメンバーとして、クライアントが後で最新のKDCの認証資格情報を取得するために/ace-group/groupName/KDC-CREDリソースにGETリクエストを送信した場合（セクション4.5.1を参照）、KDCは保存された 'ClientChallengeを使用します「クライアントに送信された応答に含めるポップエビデンスを計算するために、それゆえそれ自身の秘密鍵の所有を証明します。
If the Join Response includes the 'kdc_cred_verify' parameter, the Client verifies the conveyed PoP evidence and considers the group joining unsuccessful in case of failed verification. Application profiles of this specification MUST specify the exact approaches used by the Client to verify the PoP evidence in 'kdc_cred_verify' and MUST specify which of those approaches is used in which case (REQ21).
結合応答に「kdc_cred_verify」パラメーターが含まれている場合、クライアントは伝達されたポップエビデンスを検証し、検証に失敗した場合にグループが失敗したと考える。この仕様のアプリケーションプロファイルは、「kdc_cred_verify」のポップエビデンスを検証するためにクライアントが使用する正確なアプローチを指定し、それらのアプローチのどれがその場合（Req21）を使用するかを指定する必要があります。
Application profiles of this specification MUST specify the communication protocol that members of the group use to communicate with each other (REQ22) and the security protocol that they use to protect the group communication (REQ23).
この仕様のアプリケーションプロファイルは、グループのメンバーが互いに通信するために使用する通信プロトコル（REQ22）と、グループ通信を保護するために使用するセキュリティプロトコル（REQ23）を指定する必要があります。
Figure 12 gives an overview of the join exchange between the Client and the KDC when the Client first joins a group, while Figure 13 shows an example.
図12は、クライアントが最初にグループに参加したときにクライアントとKDCの結合交換の概要を示し、図13は例を示しています。
Client KDC
| |
|-------- Join Request: POST /ace-group/GROUPNAME ------>|
| |
|<------------ Join Response: 2.01 (Created) ----------- |
| Location-Path = "/ace-group/GROUPNAME/nodes/NODENAME" |
Figure 12: Message Flow of the Join Request-Response
図12：結合リクエスト応答のメッセージフロー
Request:
Header: POST (Code=0.02)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ scope / 3: <<["group1", ["sender", "receiver"]]>>,
/ get_creds / 4: [true, ["sender"], []],
/ client_cred / 5: h'a2026008a101a5010202410a20012158
20bbc34960526ea4d32e940cad2a2341
48ddc21791a12afbcbac93622046dd44
f02258204519e257236b2a0ce2023f09
31f1f386ca7afda64fcde0108c224c51
eabf6072',
/ cnonce / 6: h'25a8991cd700ac01',
/ client_cred_verify / 24: h'66e6d9b0db009f3e105a673f88556117
26caed57f530f8cae9d0b168513ab949
fedc3e80a96ebe94ba08d3f8d3bf8348
7458e2ab4c2f936ff78b50e33c885e35'
}
Response:
Header: Created (Code=2.01)
Content-Format: 261 (application/ace-groupcomm+cbor)
Location-Path: "ace-group"
Location-Path: "g1"
Location-Path: "nodes"
Location-Path: "c101"
Payload (in CBOR diagnostic notation):
{
/ gkty / 7: 65600,
/ key / 8: h'73657373696f6e6b6579',
/ num / 9: 12,
/ exp / 11: 1924992000,
/ exi / 12: 2592000,
/ creds / 13: [h'a2026008a101a5010202410220012158
20cd4177ba62433375ede279b5e18e8b
91bc3ed8f1e174474a26fc0edb44ea53
73225820a0391de29c5c5badda610d4e
301eaaa18422367722289cd18cbe6624
e89b9cfd',
h'a2026008a101a5010202410320012158
20ac75e9ece3e50bfc8ed60399889522
405c47bf16df96660a41298cb4307f7e
b62258206e5de611388a4b8a8211334a
c7d37ecb52a387d257e6db3c2a93df21
ff3affc8'],
/ peer_roles / 14: ["sender", ["sender", "receiver"]],
/ peer_identifiers / 15: [h'01', h'02']
}
Figure 13: Example of the First Join Request-Response for Group Joining
図13：グループに参加するための最初の結合リクエスト応答の例
If not previously established, the Client and the KDC MUST first establish a pairwise secure communication association (REQ24). This can be achieved, for instance, by using a transport profile of ACE. The join exchange MUST occur over that secure communication association. The Client and the KDC MAY use that same secure communication association to protect further pairwise communications that must be protected.
以前に確立されていない場合、クライアントとKDCは最初にペアワイズセキュア通信協会（REQ24）を確立する必要があります。これは、たとえば、ACEの輸送プロファイルを使用することにより、実現できます。結合交換は、その安全な通信協会で発生する必要があります。クライアントとKDCは、同じ安全な通信協会を使用して、保護する必要があるさらなるペアワイズ通信を保護することができます。
It is REQUIRED that the secure communication association between the Client and the KDC is established by using the proof-of-possession key bound to the access token. As a result, the proof of possession to bind the access token to the Client is performed by using the proof-of-possession key bound to the access token for establishing the pairwise secure communication association between the Client and the KDC.
クライアントとKDCの間の安全な通信関連は、アクセストークンにバインドされたプルーフオブポッセッションキーを使用して確立されることが必要です。その結果、アクセストークンをクライアントにバインドする所持の証明は、クライアントとKDCの間にペアワイズセキュアな通信関連を確立するために、アクセストークンにバインドされたプルーフオブポッセッションキーを使用して実行されます。
To join the group, the Client sends a CoAP POST request to the /ace-group/GROUPNAME endpoint at the KDC, where the group to join is identified by GROUPNAME. The group name is specified in the scope entry conveyed by the 'scope' parameter of the request (if present), formatted as specified in Section 4.3.1. This group name is the same as in the scope entry corresponding to that group, specified in the 'scope' parameter of the Authorization Request/Response, or it can be determined from it. Note that, in case of successful joining, the Location-Path Options in the Join Response provide the Client with the path of the URI to use for retrieving individual keying material and for leaving the group.
グループに参加するために、クライアントはKDCの /ace-group /groupNameエンドポイントにCOAP POSTリクエストを送信し、参加するグループがGroupNameで識別されます。グループ名は、セクション4.3.1で指定されているようにフォーマットされた要求の「スコープ」パラメーター（存在する場合）で伝えられるスコープエントリで指定されています。このグループ名は、承認要求/応答の「スコープ」パラメーターで指定されているそのグループに対応するスコープエントリと同じです。または、それから決定できます。参加が成功した場合、結合応答の位置パスオプションは、個々のキーイング素材を取得し、グループを去るために使用するURIのパスをクライアントに提供することに注意してください。
If the node is joining a group for the first time and the KDC maintains the authentication credentials of the group members, the Client is REQUIRED to send its own authentication credential and proof-of-possession (PoP) evidence in the Join Request (see the 'client_cred' and 'client_cred_verify' parameters in Section 4.3.1). The request is accepted only if both the authentication credential is provided and the PoP evidence is successfully verified.
ノードが初めてグループに参加し、KDCがグループメンバーの認証資格情報を維持している場合、クライアントは参加要求に独自の認証資格とプルーフオブポッセッション（POP）の証拠を送信する必要があります（セクション4.3.1の「client_cred」および「client_cred_verify」パラメーター）。リクエストは、認証資格情報が提供され、ポップエビデンスが正常に検証された場合にのみ受け入れられます。
If a node rejoins a group as authorized by the same access token and using the same authentication credential, it can omit the authentication credential and the PoP evidence, or just the PoP evidence, from the Join Request. Then, the KDC will be able to retrieve the node's authentication credential associated with the access token for that group. If the authentication credential has been discarded, the KDC replies with a 4.00 (Bad Request) error response, as specified in Section 4.3.1. If a node rejoins a group but wants to update its own authentication credential, it needs to include both its authentication credential and the PoP evidence in the Join Request, like when it joined the group for the first time.
ノードが同じアクセストークンで承認され、同じ認証資格情報を使用してグループに再加入すると、参加要求から認証資格情報とポップエビデンス、またはポップエビデンスのみを省略できます。次に、KDCは、そのグループのアクセストークンに関連付けられているノードの認証資格情報を取得できます。認証資格情報が破棄されている場合、KDCはセクション4.3.1で指定されているように、4.00（悪い要求）エラー応答で応答します。ノードがグループに再び参加しているが、独自の認証資格情報を更新したい場合は、グループに初めて参加したときなど、認証資格情報と参加要求にポップエビデンスの両方を含める必要があります。
The GET handler returns the symmetric group keying material for the group identified by GROUPNAME.
Get Handlerは、GroupNameで識別されたグループの対称グループキーイングマテリアルを返します。
The handler expects a GET request.
ハンドラーはGETリクエストを期待しています。
In addition to what is defined in Section 4.1.2, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format "application/ concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members").
セクション4.1.2で定義されているものに加えて、ハンドラーは、クライアントがグループの現在のメンバーであることを確認します。検証が失敗した場合、KDCは4.03（禁止）エラー応答で返信する必要があります。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は0に設定する必要があります（「グループメンバーのみに許可される操作」）。
If all verifications succeed, the handler replies with a 2.05 (Content) response containing the symmetric group keying material. The payload of the response is formatted as a CBOR map that MUST contain the parameters 'gkty', 'key', and 'num', as specified in Section 4.3.1.
すべての検証が成功した場合、ハンドラーは対称グループキーイング材料を含む2.05（コンテンツ）応答で応答します。応答のペイロードは、セクション4.3.1で指定されているように、パラメーター「GKTY」、「キー」、および「num」を含む必要があるCBORマップとしてフォーマットされます。
The payload MUST also include the parameters 'rekeying_scheme' and 'mgt_key_material' as specified in Section 4.3.1, if they are included in the payload of the Join Responses sent for the group.
ペイロードには、セクション4.3.1で指定されているパラメーター「Rekeying_scheme」と「MGT_Key_Material」も含める必要があります。
The payload MAY also include the parameters 'ace_groupcomm_profile', 'exp', and 'exi', as specified in Section 4.3.1. If the 'exp' parameter is included, the 'exi' parameter MUST also be included. If the 'exi' parameter is included, its value specifies the residual lifetime of the group keying material from the current time at the KDC.
ペイロードには、セクション4.3.1で指定されているように、パラメーター「ACE_GROUPCOMM_PROFILE」、「EXP」、および「EXI」も含まれます。「EXP」パラメーターが含まれている場合、「EXI」パラメーターも含める必要があります。「exi」パラメーターが含まれている場合、その値は、KDCでの現在のグループキーイングマテリアルの残留寿命を指定します。
A node in the group can contact the KDC to retrieve the current group keying material by sending a CoAP GET request to the /ace-group/ GROUPNAME endpoint at the KDC, where the group is identified by GROUPNAME.
グループ内のノードは、KDCに連絡して、KDCの / ace-group / groupNameエンドポイントにCOAP GETリクエストを送信することにより、現在のグループキーイングマテリアルを取得できます。グループはグループ名で識別されます。
Figure 14 gives an overview of the key distribution exchange between the Client and the KDC, while Figure 15 shows an example.
図14に、クライアントとKDCの間の主要な分布交換の概要を示し、図15に例を示しています。
Client KDC
| |
|------ Key Distribution Request: GET /ace-group/GROUPNAME ------>|
| |
|<----------- Key Distribution Response: 2.05 (Content) --------- |
| |
Figure 14: Message Flow of Key Distribution Request-Response
図14：キーディストリビューションリクエスト応答のメッセージフロー
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Response:
Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ gkty / 7: 65600,
/ key / 8: h'73657373696f6e6b6579',
/ num / 9: 12
}
Figure 15: Example of Key Distribution Request-Response
図15：キーディストリビューションリクエスト応答の例
This resource implements the GET and FETCH handlers.
このリソースは、Get and Fetchハンドラーを実装します。
The FETCH handler receives identifiers of group members for the group identified by GROUPNAME and returns the authentication credentials of such group members.
Fetch Handlerは、GroupNameによって識別されたグループのグループメンバーの識別子を受信し、そのようなグループメンバーの認証資格情報を返します。
The handler expects a request with the payload formatted as a CBOR map, which MUST contain the following field.
ハンドラーは、ペイロードがCBORマップとしてフォーマットされたリクエストを期待しています。これには、次のフィールドを含める必要があります。
* 'get_creds': its value is encoded as in Section 4.3.1, with the following modifications.
* 「get_creds」：その値は、次の変更を加えて、セクション4.3.1のようにエンコードされます。
- The arrays 'role_filter' and 'id_filter' MUST NOT both be empty, i.e., in CDDL notation: [ bool, [ ], [ ] ]. If the 'get_creds' parameter has such a format, the request MUST be considered malformed, and the KDC MUST reply with a 4.00 (Bad Request) error response.
- Arrays 'Role_filter'と「id_filter」は両方とも空ではない必要があります。つまり、CDDL表記：[bool、[]、[]]。「get_creds」パラメーターにそのような形式がある場合、リクエストは奇形と見なされる必要があり、KDCは4.00（悪い要求）エラー応答で返信する必要があります。
Note that a group member can retrieve the authentication credentials of all the current group members by sending a GET request to the same KDC resource instead (see Section 4.4.2.1).
グループメンバーは、代わりに同じKDCリソースにGETリクエストを送信することにより、現在のすべてのグループメンバーの認証資格情報を取得できることに注意してください（セクション4.4.2.1を参照）。
- The element 'inclusion_flag' encodes the CBOR simple value true (0xf5) or false (0xf4), as defined in Section 4.3.1.
- 要素「inclusion_flag」は、セクション4.3.1で定義されているように、CBOR Simple値True（0xf5）またはfalse（0xf4）をエンコードします。
- The array 'role_filter' can be empty if the Client does not wish to filter the requested authentication credentials based on the roles of the group members.
- クライアントがグループメンバーの役割に基づいて要求された認証資格情報をフィルタリングすることを望まない場合、配列の「役割」は空になる可能性があります。
- The array 'id_filter' contains zero or more node identifiers of group members for the group identified by GROUPNAME, as defined in Section 4.3.1. The array may be empty if the Client does not wish to filter the requested authentication credentials based on the node identifiers of the group members.
- 配列「ID_Filter」には、セクション4.3.1で定義されているように、グループ名で識別されたグループのグループメンバーのゼロ以上のノード識別子が含まれています。グループメンバーのノード識別子に基づいて、クライアントが要求された認証資格情報をフィルタリングしたくない場合、配列は空になる場合があります。
Note that, in case the 'role_filter' array and the 'id_filter' array are both non-empty:
「role_filter」アレイと「id_filter」アレイがどちらも空でない場合に注意してください。
* If the 'inclusion_flag' encodes the CBOR simple value true (0xf5), the handler returns the authentication credentials of group members whose roles match with 'role_filter' and/or have their node identifier specified in 'id_filter'.
* 「inclusion_flag」がCBOR Simple Value True（0xf5）をエンコードする場合、ハンドラーは、役割が「role_filter」と一致するグループメンバーの認証資格情報を返し、「id_filter」でノード識別子を指定します。
* If the 'inclusion_flag' encodes the CBOR simple value false (0xf4), the handler returns the authentication credentials of group members whose roles match with 'role_filter' and, at the same time, do not have their node identifier specified in 'id_filter'.
* 「inclusion_flag」がCbor simple値false（0xf4）をエンコードする場合、ハンドラーは、役割が「role_filter」と一致するグループメンバーの認証資格情報を返し、同時に「id_filter」でノード識別子を指定していません。
The specific format of authentication credentials as well as the identifiers, roles, and combination of roles of group members MUST be specified by application profiles of this specification (REQ1, REQ6, REQ25).
認証資格情報の特定の形式と、識別子、役割、およびグループメンバーの役割の組み合わせは、この仕様のアプリケーションプロファイル（REQ1、REQ6、REQ25）によって指定する必要があります。
The handler identifies the authentication credentials of the current group members for which either of the following holds:
ハンドラーは、次のいずれかが保持する現在のグループメンバーの認証資格情報を識別します。
* The role identifier matches with one of those indicated in the request; note that the request can specify a combination of roles, in which case the handler selects only the group members that have all the roles included in the combination.
* 役割識別子は、リクエストに示されているものの1つと一致します。リクエストは役割の組み合わせを指定できることに注意してください。この場合、ハンドラーは、組み合わせにすべての役割を含むグループメンバーのみを選択します。
* The node identifier matches with one of those indicated in the request or does not match with any of those, which is consistent with the value of the element 'inclusion_flag'.
* ノード識別子は、要求に示されているものの1つと一致するか、それらのいずれかと一致しません。
If all verifications succeed, the handler returns a 2.05 (Content) message response with the payload formatted as a CBOR map, containing only the following parameters from Section 4.3.1.
すべての検証が成功した場合、ハンドラーは、セクション4.3.1の次のパラメーターのみを含む、CBORマップとしてフォーマットされたペイロードをフォーマットして2.05（コンテンツ）メッセージ応答を返します。
* 'num': encoding the version number of the current group keying material.
* 'num'：現在のグループキーイング素材のバージョン番号をエンコードします。
* 'creds': encoding the list of authentication credentials of the selected group members.
* 'creds'：選択したグループメンバーの認証資格情報のリストをエンコードします。
* 'peer_roles': encoding the role(s) that each of the selected group members has in the group.
* 'Peer_roles'：選択したグループメンバーのそれぞれがグループに持っている役割をエンコードします。
This parameter SHOULD be present, and it MAY be omitted according to the same criteria defined for the Join Response (see Section 4.3.1).
このパラメーターは存在する必要があり、結合応答に対して定義された同じ基準（セクション4.3.1を参照）に従って省略することができます。
* 'peer_identifiers': encoding the node identifier that each of the selected group members has in the group.
* 'Peer_identifiers'：選択した各グループメンバーがグループ内に持っているノード識別子をエンコードします。
The specific format of authentication credentials as well as of node identifiers of group members is specified by the application profile (REQ6, REQ25).
認証資格情報とグループメンバーのノード識別子の特定の形式は、アプリケーションプロファイル（REQ6、REQ25）によって指定されています。
If the KDC does not store any authentication credential associated with the specified node identifiers, the handler returns a response with the payload formatted as a CBOR byte string of zero length (0x40).
KDCが指定されたノード識別子に関連付けられた認証資格情報を保存しない場合、ハンドラーは、ゼロ長さ（0x40）のCBORバイト文字列としてフォーマットされたペイロードを使用して応答を返します。
The handler MAY enforce one of the following policies in order to handle possible node identifiers that are included in the 'id_filter' element of the 'get_creds' parameter of the request but are not associated with any current group member. Such a policy MUST be specified by application profiles of this specification (REQ26).
ハンドラーは、リクエストの「get_creds」パラメーターの「ID_FILTER」要素に含まれているが、現在のグループメンバーに関連付けられていない可能性のあるノード識別子を処理するために、次のポリシーのいずれかを実施できます。このようなポリシーは、この仕様のアプリケーションプロファイル（REQ26）によって指定する必要があります。
* The KDC silently ignores those node identifiers.
* KDCは、これらのノード識別子を静かに無視します。
* The KDC retains authentication credentials of group members for a given amount of time after their leaving before discarding them. As long as such authentication credentials are retained, the KDC provides them to a requesting Client.
* KDCは、グループメンバーが廃棄する前に退職後、特定の時間の間、グループメンバーの認証資格情報を保持します。そのような認証資格情報が保持される限り、KDCはそれらを要求クライアントに提供します。
If the KDC adopts this policy, the application profile MUST also specify the amount of time during which the KDC retains the authentication credential of a former group member after its leaving, possibly on a per-member basis.
KDCがこのポリシーを採用している場合、アプリケーションプロファイルは、KDCが去った後、おそらく1人のメンバーベースで元グループメンバーの認証資格を保持する時間を指定する必要があります。
Note that this resource handler only verifies that the node is authorized by the AS to access this resource. Nodes that are not members of the group but are authorized to do signature verifications on the group messages may be allowed to access this resource if the application needs it.
このリソースハンドラーは、このリソースにアクセスするためにノードが承認されていることのみを確認することに注意してください。グループのメンバーではないが、グループメッセージの署名の検証を行うことが許可されているノードは、アプリケーションが必要な場合にこのリソースにアクセスできる場合があります。
In case the KDC maintains the authentication credentials of group members, a node in the group can contact the KDC to request the authentication credentials, roles, and node identifiers of a specified subset of group members by sending a CoAP FETCH request to the /ace-group/GROUPNAME/creds endpoint at the KDC, which is formatted as defined in Section 4.4.1 and where GROUPNAME identifies the group.
KDCがグループメンバーの認証資格情報を維持している場合、グループ内のノードはKDCに連絡して、 /ace-にCOAPフェッチリクエストを送信することにより、グループメンバーの指定されたサブセットの認証資格情報、役割、およびノード識別子を要求できます。KDCのGroup/GroupName/CREDSエンドポイント。これは、セクション4.4.1で定義されているようにフォーマットされ、GroupNameがグループを識別します。
Figure 16 gives an overview of the exchange mentioned above, while Figure 17 shows an example of such an exchange.
図16は、上記の交換の概要を示し、図17はそのような交換の例を示しています。
Client KDC
| |
| Authentication Credential Request: |
|-------------------------------------------------------->|
| FETCH /ace-group/GROUPNAME/creds |
| |
|<-- Authentication Credential Response: 2.05 (Content) --|
| |
Figure 16: Message Flow of Authentication Credential Request-Response to Obtain the Authentication Credentials of Specific Group Members
図16：認証のメッセージの流れ特定のグループメンバーの認証資格情報を取得するためのリクエスト応答
Request:
Header: FETCH (Code=0.05)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "creds"
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ get_creds / 4: [true, [], [h'02', h'03']]
}
Response:
Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ creds / 13: [h'a2026008a101a5010202410320012158
20ac75e9ece3e50bfc8ed60399889522
405c47bf16df96660a41298cb4307f7e
b62258206e5de611388a4b8a8211334a
c7d37ecb52a387d257e6db3c2a93df21
ff3affc8',
h'a2026008a101a5010202410920012158
206f9702a66602d78f5e81bac1e0af01
f8b52810c502e87ebb7c926c07426fd0
2f225820c8d33274c71c9b3ee57d842b
bf2238b8283cb410eca216fb72a78ea7
a870f800'],
/ peer_roles / 14: [["sender", "receiver"], "receiver"],
/ peer_identifiers / 15: [h'02', h'03']
}
Figure 17: Example of Authentication Credential Request-Response to Obtain the Authentication Credentials of Specific Group Members
図17：特定のグループメンバーの認証資格情報を取得するための認証資格リクエスト応答の例
The handler expects a GET request.
ハンドラーはGETリクエストを期待しています。
If all verifications succeed, the KDC replies with a 2.05 (Content) response as in the FETCH handler in Section 4.4.1, but its payload specifies the authentication credentials of all the group members, together with their roles and node identifiers.
すべての検証が成功した場合、KDCはセクション4.4.1のフェッチハンドラーのように2.05（コンテンツ）応答で応答しますが、そのペイロードは、すべてのグループメンバーの認証資格情報とその役割とノード識別子を指定します。
The 'peer_roles' parameter SHOULD be present in the payload of the response, and it MAY be omitted according to the same criteria defined for the Join Response (see Section 4.3.1).
「PEER_ROLES」パラメーターは、応答のペイロードに存在する必要があり、結合応答に対して定義された同じ基準（セクション4.3.1を参照）に従って省略できます。
In case the KDC maintains the authentication credentials of group members, a node in the group or an external signature verifier can contact the KDC to request the authentication credentials, roles, and node identifiers of all the current group members, by sending a CoAP GET request to the /ace-group/GROUPNAME/creds endpoint at the KDC, where the group is identified by GROUPNAME.
KDCがグループメンバーの認証資格情報を維持している場合、グループ内のノードまたは外部署名検証者は、KDCに連絡して、COAP GETリクエストを送信して、現在のグループメンバーの認証資格情報、役割、およびノード識別子を要求できます。KDCの/ace-group/groupName/credsエンドポイントへ。グループはGroupNameで識別されます。
Figure 18 gives an overview of the message exchange, while Figure 19 shows an example of such an exchange.
図18にメッセージ交換の概要を示し、図19はそのような交換の例を示しています。
Client KDC
| |
| Authentication Credential Request: |
|-------------------------------------------------------->|
| GET /ace-group/GROUPNAME/creds |
| |
|<-- Authentication Credential Response: 2.05 (Content) --|
| |
Figure 18: Message Flow of Authentication Credential Request-Response to Obtain the Authentication Credentials of All the Group Members
図18：認証のメッセージの流れすべてのグループメンバーの認証資格情報を取得するためのリクエスト応答
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "creds"
Response:
Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ num / 9: 12,
/ creds / 13: [h'a2026008a101a5010202410220012158
20cd4177ba62433375ede279b5e18e8b
91bc3ed8f1e174474a26fc0edb44ea53
73225820a0391de29c5c5badda610d4e
301eaaa18422367722289cd18cbe6624
e89b9cfd',
h'a2026008a101a5010202410320012158
20ac75e9ece3e50bfc8ed60399889522
405c47bf16df96660a41298cb4307f7e
b62258206e5de611388a4b8a8211334a
c7d37ecb52a387d257e6db3c2a93df21
ff3affc8',
h'a2026008a101a5010202410920012158
206f9702a66602d78f5e81bac1e0af01
f8b52810c502e87ebb7c926c07426fd0
2f225820c8d33274c71c9b3ee57d842b
bf2238b8283cb410eca216fb72a78ea7
a870f800'],
/ peer_roles / 14: ["sender", ["sender", "receiver"],
"receiver"],
/ peer_identifiers / 15: [h'01', h'02', h'03']
}
Figure 19: Example of Authentication Credential Request-Response to Obtain the Authentication Credentials of All the Group Members
図19：すべてのグループメンバーの認証資格情報を取得するための認証資格リクエスト応答の例
This resource implements a GET handler.
このリソースはGet Handlerを実装します。
The handler expects a GET request.
ハンドラーはGETリクエストを期待しています。
If all verifications succeed, the handler returns a 2.05 (Content) message containing the KDC's authentication credential together with the proof-of-possession (PoP) evidence. The response MUST have Content-Format "application/ace-groupcomm+cbor". The payload of the response is a CBOR map, which includes the following fields.
すべての検証が成功した場合、ハンドラーは、KDCの認証資格情報を含む2.05（コンテンツ）メッセージと、プルーフオブポッセッション（POP）の証拠を返します。応答には、コンテンツフォーマット「Application/Ace-GroupComm+Cbor」が必要です。応答のペイロードは、次のフィールドを含むCBORマップです。
* 'kdc_cred: specifying the KDC's authentication credential. This parameter is encoded like the 'kdc_cred' parameter in the Join Response (see Section 4.3.1).
* 'KDC_CRED：KDCの認証資格情報を指定します。このパラメーターは、結合応答の「KDC_CRED」パラメーターのようにエンコードされています（セクション4.3.1を参照）。
* 'kdc_nonce': specifying a nonce generated by the KDC. This parameter is encoded like the 'kdc_nonce' parameter in the Join Response (see Section 4.3.1).
* 'KDC_NONCE'：KDCによって生成されたNonceを指定します。このパラメーターは、結合応答の「kdc_nonce」パラメーターのようにエンコードされています（セクション4.3.1を参照）。
* 'kdc_cred_verify': specifying the PoP evidence computed by the KDC over the following PoP input: the nonce N_C (encoded as a CBOR byte string) concatenated with the nonce N_KDC (encoded as a CBOR byte string), where:
* 'KDC_CRED_VERIFY'：次のPOP入力でKDCによって計算されたポップエビデンスを指定します。NonCeN_KDC（CBORバイト文字列としてエンコード）と合わせたNonCE N_C（CBORバイト文字列としてエンコード）、ここで
- N_C is the nonce generated by the Client group member such that: i) the nonce was specified in the 'cnonce' parameter of the latest Join Request that the Client sent to the KDC in order to join the group identified by GROUPNAME; and ii) the KDC stored the nonce as a 'clientchallenge' value associated with the Client after sending the corresponding Join Response (see Section 4.3.1).
- N_Cは、次のようなクライアントグループメンバーによって生成されたNONCEです。i）NonCEは、GroupNameで識別されたグループに参加するためにクライアントがKDCに送信した最新の参加要求の「CNONCE」パラメーターで指定されました。ii）KDCは、対応する結合応答を送信した後、クライアントに関連付けられた「クライアントチャレンジ」値としてノンセを保存しました（セクション4.3.1を参照）。
- N_KDC is the nonce generated by the KDC and specified in the 'kdc_nonce' parameter.
- N_KDCは、KDCによって生成され、「KDC_NONCE」パラメーターで指定されているNONCEです。
An example of PoP input to compute 'kdc_cred_verify' using CBOR encoding is given in Figure 20.
CBORエンコードを使用して「kdc_cred_verify」を計算するポップ入力の例を図20に示します。
The PoP evidence is computed by means of the same method used for computing the PoP evidence that was included in the Join Response for this Client (see Section 4.3.1).
ポップエビデンスは、このクライアントの結合応答に含まれているポップエビデンスの計算に使用されるのと同じ方法によって計算されます（セクション4.3.1を参照）。
Application profiles of this specification MUST specify the exact approaches used by the KDC to compute the PoP evidence to include in the 'kdc_cred_verify' parameter and MUST specify which of those approaches is used in which case (REQ21).
この仕様のアプリケーションプロファイルは、KDCが使用する正確なアプローチを指定して、「KDC_CRED_VERIFY」パラメーターに含めるポップエビデンスを計算し、それらのアプローチがその場合（REQ21）を使用するものを指定する必要があります。
If an application profile supports the presence of external signature verifiers that send GET requests to this resource, then the application profile MUST specify how external signature verifiers provide the KDC with a self-generated nonce to use as N_C (REQ21).
アプリケーションプロファイルがこのリソースにGETリクエストを送信する外部署名検証剤の存在をサポートする場合、アプリケーションプロファイルは、外部署名検証者がN_C（REQ21）として使用する自己生成されたNONCEをKDCに提供する方法を指定する必要があります。
N_C and N_KDC expressed in CBOR diagnostic notation:
N_C = h'25a8991cd700ac01'
N_KDC = h'0b7db12aaff56da3'
N_C and N_KDC as CBOR encoded byte strings:
N_C = 0x4825a8991cd700ac01
N_KDC = 0x480b7db12aaff56da3
PoP input:
0x48 25a8991cd700ac01 48 0b7db12aaff56da3
Figure 20: Example of PoP Input to Compute 'kdc_cred_verify' Using CBOR Encoding
図20：cborエンコーディングを使用して「kdc_cred_verify」を計算するポップ入力の例
In case the KDC has an associated authentication credential as required for the correct group operation, a group member or an external signature verifier can contact the KDC to request the KDC's authentication credential by sending a CoAP GET request to the /ace-group/GROUPNAME/kdc-cred endpoint at the KDC, where GROUPNAME identifies the group.
KDCが正しいグループ操作に必要な関連認証資格情報を持っている場合、グループメンバーまたは外部署名検証者は、KDCに連絡して、/ace-group/groupName/KDCのKDCクレッドエンドポイントは、グループ名がグループを識別します。
Upon receiving the 2.05 (Content) response, the Client retrieves the KDC's authentication credential from the 'kdc_cred' parameter and MUST verify the proof-of-possession (PoP) evidence specified in the 'kdc_cred_verify' parameter. In case of successful verification of the PoP evidence, the Client MUST store the obtained KDC's authentication credential and replace the currently stored one.
2.05（コンテンツ）の応答を受信すると、クライアントは「KDC_CRED」パラメーターからKDCの認証資格情報を取得し、「KDC_CRED_VERIFY」パラメーターで指定されたプルーフオブポッセッション（POP）証拠を検証する必要があります。ポップエビデンスの検証が成功した場合、クライアントは取得したKDCの認証資格情報を保存し、現在保存されているものを交換する必要があります。
The PoP evidence is verified by means of the same method used when processing the Join Response (see Section 4.3.1). Application profiles of this specification MUST specify the exact approaches used by the Client to verify the PoP evidence in 'kdc_cred_verify' and MUST specify which of those approaches is used in which case (REQ21).
POPの証拠は、結合応答を処理するときに使用される同じ方法によって検証されます（セクション4.3.1を参照）。この仕様のアプリケーションプロファイルは、「kdc_cred_verify」のポップエビデンスを検証するためにクライアントが使用する正確なアプローチを指定し、それらのアプローチのどれがその場合（Req21）を使用するかを指定する必要があります。
Figure 21 gives an overview of the exchange described above, while Figure 22 shows an example.
図21に、上記の交換の概要を示し、図22は例を示しています。
Group
Member KDC
| |
| KDC Authentication Credential Request |
|------------------------------------------------------------>|
| GET /ace-group/GROUPNAME/kdc-cred |
| |
|<-- KDC Authentication Credential Response: 2.05 (Content) --|
| |
Figure 21: Message Flow of KDC Authentication Credential Request-Response to Obtain the Authentication Credential of the KDC
図21：KDC認証資格リクエスト応答のメッセージフローKDCの認証資格情報を取得する
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "kdc-cred"
Response:
Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ kdc_cred / 17: h'a2026008a101a5010202419920012158
2065eda5a12577c2bae829437fe33870
1a10aaa375e1bb5b5de108de439c0855
1d2258201e52ed75701163f7f9e40ddf
9f341b3dc9ba860af7e0ca7ca7e9eecd
0084d19c',
/ kdc_nonce / 18: h'0b7db12aaff56da3',
/ kdc_cred_verify / 19: h'3fc54702aa56e1b2cb20284294c9106a
63f91bac658d69351210a031d8fc7c5f
f3e4be39445b1a3e83e1510d1aca2f2e
8a7c081c7645042b18aba9d1fad1bd9c'
}
Figure 22: Example of KDC Authentication Credential Request-Response to Obtain the Authentication Credential of the KDC
図22：KDCの認証要求応答の例KDCの認証資格情報を取得するための例
This resource implements the GET handler.
このリソースは、Get Handlerを実装します。
The handler expects a GET request.
ハンドラーはGETリクエストを期待しています。
In addition to what is defined in Section 4.1.2, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format "application/ concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members").
セクション4.1.2で定義されているものに加えて、ハンドラーは、クライアントがグループの現在のメンバーであることを確認します。検証が失敗した場合、KDCは4.03（禁止）エラー応答で返信する必要があります。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は0に設定する必要があります（「グループメンバーのみに許可される操作」）。
If all verifications succeed, the handler replies with a 2.05 (Content) response containing the list of policies for the group identified by GROUPNAME. The payload of the response is formatted as a CBOR map including only the 'group_policies' parameter defined in Section 4.3.1 and specifying the current policies in the group. If the KDC does not store any policy, the payload is formatted as a CBOR byte string of zero length (0x40).
すべての検証が成功した場合、ハンドラーは、グループ名で識別されたグループのポリシーのリストを含む2.05（コンテンツ）応答で応答します。応答のペイロードは、セクション4.3.1で定義されている「Group_Policies」パラメーターのみを含むCBORマップとしてフォーマットされ、グループ内の現在のポリシーを指定します。KDCがポリシーを保存しない場合、ペイロードはゼロ長のCBORバイト文字列（0x40）としてフォーマットされます。
The specific format and meaning of group policies MUST be specified in application profiles of this specification (REQ20).
グループポリシーの特定の形式と意味は、この仕様のアプリケーションプロファイル（REQ20）で指定する必要があります。
A node in the group can contact the KDC to retrieve the current group policies by sending a CoAP GET request to the /ace-group/GROUPNAME/ policies endpoint at the KDC, which is formatted as defined in Section 4.6.1 and where GROUPNAME identifies the group.
グループ内のノードは、KDCに連絡して現在のグループポリシーを取得できます。KDCの/ace-group/groupName/ポリシーエンドポイントにCOAP GETリクエストを送信します。グループ。
Figure 23 gives an overview of the exchange described above, while Figure 24 shows an example.
図23に、上記の交換の概要を示し、図24は例を示しています。
Client KDC
| |
|-- Policies Request: GET /ace-group/GROUPNAME/policies -->|
| |
|<----------- Policies Response: 2.05 (Content) -----------|
| |
Figure 23: Message Flow of Policies Request-Response
図23：ポリシーリクエスト応答のメッセージの流れ
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "policies"
Response:
Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload(in CBOR diagnostic notation):
{
/ group_policies / 16: {
/ Expiration Delta / 2: 120
}
}
Figure 24: Example of Policies Request-Response
図24：ポリシー要求応答の例
This resource implements the GET handler.
このリソースは、Get Handlerを実装します。
The handler expects a GET request.
ハンドラーはGETリクエストを期待しています。
In addition to what is defined in Section 4.1.2, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format "application/ concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members").
セクション4.1.2で定義されているものに加えて、ハンドラーは、クライアントがグループの現在のメンバーであることを確認します。検証が失敗した場合、KDCは4.03（禁止）エラー応答で返信する必要があります。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は0に設定する必要があります（「グループメンバーのみに許可される操作」）。
If all verifications succeed, the handler returns a 2.05 (Content) message containing an integer that represents the version number of the symmetric group keying material. This number is incremented on the KDC every time the KDC updates the symmetric group keying material before the new keying material is distributed. This number is stored in persistent storage.
すべての検証が成功した場合、ハンドラーは、対称グループキーイングマテリアルのバージョン番号を表す整数を含む2.05（コンテンツ）メッセージを返します。この数値は、新しいキーイング材料が配布される前に、KDCが対称グループキーイング素材を更新するたびにKDCで増加します。この番号は、永続的なストレージに保存されます。
The payload of the response is formatted as a CBOR integer.
応答のペイロードは、CBOR整数としてフォーマットされます。
A node in the group can contact the KDC to request information about the version number of the symmetric group keying material by sending a CoAP GET request to the /ace-group/GROUPNAME/num endpoint at the KDC, which is formatted as defined in Section 4.7.1 and where GROUPNAME identifies the group. In particular, the version is incremented by the KDC every time the group keying material is renewed before it is distributed to the group members.
グループ内のノードは、KDCに連絡して、COAP GETリクエストをKDCの/ace-group/groupName/numエンドポイントにCOAP GETリクエストを送信して、対称グループキーイングマテリアルのバージョン番号に関する情報を要求します。4.7.1およびGroupNameがグループを識別します。特に、グループキーイング素材がグループメンバーに配布される前に更新されるたびに、バージョンはKDCによって増加します。
Figure 25 gives an overview of the exchange described above, while Figure 26 shows an example.
図25に、上記の交換の概要を示し、図26は例を示しています。
Client KDC
| |
|---- Version Request: GET /ace-group/GROUPNAME/num ---->|
| |
|<---------- Version Response: 2.05 (Content) -----------|
| |
Figure 25: Message Flow of Version Request-Response
図25：バージョンリクエスト応答のメッセージフロー
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "num"
Response:
Header: Content (Code=2.05)
Content-Format: 60 (application/cbor)
Payload (in CBOR diagnostic notation):
13
Figure 26: Example of Version Request-Response
図26：バージョンリクエスト応答の例
This resource implements the GET, POST, and DELETE handlers.
このリソースは、取得、投稿、および削除ハンドラーを実装します。
In addition to what is defined in Section 4.1.2, each of the handlers performs the following two verifications.
セクション4.1.2で定義されているものに加えて、各ハンドラーは次の2つの検証を実行します。
* The handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members").
* ハンドラーは、クライアントがグループの現在のメンバーであることを確認します。検証が失敗した場合、KDCは4.03（禁止）エラー応答で返信する必要があります。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は0に設定する必要があります（「グループメンバーのみに許可される操作」）。
* The handler verifies that the node name of the Client is equal to NODENAME used in the url-path. If the verification fails, the handler replies with a 4.03 (Forbidden) error response.
* ハンドラーは、クライアントのノード名がURL-PATHで使用されるnodenameに等しいことを確認します。検証が失敗した場合、ハンドラーは4.03（禁止）エラー応答で応答します。
The handler expects a GET request.
ハンドラーはGETリクエストを期待しています。
If all verifications succeed, the handler replies with a 2.05 (Content) response containing both the group keying material and the individual keying material for the Client or information enabling the Client to derive it.
すべての検証が成功した場合、ハンドラーは、クライアントがそれを導き出すことを可能にするクライアントまたは情報のグループキーイング素材の両方を含む2.05（コンテンツ）応答で応答します。
The payload of the response is formatted as a CBOR map, which includes the same fields of the response defined in Section 4.3.2. In particular, the format for the group keying material is the same as defined in the response of Section 4.3.2. If the 'exp' parameter is included, the 'exi' parameter MUST also be included. If the parameter 'exi' is included, its value specifies the residual lifetime of the group keying material from the current time at the KDC.
応答のペイロードは、セクション4.3.2で定義された同じ応答のフィールドを含むCBORマップとしてフォーマットされます。特に、グループキーイングマテリアルの形式は、セクション4.3.2の応答で定義されているものと同じです。「EXP」パラメーターが含まれている場合、「EXI」パラメーターも含める必要があります。パラメーター「exi」が含まれている場合、その値は、KDCでの現在のグループキーイング素材の残留寿命を指定します。
The CBOR map can include additional parameters that specify the individual keying material for the Client. The specific format of individual keying material for group members or of the information to derive such keying material MUST be defined in application profiles of this specification (REQ27), together with the corresponding CBOR map key that has to be registered in the "ACE Groupcomm Parameters" registry defined in Section 11.7.
CBORマップには、クライアントの個々のキーイング素材を指定する追加のパラメーターを含めることができます。グループメンバーまたはそのようなキーイング材料を導き出すための情報の個々のキーイン素材の特定の形式は、この仕様のアプリケーションプロファイル（REQ27）で定義する必要があります。「セクション11.7で定義されているレジストリ。
Optionally, the KDC can make the sub-resource at /ace-group/GROUPNAME/nodes/NODENAME also observable [RFC7641] for the associated node. In case the KDC removes that node from the group without having been explicitly asked for it, this allows the KDC to send an unsolicited 4.04 (Not Found) response to the node as a notification of eviction from the group (see Section 5).
オプションで、KDCは、関連するノードの場合、サブリソースat/ace-group/groupname/nodes/nodes/nodenameも観察可能[RFC7641]を作成できます。KDCが明示的に要求されることなくグループからそのノードを削除した場合、これにより、KDCはグループからの立ち退きの通知としてノードに対する未承諾の4.04（発見されていない）応答を送信できます（セクション5を参照）。
Note that the node could have also been observing the resource at /ace-group/GROUPNAME in order to be informed of changes in the group keying material. In such a case, this method would result in largely overlapping notifications received for the resource at /ace-group/ GROUPNAME and the sub-resource at /ace-group/GROUPNAME/nodes/ NODENAME.
ノードは、グループキーイングマテリアルの変更を知らせるために、 /ace-group /groupNameのリソースを観察していた可能性があることに注意してください。そのような場合、この方法は、/ace-group/groupNameおよび/ace-group/groupName/nodes/nodenameでのリソースのリソースおよびサブリソースのサブリソースに対して受信された通知を大きく重複させます。
In order to mitigate this, a node that supports the CoAP No-Response Option [RFC7967] can use it when starting the observation of the sub-resource at /ace-group/GROUPNAME/nodes/NODENAME. In particular, the GET observation request can also include the No-Response option, with value set to 2 (Not interested in 2.xx responses).
これを緩和するために、COAP No-Responseオプション[RFC7967]をサポートするノードは、/ace-group/groupName/nodes/nodenameのサブリソースの観測を開始するときに使用できます。特に、GETの観測要求には、値が2に設定された応答なしオプションを含めることもできます（2.xx応答には興味がありません）。
When any of the following happens, a node MUST stop using the stored group keying material to protect outgoing messages and SHOULD stop using it to decrypt and verify incoming messages.
次のいずれかが発生した場合、ノードは、発信メッセージを保護するために保存されたグループキーイング素材の使用を停止する必要があり、それを使用して着信メッセージを解読および検証する必要があります。
* Upon expiration of the keying material, according to what is indicated by the KDC through the 'exp' and/or 'exi' parameter (e.g., in a Join Response) or to a pre-configured value.
* キーイング素材の有効期限が切れたら、KDCが「EXP」および/または「EXI」パラメーター（結合応答など）を介して示されていることに従って、または事前に構成された値に応じて。
* Upon receiving a notification of revoked/renewed keying material from the KDC, possibly as part of an update of the keying material (rekeying) triggered by the KDC.
* KDCによってトリガーされたキーイング素材（再キーイング）の更新の一部として、KDCから取り消された/更新されたキーイング素材の通知を受け取ったとき。
* Upon receiving messages from other group members without being able to retrieve the keying material to correctly decrypt them. This may be due to rekeying messages previously sent by the KDC that the Client was not able to receive or decrypt.
* キーイング素材を取得して正しく復号化することができずに、他のグループメンバーからメッセージを受信すると。これは、クライアントが以前に送信したメッセージを、クライアントが受信または復号化できなかったというメッセージを再キーすることによる可能性があります。
In either case, if it wants to continue participating in the group communication, the Client has to request the latest keying material from the KDC. To this end, the Client sends a CoAP GET request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, formatted as specified in Section 4.8.1. The Client can request the latest keying material from the KDC before the currently stored, old keying material reaches its expiration time.
どちらの場合でも、グループコミュニケーションへの参加を継続したい場合、クライアントはKDCから最新のキーイング素材を要求する必要があります。この目的のために、クライアントは、セクション4.8.1で指定されているようにフォーマットされているKDCの/ace-group/groupName/nodes/nodenameエンドポイントにCOAP GETリクエストを送信します。クライアントは、現在保存されている古いキーイング素材が有効期限に達する前に、KDCから最新のキーイング資料を要求できます。
Note that policies can be set up so that the Client sends a Key Distribution Request to the KDC only after a given number of received messages could not be decrypted (because of failed decryption processing or the inability to retrieve the necessary keying material).
ポリシーを設定できるように、特定の数の受信メッセージが復号化できなかった後にのみ、クライアントがKDCにキーディストリビューション要求を送信できるようにすることに注意してください（復号化処理の失敗または必要なキーイン材料を取得できないため）。
It is application dependent and pertaining to the used secure message exchange (e.g., [GROUP-OSCORE]) to set up these policies for instructing Clients to retain incoming messages and for how long (OPT11). This allows Clients to possibly decrypt such messages after getting updated keying material, rather than just consider them invalid messages to discard right away.
アプリケーションに依存し、使用済みのセキュアなメッセージ交換（[Group-Oscore]など）に関連することで、クライアントに着信メッセージを保持するよう指示するためにこれらのポリシーを設定し、どのくらいの期間（OPT11）。これにより、クライアントは、すぐに廃棄するために無効なメッセージを考慮するだけでなく、更新されたキーイング素材を取得した後にそのようなメッセージを解読することができます。
After having failed to decrypt messages from another group member and having sent a Key Distribution Request to the KDC, the Client might end up retrieving the same, latest group keying material that it already stores. In such a case, multiple failed decryptions might be due to the message sender and/or the KDC that have changed their authentication credential. Hence, the Client can retrieve such latest authentication credentials by sending to the KDC an Authentication Credential Request (see Sections 4.4.1.1 and 4.4.2.1) and a KDC Authentication Credential Request (see Section 4.5.1.1), respectively.
別のグループメンバーからのメッセージの復号化に失敗し、KDCにキーディストリビューションリクエストを送信した後、クライアントは、すでに保存している同じ最新のグループキーイング素材を取得することになります。そのような場合、複数の故障した復号化は、認証資格情報を変更したメッセージ送信者および/またはKDCによる可能性があります。したがって、クライアントは、それぞれKDCに認証資格要求（セクション4.4.1.1および4.4.2.1を参照）とKDC認証資格要求（セクション4.5.1.1を参照）を送信することにより、このような最新認証資格情報を取得できます。
The Client can also send to the KDC a Key Distribution Request without having been triggered by a failed decryption of a message from another group member, if the Client wants to be sure that it currently stores the latest group keying material. If that is the case, the Client will receive from the KDC the same group keying material it already stores.
クライアントは、クライアントが現在最新のグループキーイングマテリアルを保存していることを確認したい場合、別のグループメンバーからのメッセージの復号化によってトリガーされることなく、KDCにキーディストリビューリクエストを送信することもできます。その場合、クライアントはKDCから既に保存している同じグループキーイングマテリアルを受け取ります。
Figure 27 gives an overview of the exchange described above, while Figure 28 shows an example.
図27に、上記の交換の概要を示し、図28は例を示しています。
Client KDC
| |
|------------------ Key Distribution Request: --------------->|
| GET /ace-group/GROUPNAME/nodes/NODENAME |
| |
|<-------- Key Distribution Response: 2.05 (Content) ---------|
| |
Figure 27: Message Flow of Key Distribution Request-Response
図27：キーディストリビューションリクエスト応答のメッセージフロー
Request:
Header: GET (Code=0.01)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "nodes"
Uri-Path: "c101"
Response:
Header: Content (Code=2.05)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation, with "ind-key" being the
profile-specified label for individual keying material):
{
/ gkty / 7: 65600,
/ key / 8: h'73657373696f6e6b6579',
/ num / 9: 12,
"ind-key": h'fcae9023'
}
Figure 28: Example of Key Distribution Request-Response
図28：キーディストリビューションリクエスト応答の例
The POST handler processes requests from a Client that asks for new individual keying material, as required to process messages exchanged in the group.
ポストハンドラーは、グループで交換されるメッセージを処理するために必要な新しい個別キーイング資料を要求するクライアントからのリクエストを処理します。
The handler expects a POST request with an empty payload.
ハンドラーは、空のペイロードを備えたPOSTリクエストを期待しています。
In addition to what is defined in Section 4.1.2 and at the beginning of Section 4.8, the handler verifies that this operation is consistent with the set of roles that the Client has in the group (REQ11). If the verification fails, the KDC MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 1 ("Request inconsistent with the current roles").
セクション4.1.2で定義されているものとセクション4.8の先頭に加えて、ハンドラーは、この操作がクライアントがグループに持っている役割のセットと一致していることを確認します（Req11）。検証が失敗した場合、KDCは4.00（悪い要求）エラー応答で返信する必要があります。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は1（「現在の役割と矛盾する要求」）に設定する必要があります。
If the KDC is currently not able to serve this request, i.e., to generate new individual keying material for the requesting Client, the KDC MUST reply with a 5.03 (Service unavailable) error response. The response MUST have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 4 ("No available individual keying material").
KDCが現在このリクエストを提供できない場合、つまり、要求クライアントの新しい個々のキーイング資料を生成するために、KDCは5.03（サービスが利用できない）エラー応答で返信する必要があります。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は4（「利用可能な個別のキーイング資料なし」）に設定する必要があります。
If all verifications succeed, the handler replies with a 2.04 (Changed) response containing newly generated individual keying material for the Client. The payload of the response is formatted as a CBOR map. The specific format of newly generated individual keying material for group members or of the information to derive such keying material MUST be defined in application profiles of this specification (REQ27), together with the corresponding CBOR map key that has to be registered in the "ACE Groupcomm Parameters" registry defined in Section 11.7.
すべての検証が成功した場合、ハンドラーは、クライアント用に新しく生成された個々のキーイング資料を含む2.04（変更）応答で応答します。応答のペイロードは、CBORマップとしてフォーマットされます。グループメンバーまたはそのようなキーイング材料を導き出すための新しく生成された個々のキーイング資料の特定の形式は、この仕様のアプリケーションプロファイル（REQ27）で定義する必要があります。GroupCommパラメーター "セクション11.7で定義されているレジストリ。
The typical successful outcome consists in replying with newly generated individual keying material for the Client, as defined above. However, application profiles of this specification MAY also extend this handler in order to achieve different akin outcomes (OPT12), for instance:
典型的な成功した結果は、上記で定義されているように、クライアント向けに新しく生成された個々のキーイング資料で応答することです。ただし、この仕様のアプリケーションプロファイルは、このハンドラーを拡張して、さまざまなAkinの結果を達成するためにも拡張する場合があります（OPT12）。
* Not providing the Client with newly generated individual keying material, but rather rekeying the whole group, i.e., providing all the current group members with newly generated group keying material.
* クライアントに新しく生成された個々のキーイング素材を提供するのではなく、グループ全体を再キーにします。つまり、現在のすべてのグループメンバーに新しく生成されたグループキーイング素材を提供します。
* Both providing the Client with newly generated individual keying material, as well as rekeying the whole group, i.e., providing all the current group members with newly generated group keying material.
* どちらも、クライアントに新しく生成された個々のキーイング素材を提供し、グループ全体を再キーすること、つまり現在のすべてのグループメンバーに新しく生成されたグループキーイング素材を提供します。
In either case, the handler may specify the new group keying material as part of the 2.04 (Changed) response.
どちらの場合でも、ハンドラーは2.04（変更）応答の一部として新しいグループキーイングマテリアルを指定することができます。
Note that this handler is not intended to accommodate requests from a group member to trigger a group rekeying, whose scheduling and execution is an exclusive prerogative of the KDC (also see related security considerations in Section 10.2).
このハンドラーは、スケジューリングと実行がKDCの排他的特権であるグループをトリガーするためにグループメンバーからのリクエストに対応することを意図していないことに注意してください（セクション10.2の関連するセキュリティに関する考慮事項も参照）。
A Client may ask the KDC for new individual keying material. For instance, this can be due to the expiration of such individual keying material or to the exhaustion of Authenticated Encryption with Associated Data (AEAD) nonces if an AEAD encryption algorithm is used for protecting communications in the group. An example of individual keying material can simply be an individual encryption key associated with the Client. Hence, the Client may ask for a new individual encryption key or for new input material to derive it.
クライアントは、KDCに新しい個別のキーイング資料を求めることができます。たとえば、これは、このような個々のキーイング材料の有効期限が切れるか、AEAD暗号化アルゴリズムがグループ内の通信を保護するために使用されている場合、関連データ（AEAD）の認証された暗号化の疲労による可能性があります。個々のキーイング材料の例は、単にクライアントに関連付けられた個々の暗号化キーにすることができます。したがって、クライアントは、新しい個別の暗号化キーまたは新しい入力資料を導出するための新しい入力資料を要求する場合があります。
To this end, the Client performs a Key Renewal Request-Response exchange with the KDC, i.e., it sends a CoAP POST request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, which is formatted as defined in Section 4.8.1, where GROUPNAME identifies the group and NODENAME is the node name of the Client.
この目的のために、クライアントはKDCとのキー更新リクエスト応答交換を実行します。つまり、KDCの/ace-group/groupName/nodes/nodenameエンドポイントにCoap postリクエストを送信します。4.8.1、GroupNameがグループを識別し、Nodenameがクライアントのノード名です。
Figure 29 gives an overview of the exchange described above, while Figure 30 shows an example.
図29に、上記の交換の概要を示し、図30に例を示しています。
Client KDC
| |
|---------------- Key Renewal Request: ---------------->|
| POST /ace-group/GROUPNAME/nodes/NODENAME |
| |
|<-------- Key Renewal Response: 2.04 (Changed) --------|
| |
Figure 29: Message Flow of Key Renewal Request-Response
図29：キーリニューアルリクエスト応答のメッセージフロー
Request:
Header: POST (Code=0.02)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "nodes"
Uri-Path: "c101"
Response:
Header: Changed (Code=2.04)
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation, with "ind-key" being the
profile-specified label for individual keying material):
{
"ind-key": h'b71acc28'
}
Figure 30: Example of Key Renewal Request-Response
図30：キー更新リクエスト応答の例
Note that there is a difference between the Key Renewal Request in this section and the Key Distribution Request in Section 4.8.1.1. The former asks the KDC for new individual keying material, while the latter asks the KDC for the current group keying material together with the current individual keying material.
このセクションの主要な更新要求と、セクション4.8.1.1のキー配布要求には違いがあることに注意してください。前者はKDCに新しい個別のキーイング材料を求め、後者は現在のグループキーイング素材と現在の個々のキーイング素材をKDCに尋ねます。
As discussed in Section 4.8.2, application profiles of this specification may define alternative outcomes for the Key Renewal Request-Response exchange (OPT12), where the provisioning of new individual keying material is replaced by or combined with the execution of a whole group rekeying.
セクション4.8.2で説明したように、この仕様のアプリケーションプロファイルは、新しい個々のキーイング素材のプロビジョニングが、グループ全体の実行に置き換えられるか、または組み合わされている主要な更新リクエスト応答交換（OPT12）の代替結果を定義する場合があります。。
The DELETE handler removes the node identified by NODENAME from the group identified by GROUPNAME.
削除ハンドラーは、グループ名で識別されたグループからnodenameによって識別されたノードを削除します。
The handler expects a DELETE request with an empty payload.
ハンドラーは、空のペイロードを使用した削除要求を期待しています。
In addition to what is defined in Section 4.1.2, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format "application/ concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members").
セクション4.1.2で定義されているものに加えて、ハンドラーは、クライアントがグループの現在のメンバーであることを確認します。検証が失敗した場合、KDCは4.03（禁止）エラー応答で返信する必要があります。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は0に設定する必要があります（「グループメンバーのみに許可される操作」）。
If all verification succeeds, the handler performs the actions defined in Section 5 and replies with a 2.02 (Deleted) response with an empty payload.
すべての検証が成功した場合、ハンドラーはセクション5で定義されたアクションを実行し、空のペイロードで2.02（削除）応答で応答します。
A Client can actively request to leave the group. In this case, the Client sends a CoAP DELETE request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME at the KDC, where GROUPNAME identifies the group and NODENAME is the Client's node name.
クライアントは積極的にグループを離れるように要求できます。この場合、クライアントはKDCのエンドポイント/ACE-Group/GroupName/nodes/nodes/nodenameにCoap削除要求を送信します。
Note that, after having left the group, the Client may wish to join it again. Then, as long as the Client is still authorized to join the group, i.e., the associated access token is still valid, the Client can request to rejoin the group directly to the KDC (see Section 4.3.1.1) without having to retrieve a new access token from the AS.
グループを去った後、クライアントは再び参加したいと思うかもしれません。次に、クライアントがグループに参加することを許可されている限り、つまり関連するアクセストークンがまだ有効である限り、クライアントは新しいものを取得することなく、グループに直接KDC（セクション4.3.1.1を参照）に直接再加入するよう要求できますASからのアクセストークン。
This resource implements the POST handler.
このリソースはポストハンドラーを実装します。
The POST handler is used to replace the stored authentication credential of this Client (identified by NODENAME) with the one specified in the request at the KDC for the group identified by GROUPNAME.
ポストハンドラーは、このクライアントの保存された認証資格情報（nodenameで識別）を、グループ名で識別されたグループのKDCのリクエストで指定されたものに置き換えるために使用されます。
The handler expects a POST request with the payload as specified in Section 4.3.1, with the difference that the payload includes only the parameters 'client_cred', 'cnonce', and 'client_cred_verify'.
ハンドラーは、セクション4.3.1で指定されているペイロードを含むPOSTリクエストを期待しており、ペイロードにはパラメーターのクライアント_cred '、「cnonce」、および「client_cred_verify」のみが含まれるという違いがあります。
The PoP evidence included in the 'client_cred_verify' parameter is computed in the same way considered in Section 4.3.1 and defined by the specific application profile (REQ14) by using the following to build the PoP input: i) the same scope entry specified by the Client in the 'scope' parameter of the latest Join Request that the Client sent to the KDC in order to join the group identified by GROUPNAME; ii) the latest N_S value stored by the Client; and iii) a new N_C nonce generated by the Client and specified in the parameter 'cnonce' of this request.
「client_cred_verify」パラメーターに含まれるポップエビデンスは、セクション4.3.1で考慮され、次のPOP入力を構築するために特定のアプリケーションプロファイル（REQ14）で定義され、次のように計算されます。クライアントは、グループ名で識別されたグループに参加するために、クライアントがKDCに送信した最新の参加要求の「スコープ」パラメーターのクライアント。ii）クライアントが保存する最新のN_S値。iii）クライアントによって生成され、このリクエストのパラメーター「cnonce」で指定された新しいN_C Nonce。
An example of PoP input to compute 'client_cred_verify' using CBOR encoding is given in Figure 31.
CBORエンコードを使用して「client_cred_verify」を計算するポップ入力の例を図31に示します。
It is REQUIRED for application profiles to define the specific formats of authentication credentials that are acceptable to use in the group (REQ6).
アプリケーションプロファイルには、グループで使用できる特定の形式の認証資格情報を定義する必要があります（REQ6）。
In addition to what is defined in Section 4.1.2 and at the beginning of Section 4.8, the handler verifies that this operation is consistent with the set of roles that the node has in the group. If the verification fails, the KDC MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format "application/ concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 1 ("Request inconsistent with the current roles").
セクション4.1.2で定義されているものとセクション4.8の先頭に加えて、ハンドラーは、この操作がグループ内のノードが持っている役割のセットと一致していることを確認します。検証が失敗した場合、KDCは4.00（悪い要求）エラー応答で返信する必要があります。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は1（「現在の役割と矛盾する要求」）に設定する必要があります。
If the KDC cannot retrieve the 'kdcchallenge' associated with this Client (see Section 3.3), the KDC MUST reply with a 4.00 (Bad Request) error response, which MUST also have Content-Format "application/ace-groupcomm+cbor". The payload of the error response is a CBOR map including the 'kdcchallenge' parameter, which specifies a newly generated 'kdcchallenge' value. In such a case, the KDC MUST store the newly generated value as the 'kdcchallenge' value associated with this Client, replacing the currently stored value (if any).
KDCがこのクライアントに関連付けられた「KDCChallenge」を取得できない場合（セクション3.3を参照）、KDCは4.00（悪い要求）エラー応答で返信する必要があります。エラー応答のペイロードは、新しく生成された「kdcchallenge」値を指定する「kdcchallenge」パラメーターを含むcborマップです。そのような場合、KDCは、このクライアントに関連付けられた「KDCChallenge」値として新しく生成された値を保存する必要があり、現在保存されている値（ある場合）を置き換えます。
Otherwise, the handler checks that the authentication credential specified in the 'client_cred' field is valid for the group identified by GROUPNAME. That is, the handler checks that the authentication credential is encoded according to the format used in the group, is intended for the public key algorithm used in the group, and is aligned with the possible associated parameters used in the group. If that cannot be successfully verified, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 2 ("Authentication credential incompatible with the group configuration").
それ以外の場合、ハンドラーは、「client_cred」フィールドで指定された認証資格情報がグループ名で識別されたグループに対して有効であることを確認します。つまり、ハンドラーは、認証資格情報がグループで使用される形式に従ってエンコードされていることをチェックし、グループで使用される公開キーアルゴリズムを対象としており、グループで使用される可能性のある関連パラメーターと一致しています。それを正常に検証できない場合、ハンドラーは4.00（悪い要求）エラー応答で返信する必要があります。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は2に設定する必要があります（「グループ構成と互換性のない認証資格情報」）。
Otherwise, the handler verifies the PoP evidence conveyed in the 'client_cred_verify' parameter of the request, by using the authentication credential specified in the 'client_cred' parameter as well as the same way considered in Section 4.3.1 and defined by the specific application profile (REQ14). If the PoP evidence does not pass verification, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format "application/ concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 3 ("Invalid proof-of-possession evidence").
それ以外の場合、ハンドラーは、「client_cred_verify」パラメーターで「client_cred_verify」パラメーターで伝えられるポップエビデンスを確認します。（req14）。ポップエビデンスが検証に合格しない場合、ハンドラーは4.00（悪い要求）エラー応答で返信する必要があります。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は3に設定する必要があります（「無効な入場証明証拠」）。
If all verifications succeed, the handler performs the following actions.
すべての検証が成功した場合、ハンドラーは次のアクションを実行します。
* The handler associates the authentication credential from the 'client_cred' parameter of the request with the node identifier NODENAME, as well as with the access token associated with the node identified by NODENAME.
* ハンドラーは、リクエストの「client_creded」パラメーターから認証資格情報を、ノード識別子nodenameと、およびnodenameで識別されたノードに関連付けられたアクセストークンに関連付けます。
* In the stored list of group members' authentication credentials for the group identified by GROUPNAME, the handler replaces the authentication credential of the node identified by NODENAME with the authentication credential specified in the 'client_cred' parameter of the request.
* グループ名で識別されたグループのグループメンバーの認証資格情報の保存されたリストでは、ハンドラーはノードによって識別されたノードの認証資格情報を、リクエストの「client_cred」パラメーターで指定された認証資格情報に置き換えます。
Then, the handler replies with a 2.04 (Changed) response, which does not include a payload.
次に、ハンドラーは2.04（変更）応答で応答しますが、これにはペイロードが含まれません。
scope, N_S, and N_C expressed in CBOR diagnostic notation:
scope = h'826667726f7570316673656e646572'
N_S = h'018a278f7faab55a'
N_C = h'0446baefc56111bf'
scope, N_S, and N_C as CBOR encoded byte strings:
scope = 0x4f826667726F7570316673656E646572
N_S = 0x48018a278f7faab55a
N_C = 0x480446baefc56111bf
PoP input:
0x4f 826667726f7570316673656e646572
48 018a278f7faab55a 48 0446baefc56111bf
Figure 31: Example of PoP Input to Compute 'client_cred_verify' Using CBOR Encoding
図31：cborエンコーディングを使用して「client_cred_verify」を計算するポップ入力の例
In case the KDC maintains the authentication credentials of group members, a node in the group can contact the KDC to upload a new authentication credential to use in the group and to replace the currently stored one.
KDCがグループメンバーの認証資格情報を維持している場合、グループ内のノードはKDCに連絡して、グループで使用する新しい認証資格情報をアップロードし、現在保存されているものを置き換えることができます。
To this end, the Client performs an Authentication Credential Update Request-Response exchange with the KDC, i.e., it sends a CoAP POST request to the /ace-group/GROUPNAME/nodes/NODENAME/cred endpoint at the KDC, where GROUPNAME identifies the group and NODENAME is the Client's node name.
この目的のために、クライアントはKDCとの認証資格情報の更新リクエスト応答交換を実行します。つまり、KDCの/ace-group/groupName/nodes/nodename/credエンドポイントにCOAP POSTリクエストを送信します。グループとnodenameはクライアントのノード名です。
The request is formatted as specified in Section 4.9.1.
リクエストは、セクション4.9.1で指定されているようにフォーマットされます。
Figure 32 gives an overview of the exchange described above, while Figure 33 shows an example.
図32に、上記の交換の概要を示し、図33は例を示しています。
Client KDC
| |
|----------- Authentication Credential Update Request: --------->|
| POST /ace-group/GROUPNAME/nodes/NODENAME/cred |
| |
|<-- Authentication Credential Update Response: 2.04 (Changed) --|
| |
Figure 32: Message Flow of Authentication Credential Update Request-Response
図32：認証資格情報のメッセージのフローリクエスト応答
Request:
Header: POST (Code=0.02)
Uri-Host: "kdc.example.com"
Uri-Path: "ace-group"
Uri-Path: "g1"
Uri-Path: "nodes"
Uri-Path: "c101"
Uri-Path: "cred"
Content-Format: 261 (application/ace-groupcomm+cbor)
Payload (in CBOR diagnostic notation):
{
/ client_cred / 5: h'a2026008a101a501020241fc20012158
20bac5b11cad8f99f9c72b05cf4b9e26
d244dc189f745228255a219a86d6a09e
ff22582020138bf82dc1b6d562be0fa5
4ab7804a3a64b6d72ccfed6b6fb6ed28
bbfc117e',
/ cnonce / 6: h'0446baefc56111bf',
/ client_cred_verify / 24: h'e2aeafd40d69d19dfe6e52077c5d7ff4
e408282cbefb5d06cbf414af2e19d982
ac45ac98b8544c908b4507de1e90b717
c3d34816fe926a2b98f53afd2fa0f30a'
}
Response:
Header: Changed (Code=2.04)
Figure 33: Example of Authentication Credential Update Request-Response
図33：認証資格情報の更新リクエスト応答の例
Additionally, after updating its own authentication credential, a group member MAY send to the group a number of requests, including an identifier of the updated authentication credential, to notify other group members that they have to retrieve it. How this is done depends on the group communication protocol used and therefore is application profile specific (OPT13).
さらに、独自の認証資格情報を更新した後、グループメンバーは、更新された認証資格情報の識別子を含む多くのリクエストをグループに送信して、他のグループメンバーにそれを取得する必要があることを通知することができます。これがどのように行われるかは、使用されるグループ通信プロトコルに依存するため、アプリケーションプロファイル固有です（OPT13）。
A Client identified by NODENAME may be removed from a group identified by GROUPNAME where it is a member, for example, due to the following reasons.
nodenameによって識別されたクライアントは、以下の理由により、グループ名によって識別されたグループから識別されたグループから削除される場合があります。
1. The Client explicitly asks to leave the group, as defined in Section 4.8.3.1.
1. クライアントは、セクション4.8.3.1で定義されているように、グループを離れるように明示的に求めています。
2. The node has been found compromised or is suspected so. The KDC is expected to determine that a group member has to be evicted either through its own means or based on information that it obtains from a trusted source (e.g., an Intrusion Detection System or an issuer of authentication credentials). Additional mechanics, protocols, and interfaces at the KDC that can support this are out of the scope of this document.
2. ノードは侵害されていると判断されているか、疑わしい。KDCは、グループメンバーがそれ自体の手段を通じて、または信頼できるソース（侵入検知システムまたは認証資格の発行者など）から取得した情報に基づいて、またはそれが取得した情報に基づいて立ち退かなければならないと判断することが期待されています。これをサポートできるKDCの追加のメカニズム、プロトコル、およびインターフェイスは、このドキュメントの範囲外です。
3. The Client's authorization to be a group member with the current roles is not valid anymore, i.e., the access token has expired or has been revoked. If the AS provides token introspection (see Section 5.9 of [RFC9200]), the KDC can optionally use it and check whether the Client is still authorized.
3. 現在の役割を持つグループメンバーになるというクライアントの承認はもはや有効ではありません。つまり、アクセストークンの有効期限が切れているか、取り消されています。ASがトークン内省（[RFC9200]のセクション5.9を参照）を提供する場合、KDCはオプションで使用して、クライアントがまだ許可されているかどうかを確認できます。
In all cases, the KDC performs the following actions.
すべての場合において、KDCは次のアクションを実行します。
* The KDC removes the Client from the list of current members of the group. When doing so, the KDC deletes the currently stored value of 'clientchallenge' for that Client, which was specified in the latest Join Request that the Client sent to the KDC in order to join the group (see Section 4.3.1).
* KDCは、グループの現在のメンバーのリストからクライアントを削除します。その場合、KDCは、そのクライアントの現在保存されている「クライアントチャレンジ」の値を削除します。これは、グループに参加するためにクライアントがKDCに送信した最新の参加要求で指定されました（セクション4.3.1を参照）。
* In case of forced eviction, i.e., for cases 2 and 3 above, the KDC deletes the authentication credential of the removed Client if it acts as a repository of authentication credentials for group members.
* 強制的な立ち退きの場合、つまり上記のケース2および3の場合、KDCは、グループメンバーの認証資格情報のリポジトリとして機能する場合、削除されたクライアントの認証資格情報を削除します。
* If the removed Client is registered as an observer of the group-membership resource at /ace-group/GROUPNAME, the KDC removes the Client from the list of observers of that resource.
* 削除されたクライアントが /ace-group /groupNameでグループメンバーシップリソースの観察者として登録されている場合、KDCはそのリソースのオブザーバーのリストからクライアントを削除します。
* If the sub-resource /nodes/NODENAME was created for the removed Client, the KDC deletes that sub-resource.
* 削除されたクライアント用にサブリソース /ノード /node /nodenameが作成された場合、KDCはサブリソースを削除します。
In case of forced eviction, i.e., for cases 2 and 3 above, the KDC MAY explicitly inform the removed Client by means of the following methods.
強制的な立ち退きの場合、つまり、上記のケース2および3の場合、KDCは、次の方法で削除されたクライアントに明示的に通知する場合があります。
- If the evicted Client implements the 'control_uri' resource (see Section 4.3.1), the KDC sends a DELETE request to that resource, targeting the URI specified in the 'control_uri' parameter of the Join Request (see Section 4.3.1).
- 追い出されたクライアントが「control_uri」リソースを実装している場合（セクション4.3.1を参照）、KDCはそのリソースに削除要求を送信し、参加要求の「control_uri」パラメーターで指定されたURIをターゲットにします（セクション4.3.1を参照）。
- If the evicted Client is observing its associated sub-resource at /ace-group/GROUPNAME/nodes/NODENAME (see Section 4.8.1), the KDC sends an unsolicited 4.04 (Not Found) error response, which does not include the Observe Option and indicates that the observed resource has been deleted (see Section 3.2 of [RFC7641]).
- 立ち退きを受けたクライアントが、それに関連するサブリソースで/ace-group/groupName/nodes/nodenameを観察している場合（セクション4.8.1を参照）、KDCは未承諾4.04（見つかりません）エラー応答を送信します。観測されたリソースが削除されていることを示します（[RFC7641]のセクション3.2を参照）。
The response MUST have Content-Format "application/concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 5 ("Group membership terminated").
応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は5（「グループメンバーシップが終了しました」）に設定する必要があります。
* If forward security is prescribed by application policies installed at the KDC or by the used application profile of this specification, then the KDC MUST generate new group keying material and securely distribute it to all the current group members except the leaving node (see Section 6).
* KDCにインストールされたアプリケーションポリシーまたはこの仕様の使用済みアプリケーションプロファイルによって処方されている場合、KDCは新しいグループキーイングマテリアルを生成し、去るノードを除くすべての現在のグループメンバーに安全に配布する必要があります（セクション6を参照）。
A group rekeying is started and driven by the KDC. The KDC is not intended to accommodate explicit requests from group members to trigger a group rekeying. That is, the scheduling and execution of a group rekeying is an exclusive prerogative of the KDC. Some reasons that can trigger a group rekeying include a change in the group membership, the current group keying material approaching its expiration time, or a regularly scheduled update of the group keying material.
グループの再キーイングが開始され、KDCによって駆動されます。KDCは、グループメンバーからの明示的なリクエストに対応することを意図していません。つまり、グループの再キーイングのスケジューリングと実行は、KDCの排他的な特権です。グループの再キーイングをトリガーできるいくつかの理由には、グループメンバーシップの変更、有効期限に近づく現在のグループキーイング素材、またはグループキーイングマテリアルの定期的にスケジュールされた更新が含まれます。
The KDC can perform a group rekeying before the current group keying material expires, unless it is acceptable or there are reasons to temporarily pause secure communications in the group, following the expiration of the current keying material. For example, a pause in the group communication might have been scheduled to start anyway when the group keying material expires, e.g., to allow maintenance operations on the group members. As another example, the KDC might be carrying out a verification that some group members are seemingly compromised and to be evicted, and this needs to be completed in order to appropriately define and schedule the exact rekeying process to perform. As a result, the KDC could delay the execution of the group rekeying.
KDCは、現在のグループキーイング素材が許容されない場合を除き、現在のグループのキーイング材料が期限切れになる前に、グループ内の安全な通信を一時的に一時停止する理由がない限り、再キーイングを実行することができます。たとえば、グループのキーイング素材が期限切れになったときに、グループ通信の一時停止がとにかく開始するようにスケジュールされている可能性があります。たとえば、グループメンバーのメンテナンス操作を許可します。別の例として、KDCは、一部のグループメンバーが一見妥協しており、追い出されるようになるという検証を実施している可能性があります。その結果、KDCはグループの再キーイングの実行を遅らせる可能性があります。
The KDC MUST increment the version number NUM of the current keying material before distributing the newly generated keying material with version number NUM+1 to the group. Once the group rekeying is completed, the KDC MUST delete the old keying material and SHOULD store the newly distributed keying material in persistent storage.
KDCは、新しく生成されたキーイング材料をグループに配布する前に、現在のキーイング材料のバージョン番号番号を増分する必要があります。グループの再キーイングが完了したら、KDCは古いキーイング素材を削除し、新しく分散したキーイング材料を永続的なストレージに保存する必要があります。
Distributing the new group keying material requires the KDC to send multiple rekeying messages to the group members. Depending on the rekeying scheme used in the group and the reason that has triggered the rekeying process, each rekeying message can be intended for one or multiple group members, hereafter referred to as target group members. The KDC MUST support at least the "Point-to-Point" group rekeying scheme described in Section 6.1 and MAY support additional ones.
新しいグループキーイングマテリアルを配布するには、KDCがグループメンバーに複数の再キーイングメッセージを送信する必要があります。グループで使用されている再キーイングスキームと、再キーイングプロセスをトリガーした理由に応じて、それぞれの再キーイングメッセージは、ターゲットグループメンバーと呼ばれる1人または複数のグループメンバーを対象としています。KDCは、少なくともセクション6.1で説明されている「ポイントツーポイント」グループの再キーイングスキームをサポートする必要があり、追加のグループをサポートする場合があります。
Each rekeying message MUST have Content-Format "application/ace-groupcomm+cbor" and its payload is formatted as a CBOR map, which MUST include at least the information specified in the Key Distribution Response message (see Section 4.3.2), i.e., the parameters 'gkty', 'key', and 'num' defined in Section 4.3.1. The CBOR map SHOULD also include the parameters 'exp' and 'exi'. If the 'exp' parameter is included, the 'exi' parameter MUST also be included. The CBOR map MAY include the parameter 'mgt_key_material' to specify new administrative keying material for the target group members if it is relevant for the used rekeying scheme.
各再キーイングメッセージには、コンテンツフォーマット「Application/Ace-GroupComm+CBOR」が必要であり、そのペイロードはCBORマップとしてフォーマットされています。、セクション4.3.1で定義されているパラメーター「Gkty」、「キー」、および「num」。CBORマップには、パラメーター「EXP」と「EXI」も含める必要があります。「EXP」パラメーターが含まれている場合、「EXI」パラメーターも含める必要があります。CBORマップには、使用済みの再キーイングスキームに関連する場合は、ターゲットグループメンバーの新しい管理キーイング資料を指定するパラメーター「MGT_KEY_MATIRIAL」を含めることができます。
A rekeying message may include additional information, depending on the rekeying scheme used in the group, the reason that has triggered the rekeying process, and the specific target group members. In particular, if the group rekeying is performed due to one or multiple Clients that have joined the group and the KDC acts as a repository of authentication credentials of the group members, then a rekeying message MAY also include the authentication credentials that those Clients use in the group, together with the roles and node identifier that each of such Clients has in the group. It is RECOMMENDED to specify this information by means of the parameters 'creds', 'peer_roles', and 'peer_identifiers', like it is done in the Join Response message (see Section 4.3.1).
再キーイングメッセージには、グループで使用される再キーイングスキーム、再キーイングプロセスをトリガーした理由、および特定のターゲットグループメンバーに応じて、追加情報が含まれる場合があります。特に、グループに参加した1人または複数のクライアントがグループに参加し、KDCがグループメンバーの認証資格情報のリポジトリとして機能するため、グループの再キーイングが実行される場合、リクイーメッセージには、クライアントが使用する認証資格情報も含まれる場合があります。グループは、そのようなクライアントのそれぞれがグループに持っている役割とノード識別子とともに。パラメーター「クレジット」、「PEER_ROLES」、および「PEER_IDENTIFIERS」を使用してこの情報を指定することをお勧めします。
The complete format of a rekeying message, including the encoding and content of the 'mgt_key_material' parameter, has to be defined in separate specifications aimed at profiling the used rekeying scheme in the context of the used application profile of this specification. As a particular case, an application profile of this specification MAY define additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme defined in Section 6.1 (OPT14).
「MGT_Key_Material」パラメーターのエンコードとコンテンツを含む、再キーイングメッセージの完全な形式は、この仕様の使用されるアプリケーションプロファイルのコンテキストで使用されている再キーイングスキームをプロファイリングすることを目的とした個別の仕様で定義する必要があります。特定のケースとして、この仕様のアプリケーションプロファイルは、セクション6.1（OPT14）で定義されている「ポイントツーポイント」グループの再キーイングスキームのメッセージを再キーにすることに含める追加情報を定義する場合があります。
Consistently with the used group rekeying scheme, the actual delivery of rekeying messages can occur through different approaches, as discussed in Sections 6.1 and 6.2.
中古グループの再キーイングスキームと一貫して、セクション6.1および6.2で説明するように、異なるアプローチで再キーイングメッセージの実際の配信が発生する可能性があります。
The possible, temporary misalignment of the keying material stored by the different group members due to a group rekeying is discussed in Section 6.3. Further security considerations related to the group rekeying process are compiled in Section 10.2.
グループの再キーイングによるさまざまなグループメンバーによって保存されているキーイング材料の可能性のある一時的な不整合については、セクション6.3で説明します。グループの再キーイングプロセスに関連するさらなるセキュリティ上の考慮事項は、セクション10.2にまとめられています。
A point-to-point group rekeying consists in the KDC sending one individual rekeying message to each target group member. In particular, the rekeying message is protected by means of the secure communication association between the KDC and the target group member in question, as per the used application profile of this specification and the used transport profile of ACE.
ポイントツーポイントグループの再キーイングは、KDCで構成されており、各ターゲットグループメンバーに1人の個別の再キーイングメッセージを送信します。特に、この仕様の使用済みアプリケーションプロファイルとACEの使用済み輸送プロファイルによると、再キーイングメッセージは、問題のKDCとターゲットグループメンバーとの間の安全な通信関連によって保護されます。
This is the approach taken by the basic "Point-to-Point" group rekeying scheme, which the KDC can explicitly indicate in the Join Response (see Section 4.3.1), through the 'rekeying_scheme' parameter specifying the value 0.
これは、基本的な「ポイントツーポイント」グループの再キーイングスキームによって行われるアプローチであり、KDCは、値0を指定する「Rekeying_scheme」パラメーターを介して、結合応答で明示的に示すことができます（セクション4.3.1を参照）。
When taking this approach in the group identified by GROUPNAME, the KDC can practically deliver the rekeying messages to the target group members in different, coexisting ways.
GroupNameで識別されたグループでこのアプローチを取ると、KDCは、異なる、共存する方法でターゲットグループメンバーに再キーイングメッセージを実際に配信できます。
* The KDC SHOULD make the /ace-group/GROUPNAME resource observable [RFC7641]. Thus, upon performing a group rekeying, the KDC can distribute the new group keying material through individual notification responses sent to the target group members that are also observing that resource.
* KDCは、 /ace-group /groupNameリソースを観察可能にする必要があります[RFC7641]。したがって、グループが再キーになっているグループを実行すると、KDCは、そのリソースを観察しているターゲットグループメンバーに送信された個々の通知応答を通じて、新しいグループキーイング素材を配布できます。
In case the KDC deletes the group (and thus deletes the /ace-group/GROUPNAME resource), relying on CoAP Observe as discussed above also allows the KDC to send an unsolicited 4.04 (Not Found) response to each observer group member as a notification of group termination. The response MUST have Content-Format "application/ concise-problem-details+cbor" and is formatted as defined in Section 4.1.2. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 6 ("Group deleted").
KDCがグループを削除し（したがって /ace-group /groupNameリソースを削除する場合）、上記のようにCOAP観測に依存すると、KDCは各オブザーバーグループメンバーに通知として各オブザーバーグループメンバーに未承諾の4.04（発見されていない）応答を送信できます。グループ終了の。応答には、コンテンツフォーマット「アプリケーション/簡潔な問題」が必要である必要があり、セクション4.1.2で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「Ace-GroupComm-Error」内で、「エラーID」フィールドの値は6（「グループ削除」）に設定する必要があります。
* If a target group member specified a URI in the 'control_uri' parameter of the Join Request upon joining the group (see Section 4.3.1), the KDC can provide that group member with the new group keying material by sending a unicast POST request to that URI.
* ターゲットグループメンバーが、グループに参加したときに参加要求の「control_uri」パラメーターでURIを指定した場合（セクション4.3.1を参照）、KDCはユニキャストポストリクエストを送信することにより、そのグループメンバーに新しいグループキーイング素材を提供できます。あのuri。
A Client that does not plan to observe the /ace-group/GROUPNAME resource at the KDC SHOULD specify a URI in the 'control_uri' parameter of the Join Request upon joining the group.
KDCで /ace-group /groupNameリソースを遵守する予定のクライアントは、グループに参加すると、参加要求の「control_uri」パラメーターにURIを指定する必要があります。
If the KDC has to send a rekeying message to a target group member, but this did not include the 'control_uri' parameter in the Join Request and is not a registered observer for the /ace-group/GROUPNAME resource, then that target group member will not be able to participate in the group rekeying. Later on, after having repeatedly failed to successfully exchange secure messages in the group, that group member can retrieve the current group keying material from the KDC, by sending a GET request to the /ace-group/GROUPNAME or /ace-group/GROUPNAME/nodes/NODENAME resource at the KDC (see Sections 4.3.2 and 4.8.1, respectively).
KDCがターゲットグループメンバーに再キーイングメッセージを送信する必要がありますが、これには参加要求に「control_uri」パラメーターが含まれておらず、 /ace-group /groupNameリソースの登録オブザーバーではない場合、そのターゲットグループメンバーグループの再キーイングに参加することはできません。後で、グループ内の安全なメッセージを繰り返し交換できなかった後、そのグループメンバーは、 /ace-group /groupnameまたは /ace-group /groupNameにGETリクエストを送信することにより、KDCから現在のグループキーイング資料を取得できます。/nodes/nodenameリソースKDCのリソース（それぞれセクション4.3.2と4.8.1を参照）。
Figure 34 provides an example of point-to-point group rekeying. In particular, the example makes the following assumptions:
図34は、ポイントツーポイントグループの再キーイングの例を示しています。特に、この例は次の仮定を作成します。
* The group currently consists of four group members, namely C1, C2, C3, and C4.
* このグループは現在、4人のグループメンバー、すなわちC1、C2、C3、およびC4で構成されています。
* Each group member, when joining the group, provided the KDC with a URI in the 'control_uri' parameter with url-path "grp-rek".
* 各グループメンバーは、グループに参加するときに、URL-PATH「GRP-REK」を使用した「Control_uri」パラメーターのURIをKDCに提供しました。
* Before the group rekeying is performed, the keying material used in the group has version number num=5.
* グループの再キーイングが実行される前に、グループで使用されるキーイング素材にはバージョン番号num = 5があります。
* The KDC performs the group rekeying in such a way to evict the group member C3, which has been found to be compromised.
* KDCは、グループメンバーC3を追い出すような方法で再キーイングを実行します。
In the example, the KDC individually rekeys the group members intended to remain in the group (i.e., C1, C2, and C4) by means of one rekeying message each.
この例では、KDCは、それぞれのメッセージを再キーイングすることにより、グループ（すなわち、C1、C2、およびC4）に留まることを意図したグループメンバーを個別に再キーします。
.----------------------------------------------------------------.
| KDC |
'----------------------------------------------------------------'
| | |
Group | Group | Group |
keying | keying | keying |
material | material | material |
(num=6) | (num=6) | (num=6) |
| | |
| | |
| | |
v v v
/grp-rek /grp-rek /grp-rek /grp-rek
.--------. .--------. .--------. .--------.
| C1 | | C2 | | C3 | | C4 |
'--------' '--------' '--------' '--------'
[TO BE EVICTED]
| |
\____________ Stored group keying material (num=5) _____________/
Figure 34: Example of Message Exchanges for a Point-to-Point Group Rekeying
図34：ポイントツーポイントグループのメッセージ交換の例
This section provides high-level recommendations on how the KDC can rekey a group by means of a more efficient and scalable group rekeying scheme, e.g., [RFC2093], [RFC2094], and [RFC2627]. That is, each rekeying message might be, and likely is, intended for multiple target group members, and thus can be delivered to the whole group, although possible to decrypt only for the actual target group members.
このセクションでは、KDCがより効率的でスケーラブルなグループの再キーイングスキームを使用して、[RFC2093]、[RFC2094]、および[RFC2627]を使用して、KDCがどのようにグループを再キーできるかについての高レベルの推奨事項を提供します。つまり、各ターゲットグループメンバーを対象としている可能性があり、実際のターゲットグループメンバーのみを解読することは可能ですが、複数のターゲットグループメンバーを対象としている可能性があり、したがって、グループ全体に配信できます。
This yields an overall lower number of rekeying messages, thus potentially reducing the overall time required to rekey the group. On the other hand, it requires the KDC to provide and use additional administrative keying material to protect the rekeying messages and to additionally sign them to ensure source authentication (see Section 6.2.1).
これにより、全体的な数が少ないメッセージが生成されるため、グループを再キーするのに必要な全体の時間を潜在的に短縮します。一方、KDCは、再キーイングメッセージを保護し、ソース認証を確保するために追加の署名するために追加の管理キーイング資料を提供および使用する必要があります（セクション6.2.1を参照）。
Compared to a group rekeying performed in a point-to-point fashion (see Section 6.1), a one-to-many group rekeying typically pays off in large-scale groups due to the reduced time for completing the rekeying, a more efficient utilization of network resources, and a reduced performance overhead at the KDC. To different extents, it also requires individual group members to locally perform additional operations in order to handle the administrative keying material and verify source authentication of rekeying messages. Therefore, one-to-many group rekeying schemes and their employment ought to ensure that the experienced performance overhead on the group members also remains bearable for resource-constrained devices.
ポイントツーポイントで実行されたグループの再キーイングと比較して（セクション6.1を参照）、1対多数のグループが通常、再キーイングを完了するための時間が短縮されたため、より効率的な利用を完了するために大規模なグループで報われますネットワークリソースの、KDCでのパフォーマンスオーバーヘッドの削減。また、さまざまな範囲に、個々のグループメンバーは、管理キーイング素材を処理し、メッセージの再キーイングのソース認証を検証するために、追加の操作をローカルに実行する必要があります。したがって、1対多数のグループがスキームとその雇用を再キーニングすることは、グループメンバーの経験豊富なパフォーマンスがリソースに制約のあるデバイスにも耐えられることを保証する必要があります。
The exact set of rekeying messages to send, their content and format, the administrative keying material to use to protect them, as well as the set of target group members depend on the specific group rekeying scheme and are typically affected by the reason that has triggered the group rekeying. Details about the data content and format of rekeying messages have to be defined by separate documents profiling the use of the group rekeying scheme in the context of the used application profile of this specification.
送信するメッセージの正確なセット、そのコンテンツとフォーマット、それらを保護するために使用する管理キーイング資料、およびターゲットグループメンバーのセットは、特定のグループの再キーイングスキームに依存し、通常トリガーされた理由によって影響を受けるグループは再キーイングします。メッセージのコンテンツと再キーイングメッセージの形式に関する詳細は、この仕様の使用されているアプリケーションプロファイルのコンテキストで、グループの再キーイングスキームの使用をプロファイリングする個別のドキュメントで定義する必要があります。
When one of these group rekeying schemes is used, the KDC provides related information to a Client joining the group in the Join Response message (see Section 4.3.1). In particular, the 'rekeying_scheme' parameter indicates the rekeying scheme used in the group (if no default scheme can be assumed); the 'control_group_uri' parameter, if present, specifies a URI whose addressing information is, e.g., a multicast IP address where the KDC will send the rekeying messages for that group as intended to reach all the group members; and the 'mgt_key_material' parameter specifies a subset of the administrative keying material intended for that particular joining Client to have, as used to protect the rekeying messages sent to the group when also intended for that joining Client.
これらのグループの1つの1つがスキームを使用している場合、KDCは、結合応答メッセージにグループに参加するクライアントに関連情報を提供します（セクション4.3.1を参照）。特に、「rekeying_scheme」パラメーターは、グループで使用される再キーイングスキームを示します（デフォルトスキームが想定されない場合）。「control_group_uri」パラメーターは、存在する場合、アドレス指定情報が、たとえば、すべてのグループメンバーに到達することを目的としたそのグループの再キーイングメッセージを送信するマルチキャストIPアドレスなどのURIを指定します。また、「MGT_KEY_MATIRALIAL」パラメーターは、その特定の参加クライアントが参加することを意図しているため、グループに送信されたグループに送信されたメッセージを保護するために使用されるように、その特定の参加を意図した管理キーイング資料のサブセットを指定します。
Rekeying messages can be protected at the application layer by using COSE [RFC9052] and the administrative keying material as prescribed by the specific group rekeying scheme (see Section 6.2.1). After that, the delivery of protected rekeying messages to the intended target group members can occur in different ways, such as the following ones.
COSE [RFC9052]および特定のグループの再キーイングスキームで規定されている管理キーイング資料を使用して、アプリケーションレイヤーでメッセージを再キー化できます（セクション6.2.1を参照）。その後、意図したターゲットグループメンバーへの保護された再キーイングメッセージの配信は、次のようなさまざまな方法で発生する可能性があります。
Over multicast -
オーバーマルチキャスト -
In this case, the KDC simply sends a rekeying message as a CoAP request addressed to the URI specified in the 'control_group_uri' parameter of the Join Response (see Section 4.3.1).
この場合、KDCは、結合応答の「control_group_uri」パラメーターで指定されたURIに宛てられたCOAPリクエストとして再キーイングメッセージを送信するだけです（セクション4.3.1を参照）。
If a particular rekeying message is intended for a single target group member, the KDC may alternatively protect the message using the secure communication association with that group member and deliver the message like when using the "Point-to-Point" group rekeying scheme (see Section 6.1).
特定の再キーイングメッセージが単一のターゲットグループメンバーを対象としている場合、KDCは、そのグループメンバーとの安全な通信関連を使用してメッセージを保護し、「ポイントツーポイント」グループの再キーイングスキームを使用する場合のようなメッセージを配信することができます（参照セクション6.1）。
Through a pub-sub communication model -
パブサブ通信モデルを通じて -
In this case, the KDC acts as a publisher and publishes each rekeying message to a specific "rekeying topic", which is associated with the group and is hosted at a Broker server. Following their group joining, the group members subscribe to the rekeying topic at the Broker, thus receiving the group rekeying messages as they are published by the KDC.
この場合、KDCはパブリッシャーとして機能し、グループに関連付けられ、ブローカーサーバーでホストされている特定の「再キーイングトピック」に各再キーイングメッセージを公開します。グループへのグループに続いて、グループメンバーはブローカーでの再キーイングトピックを購読し、KDCが公開している間、グループを再キーイングするグループを受信します。
In order to make such message delivery more efficient, the rekeying topic associated with a group can be further organized into subtopics. For instance, the KDC can use a particular subtopic to address a particular set of target group members during the rekeying process as possibly aligned to a similar organization of the administrative keying material (e.g., a key hierarchy).
このようなメッセージ配信をより効率的にするために、グループに関連する再キーイングトピックをサブトピックにさらに編成できます。たとえば、KDCは特定のサブトピックを使用して、再キーイングプロセス中に特定のターゲットグループメンバーに対処できます。
The setup of rekeying topics at the Broker as well as the discovery of the topics at the Broker for group members are application specific. A possible way is for the KDC to provide such information in the Join Response message (see Section 4.3.1) by means of a new parameter analogous to 'control_group_uri' and specifying the URI(s) of the rekeying topic(s) that a group member has to subscribe to at the Broker.
ブローカーでのトピックを再キーニングするセットアップと、グループメンバーのブローカーでのトピックの発見は、アプリケーション固有です。可能な方法は、KDCが「control_group_uri」に類似した新しいパラメーターを使用して、結合応答メッセージ（セクション4.3.1を参照）にそのような情報を提供することと、再キーイングトピックのURI（s）のURIを指定することです。グループメンバーは、ブローカーで購読する必要があります。
Regardless of the specifically used delivery method, the group rekeying scheme can perform a possible rollover of the administrative keying material through the same sent rekeying messages. Actually, such a rollover occurs every time a group rekeying is performed upon the leaving of group members, which have to be excluded from future communications in the group.
特別に使用される配信方法に関係なく、グループの再キーイングスキームは、同じ送信された再キーイングメッセージを介して管理キーイング資料のロールオーバーを実行できます。実際、このようなロールオーバーは、グループのメンバーの退職時にグループの再キーイングが実行されるたびに発生します。これは、グループ内の将来のコミュニケーションから除外する必要があります。
From a high-level point of view, each group member stores only a subset of the overall administrative keying material, which is obtained upon joining the group. Then, when a group rekeying occurs:
高レベルの観点から、各グループメンバーは、グループに参加すると取得される全体的な管理キーイング素材のサブセットのみを保存します。次に、グループの再キーイングが発生したとき：
* Each rekeying message is protected by using a (most convenient) key from the administrative keying material such that: i) the used key is not stored by any node leaving the group, i.e., the key is safe to use and does not have to be renewed; and ii) the used key is stored by all the target group members that indeed have to be provided with new group keying material to protect communications in the group.
* 各再キーイングメッセージは、次のような管理キーイング素材から（最も便利な）キーを使用して保護されます。i）使用済みキーは、グループを離れるノードによって保存されません。つまり、キーは安全であり、使用する必要はありません。更新;ii）使用済みキーは、グループ内のコミュニケーションを保護するために実際に新しいグループキーイング素材を提供する必要があるすべてのターゲットグループメンバーによって保存されます。
* Each rekeying message includes not only the new group keying material intended for all the rekeyed group members but also any new administrative keys that: i) are pertaining to and supposed to be stored by the target group members; and ii) had to be updated because leaving group members do store the previous version.
* 各再キーイングメッセージには、すべての再キーインググループメンバーを対象とした新しいグループキーイングマテリアルだけでなく、次の新しい管理キーも含まれます。ii）グループメンバーが以前のバージョンを保存するため、更新する必要がありました。
Further details depend on the specific rekeying scheme used in the group.
詳細は、グループで使用される特定の再キーイングスキームによって依存します。
Figure 35 provides an example of a one-to-many group rekeying over multicast. In particular, the example makes the following assumptions:
図35は、マルチキャストを繰り返している1対多数のグループの例を示しています。特に、この例は次の仮定を作成します。
* The group currently consists of four group members, namely C1, C2, C3, and C4.
* このグループは現在、4人のグループメンバー、すなわちC1、C2、C3、およびC4で構成されています。
* Each group member, when joining the group, provided the KDC with a URI in the 'control_uri' parameter with url-path "grp-rek".
* 各グループメンバーは、グループに参加するときに、URL-PATH「GRP-REK」を使用した「Control_uri」パラメーターのURIをKDCに提供しました。
* Each group member, when joining the group, received from the KDC a URI in the 'control_group_uri' parameter, specifying the multicast address MULT_ADDR and url-path "grp-mrek".
* 各グループメンバーは、グループに参加するときに、KDCから「control_group_uri」パラメーターでURIを受け取り、マルチキャストアドレスMult_addrとURL-Path "GRP-MREK"を指定しました。
* Before the group rekeying is performed, the keying material used in the group has version number num=5.
* グループの再キーイングが実行される前に、グループで使用されるキーイング素材にはバージョン番号num = 5があります。
* The KDC performs the group rekeying in such a way to evict the group member C3, which has been found to be compromised.
* KDCは、グループメンバーC3を追い出すような方法で再キーイングを実行します。
In the example, the KDC determines that the most convenient way to perform a group rekeying that evicts C3 is as follows.
この例では、KDCは、C3を追い出すグループを実行するグループを実行する最も便利な方法が次のとおりであると判断します。
First, the KDC sends one rekeying message over multicast to the multicast address MULT_ADDR and the url-path "grp-mrek". In the figure, the message is denoted with solid arrows. The message is protected with a non-compromised key from the administrative keying material that only C1 and C2 store. Therefore, even though all the group members receive this message, only C1 and C2 are able to decrypt it. The message includes: the new group keying material with version number num=6 and new keys from the administrative keying material to replace those stored by the group members C1, C2, and C3.
最初に、KDCはマルチキャストを介してマルチキャストアドレスMult_AddrとURL-Path「GRP-MREK」に1つの再キーイングメッセージを送信します。図では、メッセージは固体矢印で示されています。このメッセージは、C1とC2のみが保存する管理キーイング資料の非妥協のキーで保護されています。したがって、すべてのグループメンバーがこのメッセージを受け取っていても、C1とC2のみがそれを解読することができます。メッセージには、グループメンバーC1、C2、およびC3が保存しているものを置き換えるために、バージョン番号num = 6と管理キーイング素材の新しいキーを備えた新しいグループキーイング素材が含まれます。
After that, the KDC sends one rekeying message addressed individually to C4 and with url-path "grp-rek". In the figure, the message is denoted with a dotted arrow. The message is protected with the secure association shared between C4 and the KDC. The message includes: the new group keying material with version number num=6 and new keys from the administrative keying material to replace those stored by both C4 and C3.
その後、KDCは、c4に個別にアドレス指定された1つの再キーイングメッセージを、url-path "grp-rek"で送信します。図では、メッセージは点線の矢印で示されています。このメッセージは、C4とKDCの間で共有される安全な関連付けで保護されています。メッセージには、バージョン番号num = 6の新しいグループキーイング素材と、C4とC3の両方が保存したものを置き換えるための管理キーイング素材の新しいキーが含まれます。
.---------------------------------------------------------------------.
| KDC |
'---------------------------------------------------------------------'
| :
* Group keying material (num=6) | * Group keying :
* Updated administrative | material (num=6) :
keying material for C1 and C2 | * Updated administrative :
| keying material for C4 :
| :
| :
+------------+-------------+--------------+ :
| | | | :
| | | | :
v v v v v
/grp-mrek /grp-mrek /grp-mrek /grp-mrek /grp-rek
.--------. .--------. .-----------. .---------------------------.
| C1 | | C2 | | C3 | | C4 |
'--------' '--------' '-----------' '---------------------------'
[TO BE EVICTED]
| |
\_______________ Stored group keying material (num=5) ________________/
Figure 35: Example of Message Exchanges for a One-to-Many Group Rekeying
図35：1対多くのグループが再キーリングするためのメッセージ交換の例
When using a group rekeying scheme relying on one-to-many rekeying messages, the actual data content of each rekeying message is prepared according to what the rekeying scheme prescribes.
1対多くの再キーイングメッセージに依存してグループの再キーイングスキームを使用する場合、各再キーイングメッセージの実際のデータコンテンツは、再キーイングスキームが規定するものに従って作成されます。
The following describes one possible method for the KDC to protect the rekeying messages when using the administrative keying material.
以下は、KDCが管理キーイング資料を使用するときに再キーイングメッセージを保護するための1つの可能な方法を説明しています。
The method assumes that the following holds for the administrative keying material specified in the 'mgt_key_material' parameter of the Join Response (see Section 4.3.1).
この方法では、結合応答の「MGT_KEY_MATIRIAL」パラメーターで指定された管理キーイング資料については、以下が保持されると想定しています（セクション4.3.1を参照）。
* The encryption algorithm SHOULD be the same one used to protect communications in the group.
* 暗号化アルゴリズムは、グループ内の通信を保護するために使用されるものと同じである必要があります。
* The included symmetric encryption keys are accompanied by a corresponding and unique key identifier assigned by the KDC.
* 含まれる対称暗号化キーには、KDCによって割り当てられた対応する一意のキー識別子が添付されます。
* A Base IV is also included with the same size of the AEAD nonce considered by the encryption algorithm to use.
* ベースIVは、使用する暗号化アルゴリズムで考慮されるAEADノンセの同じサイズにも含まれています。
First, the KDC computes a COSE_Encrypt0 object as follows.
まず、KDCは次のようにCOSE_ENCRYPT0オブジェクトを計算します。
* The encryption key to use is selected from the administrative keying material, as defined by the rekeying scheme used in the group.
* 使用する暗号化キーは、グループで使用される再キーイングスキームで定義されているように、管理キーイング素材から選択されます。
* The plaintext is the actual data content of the current rekeying message.
* プレーンテキストは、現在の再キーイングメッセージの実際のデータコンテンツです。
* The Additional Authenticated Data (AAD) is empty unless otherwise specified by separate documents profiling the use of the group rekeying scheme.
* 追加の認証データ（AAD）は、グループの再キーイングスキームの使用をプロファイリングする個別のドキュメントで特に指定されていない限り空になります。
* Since the KDC is the only sender of rekeying messages, the AEAD nonce can be computed as follows, where NONCE_SIZE is the size in bytes of the AEAD nonce. Separate documents profiling the use of the group rekeying scheme may define alternative ways to compute the AEAD nonce.
* KDCはメッセージの再キーイングの唯一の送信者であるため、AEAD Nonceは次のように計算できます。非CE_SIZEはAEAD NonCeのバイトのサイズです。グループ再キーイングスキームの使用をプロファイリングする個別のドキュメントは、AEAD Nonceを計算する代替方法を定義する場合があります。
The KDC considers the following values.
KDCは次の値を考慮します。
- COUNT: as a 2-byte unsigned integer associated with the used encryption key. Its value is set to 0 when starting to perform a new group rekeying instance and is incremented after each use of the encryption key.
- Count：使用済みの暗号化キーに関連付けられた2バイトの符号なし整数として。その値は、新しいグループの再キーイングインスタンスの実行を開始するときに0に設定され、暗号化キーを使用するたびにインクリメントされます。
- NEW_NUM: as the version number of the new group keying material to distribute in this rekeying instance, left-padded with zeros to exactly NONCE_SIZE - 2 bytes.
- New_num：この再キーイングインスタンスで配布する新しいグループキーイング素材のバージョン番号として、Zerosで左パドで正確にnonce_size -2バイト。
Then, the KDC computes a Partial IV as the byte string concatenation of COUNT and NEW_NUM in this order. Finally, the AEAD nonce is computed as the XOR between the Base IV and the Partial IV.
次に、KDCは、この順序でカウントとnew_Numのバイト文字列の連結として部分的なIVを計算します。最後に、AEADノンセは、ベースIVと部分IVの間のXORとして計算されます。
In order to comply with the security requirements of AEAD encryption algorithms, the KDC MUST NOT reuse the same pair (AEAD encryption key, AEAD nonce). For example, this includes not using the same encryption key from the administrative keying material more than 2^16 times during the same rekeying instance.
AEAD暗号化アルゴリズムのセキュリティ要件に準拠するために、KDCは同じペアを再利用してはなりません（AEAD暗号化キー、AEAD NONCE）。たとえば、これには、同じ再キーイングインスタンス中に、管理キーイング素材から同じ暗号化キーを2^16回以上使用しないことが含まれます。
* The protected header of the COSE_Encrypt0 object MUST include the following parameters.
* COSE_ENCRYPT0オブジェクトの保護されたヘッダーには、次のパラメーターを含める必要があります。
- 'alg': specifying the used encryption algorithm.
- 'alg'：使用している暗号化アルゴリズムの指定。
- 'kid': specifying the identifier of the encryption key from the administrative keying material used to protect the current rekeying message.
- 「Kid」：現在の再キーイングメッセージを保護するために使用される管理キーイング資料から暗号化キーの識別子を指定します。
* The unprotected header of the COSE_Encrypt0 object MUST include the 'Partial IV' parameter with the value of the Partial IV computed above.
* COSE_ENCRYPT0オブジェクトの保護されていないヘッダーには、上記の部分IVの値を持つ「部分IV」パラメーターを含める必要があります。
In order to ensure source authentication, each rekeying message protected with the administrative keying material MUST be signed by the KDC. To this end, the KDC computes a countersignature of the COSE_Encrypt0 object, as described in Sections 3.2 and 3.3 of [RFC9338]. In particular, the following applies when computing the countersignature.
ソース認証を確保するために、管理キーイング資料で保護されている各メッセージをKDCが署名する必要があります。この目的のために、KDCは[RFC9338]のセクション3.2および3.3で説明されているように、COSE_ENCRYPT0オブジェクトの副署を計算します。特に、Bountersignatureを計算するときに次のものが適用されます。
* The Countersign_structure contains the context text string "CounterSignature0".
* countersign_structureには、コンテキストテキスト文字列「countersignature0」が含まれています。
* The private key of the KDC is used as the signing key.
* KDCの秘密鍵は、署名キーとして使用されます。
* The payload is the ciphertext of the COSE_Encrypt0 object.
* ペイロードは、cose_encrypt0オブジェクトの暗号文です。
* The Additional Authenticated Data (AAD) is empty, unless otherwise specified by separate documents profiling the use of a group rekeying scheme.
* 追加の認証データ（AAD）は、グループの再キーイングスキームの使用をプロファイリングする個別のドキュメントで特に指定されていない限り、空です。
* The protected header of the signing object MUST include the parameter 'alg', which specifies the used signature algorithm.
* 署名オブジェクトの保護されたヘッダーには、使用される署名アルゴリズムを指定するパラメーター「アルグ」を含める必要があります。
If the source authentication of messages exchanged in the group is also ensured by means of signatures, then rekeying messages MUST be signed using the same signature algorithm and related parameters. Also, the KDC's authentication credential including the public key to use for signature verification MUST be provided in the Join Response through the 'kdc_cred' parameter, together with the corresponding proof-of-possession (PoP) evidence in the 'kdc_cred_verify' parameter.
グループで交換されたメッセージのソース認証も署名によって保証されている場合、同じ署名アルゴリズムと関連するパラメーターを使用してメッセージを再キューする必要があります。また、署名検証に使用する公開鍵を含むKDCの認証資格情報は、「kdc_cred_verify」パラメーターの「kdc_cred」パラメーターを介した「kdc_cred」パラメーターを介して結合応答に提供する必要があります。
If source authentication of messages exchanged in the group is not ensured by means of signatures, then the administrative keying material conveyed in the 'mgt_key_material' parameter of the Join Response sent by KDC (see Section 4.3.1) MUST also comprise a KDC's authentication credential including the public key to use for signature verification, together with the corresponding PoP evidence. Within the 'mgt_key_material' parameter, it is RECOMMENDED to specify this information by using the same format and encoding used for the parameters 'kdc_cred', 'kdc_nonce', and 'kdc_cred_verify' in the Join Response. It is up to separate documents profiling the use of the group rekeying scheme to specify such details.
グループで交換されたメッセージのソース認証が署名によって保証されていない場合、KDCが送信した結合応答の「MGT_KEY_MATTERIAL」パラメーター（セクション4.3.1を参照）で伝えられる管理キーイング資料もKDCの認証資格認定を構成する必要があります。対応するポップエビデンスとともに、署名検証に使用する公開鍵を含む。「MGT_Key_Material」パラメーター内で、パラメーター「KDC_CRED」、「KDC_NONCE」、および「KDC_CRED_VERIFY」に使用される同じ形式とエンコードを使用して、この情報を指定することをお勧めします。このような詳細を指定するために、グループの再キーイングスキームの使用をプロファイリングするドキュメントを別々にすることです。
After that, the KDC specifies the computed countersignature in the 'Countersignature0 version 2' header parameter of the COSE_Encrypt0 object.
その後、KDCは、cose_encrypt0オブジェクトの「countersignature0バージョン2」ヘッダーパラメーターで計算されたcountersignatureを指定します。
Finally, the KDC specifies the COSE_Encrypt0 object as payload of a CoAP request, which is sent to the target group members as per the used message delivery method.
最後に、KDCはCOSE_ENCRYPT0オブジェクトをCOAPリクエストのペイロードとして指定します。これは、使用済みのメッセージ配信方法に従ってターゲットグループメンバーに送信されます。
A group member can receive a message shortly after the group has been rekeyed and new keying material has been distributed by the KDC. In the following two cases, this may result in misaligned keying material between the group members.
グループメンバーは、グループが再キーになり、KDCによって新しいキーイング資料が配布された直後にメッセージを受信できます。次の2つのケースでは、これにより、グループメンバー間でキーイング素材が誤って整列される可能性があります。
In the first case, the sender protects a message using the old group keying material. However, the recipient receives the message after having received the new group keying material, hence it is not able to correctly process the message. A possible way to limit the impact of this issue is to preserve the old, retained group keying material for a maximum amount of time defined by the application, during which such group keying material is used solely for processing incoming messages. By doing so, the recipient can still temporarily process received messages also by using the old, retained group keying material. Note that a former (compromised) group member can take advantage of this by sending messages protected with the old, retained group keying material. Therefore, a conservative application policy should not admit the storage of old group keying material. Eventually, the sender will have obtained the new group keying material too and can possibly resend the message protected with such keying material.
最初のケースでは、送信者は古いグループキーイング素材を使用してメッセージを保護します。ただし、受信者は、新しいグループキーイング素材を受け取った後にメッセージを受信するため、メッセージを正しく処理することはできません。この問題の影響を制限する可能性のある方法は、アプリケーションによって定義された最大時間のために古い保持されたグループキーイング素材を保存することです。そうすることで、受信者は、古い保持されたグループキーイング素材を使用することにより、受信したメッセージを一時的に処理することができます。以前の（妥協した）グループメンバーは、古い保持されたグループキーイング素材で保護されたメッセージを送信することでこれを利用できることに注意してください。したがって、保守的な申請ポリシーは、古いグループキーイング資料の保管を認めるべきではありません。最終的に、送信者は新しいグループキーイングマテリアルも取得し、そのようなキーイング素材で保護されているメッセージを再送信する可能性があります。
In the second case, the sender protects a message using the new group keying material, but the recipient receives that message before having received the new group keying material. Therefore, the recipient will not be able to correctly process the message and hence will discard it. If the recipient receives the new group keying material shortly after that and the application at the sender endpoint performs retransmissions, the former will still be able to receive and correctly process the message. In any case, the recipient should actively ask the KDC for the latest group keying material according to an application-defined policy, for instance, after a given number of unsuccessfully decrypted incoming messages.
2番目のケースでは、送信者は新しいグループキーイングマテリアルを使用してメッセージを保護しますが、受信者は新しいグループキーイングマテリアルを受け取る前にそのメッセージを受け取ります。したがって、受信者はメッセージを正しく処理することができず、したがってそれを破棄します。その後、受信者が新しいグループキーイングマテリアルを受信し、送信者エンドポイントでのアプリケーションが再送信を実行すると、前者はメッセージを受信して正しく処理することができます。いずれにせよ、受信者は、アプリケーション定義のポリシー、たとえば、特定の数が失敗した後、着信メッセージを解読した後に、アプリケーション定義のポリシーに従って、最新のグループキーイング資料をKDCに積極的に依頼する必要があります。
This section defines an extended format of binary-encoded scope, which additionally specifies the semantics used to express the same access control information from the corresponding original scope.
このセクションでは、バイナリエンコード範囲の拡張形式を定義します。これは、対応する元の範囲から同じアクセス制御情報を表現するために使用されるセマンティクスをさらに指定します。
As also discussed in Section 3.2, this enables a Resource Server to unambiguously process a received access token, also in case the Resource Server runs multiple applications or application profiles that involve different scope semantics.
セクション3.2で説明したように、リソースサーバーは、リソースサーバーが異なるスコープセマンティクスを含む複数のアプリケーションまたはアプリケーションプロファイルを実行した場合にも、受信アクセストークンを明確に処理できます。
The extended format is intended only for the 'scope' claim of access tokens for the cases where the claim takes a CBOR byte string as the value. That is, the extended format does not apply to the 'scope' parameter included in ACE messages, i.e., the Authorization Request and Authorization Response exchanged between the Client and the Authorization Server (see Sections 5.8.1 and 5.8.2 of [RFC9200]), the AS Request Creation Hints message from the Resource Server (see Section 5.3 of [RFC9200]), and the Introspection Response from the Authorization Server (see Section 5.9.2 of [RFC9200]).
拡張形式は、クレームがCBORバイト文字列を値として取得する場合のアクセストークンの「スコープ」クレームのみを目的としています。つまり、拡張形式は、ACEメッセージに含まれる「スコープ」パラメーター、つまりクライアントと承認サーバーの間で交換される承認要求と承認応答には適用されません（[RFC9200]のセクション5.8.1および5.8.2を参照してください。）、ASリクエスト作成は、リソースサーバーからのメッセージをヒント（[RFC9200]のセクション5.3を参照）、および認証サーバーからの内省的応答（[RFC9200]のセクション5.9.2を参照）。
The value of the 'scope' claim following the extended format is composed as follows. Given the original scope using semantics SEM and encoded as a CBOR byte string, the corresponding extended scope consists of the same CBOR byte string enclosed by a CBOR tag [RFC8949], whose tag number identifies the semantics SEM.
拡張形式に続く「スコープ」クレームの値は、次のように構成されています。セマンティクスSEMを使用し、CBORバイト文字列としてエンコードされた元の範囲を考えると、対応する拡張スコープは、CBORタグ[RFC8949]で囲まれた同じCBORバイト文字列で構成されます。
The resulting tagged CBOR byte string is used as the value of the 'scope' claim of the access token.
結果のタグ付きCBORバイト文字列は、アクセストークンの「スコープ」クレームの値として使用されます。
Figures 36 and 37 build on the examples in Section 3.1 and show the corresponding extended scopes.
図36および37は、セクション3.1の例に基づいて構築され、対応する拡張スコープを示しています。
;# include rfc9237
gname = tstr
permissions = uint .bits roles
roles = &(
Requester: 1,
Responder: 2,
Monitor: 3,
Verifier: 4
)
scope_entries = AIF-Generic<gname, permissions>
scope = bstr .cbor scope_entries
extended_scope = #6.<TAG_FOR_THIS_SEMANTICS>(scope)
TAG_FOR_THIS_SEMANTICS = uint
Figure 36: Example of Extended scope Using AIF
図36：AIFを使用した拡張スコープの例
gname = tstr
role = tstr
scope_entry = [ gname , ? ( role / [ 2*role ] ) ]
scope_entries = [ * scope_entry ]
scope = bstr .cbor scope_entries
extended_scope = #6.<TAG_FOR_THIS_SEMANTICS>(scope)
TAG_FOR_THIS_SEMANTICS = uint
Figure 37: Example of Extended scope Using the Textual Format, with the Role Identifiers Encoded as Text Strings
図37：テキスト識別子がテキスト文字列としてエンコードされたテキスト形式を使用した拡張スコープの例
The usage of the extended scope format is not limited to application profiles of this specification or to applications based on group communication. Rather, it is generally applicable to any application and application profile where access control information in the access token is expressed as a binary-encoded scope.
拡張スコープ形式の使用は、この仕様のアプリケーションプロファイルまたはグループ通信に基づくアプリケーションに限定されません。むしろ、アクセストークン内のアクセス制御情報がバイナリエンコードされたスコープとして表されるアプリケーションとアプリケーションプロファイルに一般的に適用できます。
Applications and application profiles using the extended format of scope have to specify which CBOR tag from [CBOR.Tags] is used for identifying the scope semantics or to register a new CBOR tag if a suitable one does not exist already (REQ28). In case there is an already existing, suitable CBOR tag, a new CBOR tag should not be registered in order to avoid code point squatting.
スコープの拡張形式を使用したアプリケーションとアプリケーションプロファイルは、[cbor.tags]からのCborタグを指定する必要があります。スコープセマンティクスを識別するために、または適切なタグがまだ存在しない場合は新しいCborタグを登録する必要があります（Req28）。既存の適切なCBORタグが既にある場合、コードポイントスクワットを避けるために、新しいCBORタグを登録しないでください。
If the binary-encoded scope uses semantics associated with a registered CoAP Content-Format [RFC7252] [CoAP.Content.Formats], then a suitable CBOR tag associated with that CoAP Content-Format would already be registered, as defined in Section 4.3 of [RFC9277].
バイナリエンコードスコープが登録されたCOAPコンテンツフォーマット[RFC7252] [coap.content.formats]に関連付けられたセマンティクスを使用している場合、そのCOAPコンテンツフォーマットに関連付けられた適切なCBORタグは、既に登録されています。[RFC9277]。
This is especially relevant when the binary encoded scope uses AIF. That is, it is expected that the definition of an AIF-specific data model comes together with the registration of CoAP Content-Formats for the relevant combinations of its Toid and Tperm values. As discussed above, this yields the automatic registration of the CBOR tags associated with those CoAP Content-Formats.
これは、バイナリエンコードされたスコープがAIFを使用する場合に特に関連します。つまり、AIF固有のデータモデルの定義は、TOID値とTPERM値の関連する組み合わせのために、COAPコンテンツフォーマットの登録と一緒になることが予想されます。上記で説明したように、これにより、これらのCOAPコンテンツフォーマットに関連付けられたCBORタグの自動登録が得られます。
This specification defines a number of parameters used during the second phase of the key provisioning process, i.e., after the exchange after the exchange of Token Transfer Request and Response. The table below summarizes them and specifies the CBOR map keys to use instead of the full descriptive names.
この仕様は、主要なプロビジョニングプロセスの第2フェーズで使用される多くのパラメーター、つまりトークン転送要求と応答の交換後の交換後に使用される多くのパラメーターを定義します。以下の表はそれらをまとめて、完全な記述名の代わりに使用するCBORマップキーを指定します。
Note that the media type "application/ace-groupcomm+cbor" MUST be used when these parameters are transported in the respective CBOR map entries.
これらのパラメーターがそれぞれのCBORマップエントリで輸送される場合、メディアタイプ「アプリケーション/ACE-GroupComm+CBOR」を使用する必要があることに注意してください。
+=======================+======+========================+===========+
| Name | CBOR | CBOR Type | Reference |
| | Key | | |
+=======================+======+========================+===========+
| gid | 0 | array | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| gname | 1 | array of tstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| guri | 2 | array of tstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| scope | 3 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| get_creds | 4 | Null or array | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| client_cred | 5 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| cnonce | 6 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| gkty | 7 | int or tstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| key | 8 | See the "ACE | RFC 9594 |
| | | Groupcomm Key | |
| | | Types" registry | |
+-----------------------+------+------------------------+-----------+
| num | 9 | int | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| ace_groupcomm_profile | 10 | int | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| exp | 11 | uint | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| exi | 12 | uint | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| creds | 13 | array | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| peer_roles | 14 | array | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| peer_identifiers | 15 | array | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| group_policies | 16 | map | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| kdc_cred | 17 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| kdc_nonce | 18 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| kdc_cred_verify | 19 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| rekeying_scheme | 20 | int | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| client_cred_verify | 24 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| creds_repo | 25 | tstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| control_uri | 26 | tstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| mgt_key_material | 27 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| control_group_uri | 28 | tstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| sign_info | 29 | Null or array | RFC 9594 |
+-----------------------+------+------------------------+-----------+
| kdcchallenge | 30 | bstr | RFC 9594 |
+-----------------------+------+------------------------+-----------+
Table 5: ACE Groupcomm Parameters
表5：ACE GroupCommパラメーター
The KDC is expected to support all the parameters above. Instead, a Client can support only a subset of such parameters, depending on the roles it expects to take in the joined groups or on other conditions defined in application profiles of this specification.
KDCは、上記のすべてのパラメーターをサポートすることが期待されています。代わりに、クライアントは、参加したグループで取ることが期待される役割や、この仕様のアプリケーションプロファイルで定義されている他の条件に応じて、そのようなパラメーターのサブセットのみをサポートできます。
In the following, the parameters are categorized according to the support expected by Clients. That is, a Client that supports a parameter is able to: i) use and specify it in a request message to the KDC; and ii) understand and process it if specified in a response message from the KDC. It is REQUIRED of application profiles of this specification to sort their newly defined parameters according to the same categorization (REQ29).
以下では、パラメーターはクライアントが期待するサポートに従って分類されます。つまり、パラメーターをサポートするクライアントは次のことができます。i）KDCへのリクエストメッセージでそれを使用して指定します。ii）KDCからの応答メッセージで指定されている場合、それを理解して処理します。この仕様のアプリケーションプロファイルには、同じ分類（REQ29）に従って新たに定義されたパラメーターをソートする必要があります。
Note that the actual use of a parameter and its inclusion in a message depends on the specific exchange, the specific Client and group involved, as well as what is defined in the used application profile of this specification.
パラメーターの実際の使用とメッセージへの包含は、特定の交換、特定のクライアントとグループ、およびこの仕様の使用されるアプリケーションプロファイルで定義されているものに依存することに注意してください。
A Client MUST support the following parameters.
クライアントは、次のパラメーターをサポートする必要があります。
* 'scope'
* '範囲'
* 'cnonce'
* 「cnonce」
* 'gkty'
* 「gkty」
* 'key'
* '鍵'
* 'num'
* 「num」
* 'exp'
* 「exp」
* 'exi'
* 「exi」
* 'gid'
* 「gid」
* 'gname'
* 「gname」
* 'guri'
* 「グリ」
* 'creds'
* 「信用」
* 'peer_identifiers'
* 「Peer_identifiers」
* 'ace_groupcomm_profile'
* 'ace_groupcomm_profile'
* 'control_uri'
* 'control_uri'
* 'rekeying_scheme'
* 「Rekeying_scheme」
A Client SHOULD support the following parameter.
クライアントは、次のパラメーターをサポートする必要があります。
* 'get_creds': That is, not supporting this parameter would yield the inconvenient and undesirable behavior where: i) the Client does not ask for the other group members' authentication credentials upon joining the group (see Section 4.3.1.1); and ii) later on as a group member, the Client only retrieves the authentication credentials of all group members (see Section 4.4.2.1).
* 'get_creds'：つまり、このパラメーターをサポートしないと、以下が不便で望ましくない動作が得られます。i）クライアントは、グループに参加すると他のグループメンバーの認証資格情報を求めません（セクション4.3.1.1を参照）。ii）後でグループメンバーとして、クライアントはすべてのグループメンバーの認証資格情報のみを取得します（セクション4.4.2.1を参照）。
The following conditional parameters are relevant only if specific conditions hold. It is REQUIRED of application profiles of this specification to define whether Clients must, should, or may support these parameters and under which circumstances (REQ30).
次の条件付きパラメーターは、特定の条件が当てはまる場合にのみ関連します。この仕様のアプリケーションプロファイルには、クライアントがこれらのパラメーターをサポートする必要があるか、必要な、またはサポートするか、またはその状況下で定義する必要があります（REQ30）。
* 'client_cred' and 'client_cred_verify': These parameters are relevant for a Client that has an authentication credential to use in a joined group.
* 'client_cred'および 'client_cred_verify'：これらのパラメーターは、参加したグループで使用する認証資格情報を持っているクライアントに関連しています。
* 'kdcchallenge': This parameter is relevant for a Client that has an authentication credential to use in a joined group and that provides the access token to the KDC through a Token Transfer Request (see Section 3.3).
* 「KDCChallenge」：このパラメーターは、参加グループで使用する認証資格情報を持ち、トークン転送要求を介してKDCにアクセストークンを提供するクライアントに関連しています（セクション3.3を参照）。
* 'creds_repo': This parameter is relevant for a Client that has an authentication credential to use in a joined group and that makes it available from a key repository different than the KDC.
* 'creds_repo'：このパラメーターは、結合グループで使用する認証資格情報を持ち、KDCとは異なるキーリポジトリから利用可能にするクライアントに関連しています。
* 'group_policies': This parameter is relevant for a Client that is interested in the specific policies used in a group, but it does not know them or cannot become aware of them before joining that group.
* 「Group_Policies」：このパラメーターは、グループで使用されている特定のポリシーに関心のあるクライアントに関連していますが、そのグループに参加する前にそれらを知らないか、それらを認識できません。
* 'peer_roles': This parameter is relevant for a Client that has to know about the roles of other group members, especially when retrieving and handling their corresponding authentication credentials.
* 「PEER_ROLES」：このパラメーターは、特に対応する認証資格情報を取得および処理する場合、他のグループメンバーの役割について知っておく必要があるクライアントに関連しています。
* 'kdc_nonce', 'kdc_cred', and 'kdc_cred_verify': These parameters are relevant for a Client that joins a group for which, as per the used application profile of this specification, the KDC has an associated authentication credential and this is required for the correct group operation.
* 'kdc_nonce'、 'kdc_cred'、および 'kdc_cred_verify'：これらのパラメーターは、この仕様の使用されたアプリケーションプロファイルに従って、KDCが関連する認証資格情報を持ち、これが必要であり、これが必要であり、これが必要であるグループに参加するクライアントに関連しています。正しいグループ操作。
* 'mgt_key_material': This parameter is relevant for a Client that supports an advanced rekeying scheme possibly used in the group, such as based on one-to-many rekeying messages sent over IP multicast.
* 'mgt_key_material'：このパラメーターは、IPマルチキャストを介して送信された1対多くの再キーイングメッセージに基づくなど、グループで使用される可能性のある高度な再キーイングスキームをサポートするクライアントに関連しています。
* 'control_group_uri': This parameter is relevant for a Client that also acts as a CoAP server supporting: i) the hosting of a dedicated resource for each group that the Client is interested to be a part of; and ii) the reception of one-to-many requests sent to those resources by the KDC (e.g., over IP multicast), as targeting multiple members of the corresponding group. Examples of related management operations that the KDC can perform by this means are the eviction of group members and the execution of a group rekeying process through an advanced rekeying scheme, such as based on one-to-many rekeying messages.
* 'control_group_uri'：このパラメーターは、クライアップがサポートするCoapサーバーとしても機能するクライアントに関連しています。i）クライアントが関心を持っている各グループの専用リソースのホスティング。ii）対応するグループの複数のメンバーをターゲットにしているため、KDC（たとえば、IPマルチキャストを超えるマルチキャストなど）からこれらのリソースに送信される1対多リクエストの受信。KDCがこの手段で実行できる関連管理操作の例は、グループメンバーの立ち退きと、1対多くの再キーイングメッセージに基づくなど、高度な再キーイングスキームを通じてグループの再キーイングプロセスの実行です。
This specification defines a number of values that the KDC can use as error identifiers. These are used in error responses with Content-Format "application/concise-problem-details+cbor", as values of the 'error-id' field within the Custom Problem Detail entry 'ace-groupcomm-error' (see Section 4.1.2).
この仕様は、KDCがエラー識別子として使用できる多くの値を定義します。これらは、カスタム問題の詳細エントリ「Ace-GroupComm-Error」内の「エラーID」フィールドの値として、コンテンツフォーマット「アプリケーション/簡潔な問題」フィールドの値としてエラー応答で使用されます（セクション4.1を参照してください。2）。
+=======+=============================================+
| Value | Description |
+=======+=============================================+
| 0 | Operation permitted only to group members |
+-------+---------------------------------------------+
| 1 | Request inconsistent with the current roles |
+-------+---------------------------------------------+
| 2 | Authentication credential incompatible with |
| | the group configuration |
+-------+---------------------------------------------+
| 3 | Invalid proof-of-possession evidence |
+-------+---------------------------------------------+
| 4 | No available individual keying material |
+-------+---------------------------------------------+
| 5 | Group membership terminated |
+-------+---------------------------------------------+
| 6 | Group deleted |
+-------+---------------------------------------------+
Table 6: ACE Groupcomm Error Identifiers
表6：ACE GroupCommエラー識別子
If a Client supports the problem-details format [RFC9290] and the Custom Problem Detail entry 'ace-groupcomm-error' defined in Section 4.1.2 of this document and is able to understand the error specified in the 'error-id' field therein, then the Client can use that information to determine what actions to take next. If the Concise Problem Details data item specified in the error response includes the 'detail' entry and the Client supports it, such an entry may provide additional context.
クライアントが問題をサポートしている場合[RFC9290]、およびこのドキュメントのセクション4.1.2で定義されているカスタム問題の詳細エントリ「Ace-GroupComm-Error」の詳細を確認し、「エラーID」フィールドで指定されているエラーを理解できます。そこで、クライアントはその情報を使用して、次にとるべきアクションを決定できます。エラー応答で指定された簡潔な問題の詳細データ項目が「詳細」エントリが含まれ、クライアントがサポートする場合、そのようなエントリは追加のコンテキストを提供する場合があります。
In particular, the following guidelines apply, and application profiles of this specification can define more detailed actions for the Client to take when learning that a specific error has occurred.
特に、次のガイドラインが適用され、この仕様のアプリケーションプロファイルは、特定のエラーが発生したことを学習するときにクライアントが取るためのより詳細なアクションを定義できます。
* In case of error 0, the Client should stop sending the request in question to the KDC. Rather, the Client should first join the targeted group. If it has not happened already, this first requires the Client to obtain an appropriate access token authorizing access to the group and provide it to the KDC.
* エラー0の場合、クライアントは問題のリクエストの送信をKDCに停止する必要があります。むしろ、クライアントは最初にターゲットグループに参加する必要があります。それがまだ発生していない場合、これにより、最初にクライアントがグループへのアクセスを許可する適切なアクセストークンを取得し、KDCに提供する必要があります。
* In case of error 1, the Client as a group member should rejoin the group with all the roles needed to perform the operation in question. This might require the Client to first obtain a new access token and provide it to the KDC, if the current access token does not authorize the Client to take those roles in the group. For operations admitted to a Client that is not a group member (e.g., an external signature verifier), the Client should first obtain a new access token authorizing to also have the missing roles.
* エラー1の場合、グループメンバーとしてのクライアントは、問題の操作を実行するために必要なすべての役割でグループに再び参加する必要があります。これにより、現在のアクセストークンがクライアントにグループ内の役割を果たすことを許可しない場合、クライアントが最初に新しいアクセストークンを取得してKDCに提供する必要がある場合があります。グループメンバーではないクライアント（外部署名検証剤など）に認められた操作の場合、クライアントはまず、不足している役割を持つことを許可する新しいアクセストークンを取得する必要があります。
* In case of error 2, the Client has to obtain or self-generate a different asymmetric key pair, as aligned to the public key algorithm and parameters used in the targeted group. After that, the Client should provide the KDC with its new authentication credential, which is consistent with the format used in the targeted group and including the new public key.
* エラー2の場合、クライアントは、ターゲットグループで使用されている公開キーアルゴリズムとパラメーターに合わせて、異なる非対称キーペアを取得または自己生成する必要があります。その後、クライアントはKDCに新しい認証資格情報を提供する必要があります。これは、ターゲットグループで使用され、新しい公開キーを含む形式と一致しています。
* In case of error 3, the Client should ensure to compute its proof-of-possession evidence by correctly using the parameters and procedures defined in the used application profile of this specification. In an unattended setup, it might not be possible for a Client to autonomously diagnose the error and take an effective next action to address it.
* エラー3の場合、クライアントは、この仕様の使用されているアプリケーションプロファイルで定義されたパラメーターと手順を正しく使用して、所有証明の証拠を確実に計算することを確認する必要があります。無人セットアップでは、クライアントがエラーを自律的に診断し、効果的な次のアクションを実行して対処することは不可能かもしれません。
* In case of error 4, the Client should wait for a certain (pre-configured) amount of time before trying to resend its request to the KDC.
* エラー4の場合、クライアントは、KDCにリクエストを再送信しようとする前に、特定の（事前に構成された）時間を待つ必要があります。
* In case of error 5, the Client may try joining the group again. This might require the Client to first obtain a new access token and provide it to the KDC, e.g., if the current access token has expired.
* エラー5の場合、クライアントは再度グループに参加してみることができます。これには、クライアントが最初に新しいアクセストークンを取得し、KDCに提供する必要がある場合があります。たとえば、現在のアクセストークンの有効期限が切れた場合。
* In case of error 6, the Client should clean up its state regarding the group, just like if it has left the group with no intention to rejoin it.
* エラー6の場合、クライアントはグループに関する状態をクリーンアップする必要があります。
Security considerations are inherited from the ACE framework [RFC9200] and from the specific transport profile of ACE used between the Clients and the KDC, e.g., [RFC9202] and [RFC9203].
セキュリティ上の考慮事項は、ACEフレームワーク[RFC9200]およびクライアントとKDCの間で使用されるACEの特定の輸送プロファイル、たとえば[RFC9202]および[RFC9203]から継承されます。
When using the problem-details format defined in [RFC9290] for error responses, then the privacy and security considerations from Sections 4 and 5 of [RFC9290] also apply.
エラー応答のために[RFC9290]で定義されている問題 - 控除形式を使用する場合、[RFC9290]のセクション4および5のプライバシーとセキュリティの考慮事項も適用されます。
Furthermore, the following security considerations apply.
さらに、次のセキュリティ上の考慮事項が適用されます。
When a group member receives a message from a certain sender for the first time since joining the group, it needs to have a mechanism in place to avoid replayed messages and to assert their freshness, e.g., as described in Appendix B.1.2 of [RFC8613] or Section 10 of [GROUP-OSCORE]. Such a mechanism also aids the recipient group member in case it has rebooted and lost the security state used to protect previous group communications with that sender.
グループメンバーがグループに参加して以来初めて特定の送信者からメッセージを受信した場合、[RFC8613の付録B.1.2で説明されているように、メッセージを再生しないようにし、新鮮さを主張するためのメカニズムが必要である必要があります。]または[Group-Oscore]のセクション10。このようなメカニズムは、その送信者との以前のグループ通信を保護するために使用されるセキュリティ状態を再起動して失った場合に備えて、受信者グループメンバーを支援します。
By its nature, the KDC is invested with a large amount of trust, since it acts as a generator and provider of the symmetric keying material used to protect communications in each of its groups. While details depend on the specific communication and security protocols used in the group, the KDC is in the position to decrypt messages exchanged in the group as if it was also a group member, as long as those are protected through commonly shared group keying material.
その性質上、KDCは、各グループのコミュニケーションを保護するために使用される対称キーイング材料のジェネレーターおよびプロバイダーとして機能するため、大量の信頼を持って投資されています。詳細は、グループで使用される特定の通信およびセキュリティプロトコルに依存しますが、KDCは、一般的に共有されているグループキーイング素材を通じて保護されている限り、グループで交換されたメッセージを復号化する位置にあります。
A compromised KDC would thus put the attacker in the same position, which also means that:
したがって、侵害されたKDCは、攻撃者を同じ位置に置くでしょう。これは、次のことを意味します。
* The attacker can generate and control new group keying material, hence possibly rekeying the group and evicting certain group members as part of a broader attack.
* 攻撃者は、新しいグループキーイングマテリアルを生成および制御することができ、したがって、おそらくグループを再ケーニングし、より広範な攻撃の一部として特定のグループメンバーを追い出すことができます。
* The attacker can actively participate in communications in a group, even without having been authorized to join it, and can allow further unauthorized entities to do so.
* 攻撃者は、グループでのコミュニケーションに積極的に参加することができます。
* The attacker can build erroneous associations between node identifiers and group members' authentication credentials.
* 攻撃者は、ノード識別子とグループメンバーの認証資格情報との間に誤った関連付けを構築できます。
On the other hand, as long as the security protocol used in the group ensures source authentication of messages (e.g., by means of signatures), the KDC is not able to impersonate group members since it does not have their private keys.
一方、グループで使用されているセキュリティプロトコルがメッセージのソース認証を保証する限り（署名など）、KDCはプライベートキーがないため、グループメンバーになりすましません。
Further security considerations are specific to the communication and security protocols used in the group, and thus have to be provided by those protocols and complemented by the application profiles of this specification using them.
さらなるセキュリティ上の考慮事項は、グループで使用される通信およびセキュリティプロトコルに固有であるため、これらのプロトコルによって提供され、それらを使用したこの仕様のアプリケーションプロファイルによって補完される必要があります。
The KDC can generate new group keying material and provide it to the group members (rekeying) through the rekeying scheme used in the group, as discussed in Section 6.
KDCは、セクション6で説明されているように、グループで使用されている再キーイングスキームを通じて、新しいグループキーイングマテリアルを生成し、グループメンバー（再キーイング）に提供できます。
In particular, the KDC must renew the latest group keying material upon its expiration. Before then, the KDC MAY also renew the group keying material on a regular or periodical fashion.
特に、KDCは、その有効期限に伴う最新のグループキーイング資料を更新する必要があります。それ以前は、KDCは、グループキーイング素材を定期的または定期的なファッションで更新する場合があります。
Unless otherwise defined by an application profile of this specification, the KDC SHOULD renew the group keying material upon a group membership change. As a possible exception, the KDC may not rekey the group upon the joining of a new group member if the application does not require backward security. As another possible exception discussed more in detail later in this section, the KDC may rely on a rekeying policy that reasonably takes into account the expected rate of group membership changes and the duration of a group rekeying.
この仕様のアプリケーションプロファイルで特に定義されていない限り、KDCはグループメンバーシップの変更時にグループキーイングマテリアルを更新する必要があります。考えられる例外として、KDCは、アプリケーションが逆方向のセキュリティを必要としない場合、新しいグループメンバーの参加時にグループを再キーすることはできません。このセクションの後半で詳細に説明した別の例外として、KDCは、グループメンバーシップの変更の予想レートとグループの再キーイング期間を合理的に考慮に入れる再キーキングポリシーに依存する場合があります。
Since the minimum number of group members is one, the KDC SHOULD provide even a Client joining an empty group with new keying material never used before in that group. Similarly, the KDC SHOULD also provide new group keying material to a Client that remains the only member in the group after the leaving of other group members.
グループメンバーの最小数は1つあるため、KDCは、そのグループでこれまで使用したことのない新しいキーイング素材を備えた空のグループに参加するクライアントでさえ提供する必要があります。同様に、KDCはまた、他のグループメンバーを去った後、グループ内の唯一のメンバーであり続けるクライアントに新しいグループキーイング資料を提供する必要があります。
Note that the considerations in Section 10.1 about dealing with replayed messages still hold, even in case the KDC rekeys the group upon every single joining of a new group member. However, if the KDC has renewed the group keying material upon a group member's joining and the time interval between the end of the rekeying process and that member's joining is sufficiently small, then that group member is also on the safe side, since it would not accept replayed messages protected with the old group keying material previous to its joining.
KDCが新しいグループメンバーのすべての参加にグループを再キーする場合でも、再生されたメッセージの処理に関するセクション10.1の考慮事項はまだ保持されています。ただし、KDCがグループメンバーの参加と再キーイングプロセスの終了間の時間間隔でグループキーイングマテリアルを更新し、メンバーの参加が十分に小さい場合、そのグループメンバーも安全な側にいます。結合の前に、古いグループキーイング素材で保護された再生されたメッセージを受け入れます。
Once a joining node has obtained the new, latest keying material through a Join Response from the KDC (see Section 4.3.1.1), the joining node becomes able to read any message that was exchanged in the group and protected with that keying material. This is the case if the KDC provides the current group members with the new, latest keying material before completing the joining procedure. However, the joining node is not able to read messages exchanged in the group and protected with keying material older than the one provided in the Join Response, i.e., having a strictly lower version number NUM.
結合ノードがKDCからの結合応答（セクション4.3.1.1を参照）を通じて新しい最新キーイング素材を取得すると、結合ノードはグループで交換され、そのキーイング素材で保護されているメッセージを読み取ることができます。これは、KDCが参加手順を完了する前に現在のグループメンバーに新しい最新のキーイング資料を提供した場合です。ただし、結合ノードは、グループで交換されたメッセージを読み取ることができず、結合応答で提供されているものよりも古いキーキー材料で保護されています。
A node that has left the group should not expect any of its outgoing messages to be successfully processed if received by other nodes in the group after its leaving due to a possible group rekeying occurring before the message reception.
グループを去ったノードは、メッセージ受信の前にグループが発生する可能性があるため、グループ内の他のノードが受信した場合、発信メッセージのいずれかが正常に処理されるとは期待してはなりません。
The KDC may enforce a rekeying policy that takes into account the overall time required to rekey the group, as well as the expected rate of changes in the group membership. That is, the KDC may not rekey the group at each and every group membership change, for instance, if members' joining and leaving occur frequently and performing a group rekeying takes too long. Instead, the KDC might rekey the group after a minimum number of group members have joined or left within a given time interval, after a maximum amount of time since the last group rekeying was completed, or yet during predictable network inactivity periods.
KDCは、グループを再キーするために必要な全体的な時間と、グループメンバーシップの変化の予想レートを考慮した再キーキングポリシーを実施する場合があります。つまり、KDCは、メンバーが頻繁に発生して出発し、グループの再キーイングを実行するのに時間がかかりすぎる場合、すべてのグループメンバーシップの変化でグループを再キーすることはできません。代わりに、KDCは、最後のグループの再キーイングが完了してから最大時間内、または予測可能なネットワークの不活動期間中に、最低数のグループメンバーが特定の時間間隔内に参加または去った後、グループを再キーする可能性があります。
However, this would result in the KDC not constantly preserving backward and forward security in the group. That is:
ただし、これにより、KDCはグループ内の後方および前方のセキュリティを常に維持していません。つまり：
* Newly joining group members would be able to access the keying material used before their joining, and thus they could access past group communications if they have recorded old exchanged messages. This might still be acceptable for some applications and in situations where the new group members are freshly deployed through strictly controlled procedures.
* 新しく参加するグループメンバーは、参加前に使用されるキーイング素材にアクセスできるため、古い交換メッセージを記録した場合、過去のグループコミュニケーションにアクセスできます。これは、いくつかのアプリケーションや、新しいグループメンバーが厳密に管理された手順を通じて新たに展開される状況で依然として受け入れられる可能性があります。
* The leaving group members would remain able to access upcoming group communications, as protected with the current keying material that has not been updated. This is typically undesirable, especially if the leaving group member is compromised or suspected to be, and it might impact or compromise the security properties of the protocols used in the group to protect messages exchanged among the group members.
* 退職グループのメンバーは、更新されていない現在のキーイング素材で保護されているため、今後のグループコミュニケーションにアクセスすることができます。これは通常、望ましくありません。特に、退職グループのメンバーが侵害または疑われる場合、グループで使用されるプロトコルのセキュリティプロパティに影響を与えたり妥協したりする可能性があります。
The KDC should renew the group keying material in case it has rebooted, even if it stores the whole group keying material in persistent storage. This assumes that the secure communication associations with the current group members as well as any administrative keying material required to rekey the group are also stored in persistent storage.
KDCは、グループ全体のキーイングマテリアルを永続的なストレージに保存する場合でも、再起動した場合に備えて、グループキーイングマテリアルを更新する必要があります。これは、現在のグループメンバーとの安全な通信関連と、グループを再キーするために必要な管理キーイング資料も永続的なストレージに保存されることを前提としています。
However, if the KDC relies on Observe notifications to distribute the new group keying material, the KDC would have lost all the current ongoing Observations with the group members after rebooting, and the group members would continue using the old group keying material. Therefore, the KDC will rely on each group member asking for the new group keying material (see Sections 4.3.2.1 and 4.8.1.1) or perform a group rekeying by actively sending rekeying messages to group members as discussed in Section 6.
ただし、KDCが新しいグループキーイングマテリアルを配布するための観察通知に依存している場合、KDCは再起動後にグループメンバーと現在進行中のすべての観測を失い、グループメンバーは古いグループキーイング素材を使用し続けます。したがって、KDCは各グループメンバーに依存して、新しいグループキーイングマテリアルを求め（セクション4.3.2.1および4.8.1.1を参照）、セクション6で説明したようにグループメンバーに積極的にメッセージを送信することにより、再キーイングを実行します。
The KDC needs to have a mechanism in place to detect DoS attacks from nodes repeatedly performing actions that might trigger a group rekeying. Such actions can include leaving and/or rejoining the group at high rates or often asking the KDC for new individual keying material. Ultimately, the KDC can resort to removing these nodes from the group and (temporarily) preventing them from joining the group again.
KDCには、グループが再キーイングをトリガーする可能性のあるアクションを繰り返し実行するノードからのDOS攻撃を検出するためのメカニズムが必要です。このような行動には、グループを高いレートで去ったり再び加入したり、KDCに新しい個別のキーイング素材を求めることが含まれます。最終的に、KDCはこれらのノードをグループから削除し、（一時的に）グループに再び参加するのを防ぐことに頼ることができます。
The KDC also needs to have a congestion control mechanism in place in order to avoid network congestion upon distributing new group keying material. For example, CoAP and Observe give guidance on such mechanisms, see Section 4.7 of [RFC7252] and Section 4.5.1 of [RFC7641].
また、KDCは、新しいグループキーイング素材を配布する際のネットワーク輻輳を回避するために、輻輳制御メカニズムを整える必要があります。たとえば、COAPとObserveは、このようなメカニズムに関するガイダンスを示しています。[RFC7252]のセクション4.7および[RFC7641]のセクション4.5.1を参照してください。
If the Block-Wise CoAP options [RFC7959] are used and the keying material is updated in the middle of a Block-Wise transfer, the sender of the blocks just changes the group keying material to the updated one and continues the transfer. As long as both sides get the new group keying material, updating the group keying material in the middle of a transfer will not cause any issue. Otherwise, the sender will have to transmit the message again when receiving an error message from the recipient.
ブロックごとのCOAPオプション[RFC7959]が使用され、キーイング素材がブロックごとの転送の途中で更新される場合、ブロックの送信者はグループキーイングマテリアルを更新されたものに変更し、転送を継続します。双方が新しいグループキーイングマテリアルを取得する限り、転送の途中でグループキーイングマテリアルを更新しても、問題は発生しません。それ以外の場合、送信者は、受信者からエラーメッセージを受信するときにメッセージを再度送信する必要があります。
Compared to a scenario where the transfer does not use Block-Wise, and depending on how fast the group keying material is changed, the group members might consume a larger amount of the network bandwidth by repeatedly resending the same blocks, which might be problematic.
転送がブロックごとに使用しないシナリオと比較して、グループキーイングマテリアルの変更速度に応じて、グループメンバーは同じブロックを繰り返し留保することにより、ネットワークの帯域幅を大量に消費する可能性がありますが、これは問題になる可能性があります。
Per this document, IANA has completed the following actions.
このドキュメントによると、IANAは次のアクションを完了しています。
This specification has registered the "application/ace-groupcomm+cbor" media type for messages of the protocols defined in this document following the ACE exchange and carrying parameters encoded in CBOR. This registration follows the procedures specified in [RFC6838].
この仕様は、CBORでエンコードされたACE ExchangeおよびCharingパラメーターに続いて、このドキュメントで定義されているプロトコルのメッセージの「アプリケーション/ACE-GroupComm+CBOR」メディアタイプを登録しています。この登録は、[RFC6838]で指定された手順に従います。
Type name:
タイプ名：
application
応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務
Subtype name:
サブタイプ名：
ace-groupcomm+cbor
ACE-GROUPCOMM+CBOR
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
Must be encoded as a CBOR map containing the parameters defined in RFC 9594.
RFC 9594で定義されたパラメーターを含むCBORマップとしてエンコードする必要があります。
Security considerations:
セキュリティ上の考慮事項：
See Section 10 of RFC 9594.
RFC 9594のセクション10を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9594
RFC 9594
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
The type is used by Authorization Servers, Clients, and Resource Servers that support the ACE groupcomm framework as specified in RFC 9594.
このタイプは、RFC 9594で指定されているACE GroupCommフレームワークをサポートする承認サーバー、クライアント、およびリソースサーバーによって使用されます。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
ACE WG mailing list (ace@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)
ACE WGメーリングリスト（ace@ietf.org）またはIETFアプリケーションとリアルタイムエリア（art@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
None
なし
Author/Change controller:
著者/変更コントローラー：
IETF
IETF
Provisional registration:
暫定登録：
No
いいえノー能
IANA has registered the following entry in the "CoAP Content-Formats" registry within the "CoRE Parameters" registry group.
IANAは、「コアパラメーター」レジストリグループ内の「COAPコンテンツフォーマット」レジストリに次のエントリを登録しました。
Content Type:
コンテンツタイプ：
application/ace-groupcomm+cbor
Application/Ace-GroupComm+Cbor
Content Coding:
コンテンツコーディング：
-
-
ID:
ID:
261
261
Reference:
参照：
RFC 9594
RFC 9594
IANA has registered the following entries in the "OAuth Parameters" registry, following the procedure specified in Section 11.2 of [RFC6749].
IANAは、[RFC6749]のセクション11.2で指定された手順に従って、「OAuthパラメーター」レジストリに次のエントリを登録しました。
Name:
名前：
sign_info
sign_info
Parameter Usage Location:
パラメーターの使用場所：
client-rs request, rs-client response
クライアントRSリクエスト、RSクライアント応答
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9594
RFC 9594
Name:
名前：
kdcchallenge
kdcchallenge
Parameter Usage Location:
パラメーターの使用場所：
rs-client response
rs-client応答
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9594
RFC 9594
IANA has registered the following entries in the "OAuth Parameters CBOR Mappings" registry, following the procedure specified in Section 8.10 of [RFC9200].
IANAは、[RFC9200]のセクション8.10で指定された手順に従って、「OAuthパラメーターCBORマッピング」レジストリに次のエントリを登録しました。
Name:
名前：
sign_info
sign_info
CBOR Key:
CBORキー：
45
45
Value Type:
値タイプ：
Null or array
ヌルまたは配列
Reference:
参照：
RFC 9594
RFC 9594
Name:
名前：
kdcchallenge
kdcchallenge
CBOR Key:
CBORキー：
46
46
Value Type:
値タイプ：
byte string
バイト文字列
Reference:
参照：
RFC 9594
RFC 9594
IANA has registered the following entry in the "Interface Description (if=) Link Target Attribute Values" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.
IANAは、「Interface Description（if =）linkターゲット属性値」レジストリに「constrained Restful環境（CORE）パラメーター」レジストリグループに次のエントリを登録しています。
Value:
値：
ace.groups
Ace.Groups
Description:
説明：
The KDC interface at the parent resource of group-membership resources is used to retrieve names of security groups using the ACE framework.
グループメンバーシップリソースの親リソースでのKDCインターフェイスは、ACEフレームワークを使用してセキュリティグループの名前を取得するために使用されます。
Reference:
参照：
Section 4.1 of RFC 9594
RFC 9594のセクション4.1
Value:
値：
ace.group
ace.group
Description:
説明：
The KDC interface at a group-membership resource is used to provision keying material and related information and policies to members of the corresponding security group using the ACE framework.
グループメンバーシップリソースのKDCインターフェイスは、ACEフレームワークを使用して、対応するセキュリティグループのメンバーにキーイング素材と関連情報とポリシーを提供するために使用されます。
Reference:
参照：
Section 4.1 of RFC 9594
RFC 9594のセクション4.1
IANA has registered the following entry in the "Custom Problem Detail Keys" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.
IANAは、「Constrained Restful Environments（Core）パラメーター」レジストリグループ内の「カスタム問題詳細キー」レジストリに次のエントリを登録しました。
Key Value:
キー値：
0
0
Name:
名前：
ace-groupcomm-error
ACE-GROUPCOMM-ERROR
Brief Description:
簡単な説明：
Carry RFC 9594 problem details in a Concise Problem Details data item.
RFC 9594の問題の詳細を簡潔な問題の詳細データ項目。
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
RFC 9594, Section 4.1.2
RFC 9594、セクション4.1.2
This specification has established the "ACE Groupcomm Parameters" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.
この仕様により、「制約環境の認証と認証（ACE）」レジストリグループ内の「ACE GroupCommパラメーター」IANAレジストリが確立されました。
Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in Section 11.14
このレジストリの値は、以下に示すように、さまざまな登録ポリシーでカバーされています。一部のポリシーでは、専門家のレビューが必要です。ガイドラインはセクション11.14に記載されています
The columns of this registry are:
このレジストリの列は次のとおりです。
Name:
名前：
This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding.
これは、アイテムをより簡単に参照できるようにする説明的な名前です。名前は一意でなければなりません。エンコーディングでは使用されません。
CBOR Key:
CBORキー：
This is the value used as the CBOR map key of the item. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".
これは、アイテムのCborマップキーとして使用される値です。これらの値は一意でなければなりません。値は、正の整数、負の整数、またはテキスト文字列です。さまざまな範囲の値は、異なる登録ポリシーを使用しています[RFC8126]。-256から255の整数値と長さ1のテキスト文字列は、「専門家のレビューを伴う標準アクション」として指定されています。-65536から-257、および256から65535の整数値、および長さ2のテキスト文字列は、「仕様が必要」として指定されています。65535を超える整数値と2を超える長さのテキスト文字列は、「専門家のレビュー」として指定されています。-65536未満の整数値は、「私的使用」としてマークされています。
CBOR Type:
CBORタイプ：
This field contains the CBOR type of the item or a pointer to the registry that defines its type when that depends on another item.
このフィールドには、別のアイテムに依存するときにそのタイプを定義するレジストリへのcborタイプまたはポインターが含まれています。
Reference:
参照：
This field contains a pointer to the public specification for the item.
このフィールドには、アイテムの公開仕様へのポインターが含まれています。
This registry has been initially populated with the values in Table 5.
このレジストリには、最初に表5の値が入力されています。
This specification establishes the "ACE Groupcomm Key Types" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.
この仕様は、「制約環境の認証と認証（ACE）」レジストリグループ内の「ACE GroupCommキータイプ」IANAレジストリを確立します。
Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in Section 11.14.
このレジストリの値は、以下に示すように、さまざまな登録ポリシーでカバーされています。一部のポリシーでは、専門家のレビューが必要です。ガイドラインはセクション11.14に記載されています。
The columns of this registry are:
このレジストリの列は次のとおりです。
Name:
名前：
This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding.
これは、アイテムをより簡単に参照できるようにする説明的な名前です。名前は一意でなければなりません。エンコーディングでは使用されません。
Key Type Value:
キータイプ値：
This is the value used to identify the keying material. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".
これは、キーイン材料を識別するために使用される値です。これらの値は一意でなければなりません。値は、正の整数、負の整数、またはテキスト文字列です。さまざまな範囲の値は、異なる登録ポリシーを使用しています[RFC8126]。-256から255の整数値と長さ1のテキスト文字列は、「専門家のレビューを伴う標準アクション」として指定されています。-65536から-257、および256から65535の整数値、および長さ2のテキスト文字列は、「仕様が必要」として指定されています。65535を超える整数値と2を超える長さのテキスト文字列は、「専門家のレビュー」として指定されています。-65536未満の整数値は、「私的使用」としてマークされています。
Profile:
プロフィール：
This field may contain one or more descriptive strings of application profiles to be used with this item. The values should be taken from the "Name" column of the "ACE Groupcomm Profiles" registry.
このフィールドには、このアイテムで使用するアプリケーションプロファイルの1つ以上の説明文字列が含まれる場合があります。値は、「ACE GroupCommプロファイル」レジストリの「名前」列から取得する必要があります。
Description:
説明：
This field contains a brief description of the keying material.
このフィールドには、キーイング素材の簡単な説明が含まれています。
Reference:
参照：
This field contains a pointer to the public specification for the format of the keying material, if one exists.
このフィールドには、キーイング素材の形式のパブリック仕様へのポインターが含まれています。
This registry has been initially populated with the value in Table 1.
このレジストリは、最初に表1の値が入力されています。
This specification establishes the "ACE Groupcomm Profiles" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.
この仕様は、「制約環境の認証と認証（ACE）」レジストリグループ内の「ACE GroupCommプロファイル」IANAレジストリを確立します。
Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in Section 11.14.
このレジストリの値は、以下に示すように、さまざまな登録ポリシーでカバーされています。一部のポリシーでは、専門家のレビューが必要です。ガイドラインはセクション11.14に記載されています。
The columns of this registry are:
このレジストリの列は次のとおりです。
Name:
名前：
The name of the application profile.
アプリケーションプロファイルの名前。
Description:
説明：
Text giving an overview of the application profile and the context it is developed for.
アプリケーションプロファイルとそれが開発されたコンテキストの概要を示すテキスト。
CBOR Value:
CBOR値：
CBOR abbreviation for the name of this application profile. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".
このアプリケーションプロファイルの名前のCbor略語。これらの値は一意でなければなりません。値は、正の整数または負の整数である可能性があります。さまざまな範囲の値は、異なる登録ポリシーを使用しています[RFC8126]。-256〜255の整数値は、「専門家のレビューを伴う標準アクション」として指定されています。-65536から-257、256〜65535の整数値は、「仕様が必要」として指定されています。65535を超える整数値は、「専門家のレビュー」として指定されています。-65536未満の整数値は、「私的使用」としてマークされています。
Reference:
参照：
This field contains a pointer to the public specification for this application profile, if one exists.
このフィールドには、存在する場合、このアプリケーションプロファイルの公開仕様へのポインターが含まれています。
This registry has been initially populated with the value in Table 2.
このレジストリは、最初に表2の値が入力されています。
This specification establishes the "ACE Groupcomm Policies" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.
この仕様は、「制約環境の認証と認証（ACE）」レジストリグループ内の「ACE GroupCommポリシー」IANAレジストリを確立します。
Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in Section 11.14.
このレジストリの値は、以下に示すように、さまざまな登録ポリシーでカバーされています。一部のポリシーでは、専門家のレビューが必要です。ガイドラインはセクション11.14に記載されています。
The columns of this registry are:
このレジストリの列は次のとおりです。
Name:
名前：
The name of the group communication policy.
グループコミュニケーションポリシーの名前。
CBOR Label:
CBORラベル：
The value to be used to identify this group communication policy. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".
このグループコミュニケーションポリシーを特定するために使用される値。これらの値は一意でなければなりません。値は、正の整数、負の整数、またはテキスト文字列です。さまざまな範囲の値は、異なる登録ポリシーを使用しています[RFC8126]。-256から255の整数値と長さ1のテキスト文字列は、「専門家のレビューを伴う標準アクション」として指定されています。-65536から-257、および256から65535の整数値、および長さ2のテキスト文字列は、「仕様が必要」として指定されています。65535を超える整数値と2を超える長さのテキスト文字列は、「専門家のレビュー」として指定されています。-65536未満の整数値は、「私的使用」としてマークされています。
CBOR Type:
CBORタイプ：
The CBOR type used to encode the value of this group communication policy.
このグループコミュニケーションポリシーの価値をエンコードするために使用されるCBORタイプ。
Description:
説明：
This field contains a brief description for this group communication policy.
このフィールドには、このグループコミュニケーションポリシーの簡単な説明が含まれています。
Reference:
参照：
This field contains a pointer to the public specification for this group communication policy and its format, if one exists.
このフィールドには、存在する場合、このグループ通信ポリシーとその形式の公開仕様へのポインターが含まれています。
This registry has been initially populated with the values in Table 3.
このレジストリには、最初に表3の値が入力されています。
This specification establishes the "Sequence Number Synchronization Methods" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.
この仕様は、「制約された環境（ACE）の認証と承認」レジストリグループ内の「シーケンス番号同期方法」IANAレジストリを確立します。
Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in Section 11.14.
このレジストリの値は、以下に示すように、さまざまな登録ポリシーでカバーされています。一部のポリシーでは、専門家のレビューが必要です。ガイドラインはセクション11.14に記載されています。
The columns of this registry are:
このレジストリの列は次のとおりです。
Name:
名前：
The name of the sequence number synchronization method.
シーケンス番号の同期方法の名前。
Value:
値：
The value to be used to identify this sequence number synchronization method. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".
このシーケンス番号同期方法を識別するために使用される値。これらの値は一意でなければなりません。値は、正の整数、負の整数、またはテキスト文字列です。さまざまな範囲の値は、異なる登録ポリシーを使用しています[RFC8126]。-256から255の整数値と長さ1のテキスト文字列は、「専門家のレビューを伴う標準アクション」として指定されています。-65536から-257、および256から65535の整数値、および長さ2のテキスト文字列は、「仕様が必要」として指定されています。65535を超える整数値と2を超える長さのテキスト文字列は、「専門家のレビュー」として指定されています。-65536未満の整数値は、「私的使用」としてマークされています。
Description:
説明：
This field contains a brief description for this sequence number synchronization method.
このフィールドには、このシーケンス番号同期方法の簡単な説明が含まれています。
Reference:
参照：
This field contains a pointer to the public specification describing the sequence number synchronization method.
このフィールドには、シーケンス番号の同期方法を説明する公開仕様へのポインターが含まれています。
This specification establishes the "ACE Groupcomm Errors" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.
この仕様は、「制約環境（ACE）の認証と認証」レジストリグループ内の「ACE GroupCommエラー」IANAレジストリを確立します。
Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in Section 11.14.
このレジストリの値は、以下に示すように、さまざまな登録ポリシーでカバーされています。一部のポリシーでは、専門家のレビューが必要です。ガイドラインはセクション11.14に記載されています。
The columns of this registry are:
このレジストリの列は次のとおりです。
Value:
値：
The value to be used to identify the error. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".
エラーを識別するために使用される値。これらの値は一意でなければなりません。値は、正の整数または負の整数である可能性があります。さまざまな範囲の値は、異なる登録ポリシーを使用しています[RFC8126]。-256〜255の整数値は、「専門家のレビューを伴う標準アクション」として指定されています。-65536から-257、256〜65535の整数値は、「仕様が必要」として指定されています。65535を超える整数値は、「専門家のレビュー」として指定されています。-65536未満の整数値は、「私的使用」としてマークされています。
Description:
説明：
This field contains a brief description of the error.
このフィールドには、エラーの簡単な説明が含まれています。
Reference:
参照：
This field contains a pointer to the public specification defining the error, if one exists.
このフィールドには、エラーが存在する場合、エラーを定義する公開仕様へのポインターが含まれています。
This registry has been initially populated with the values in Table 6. The "Reference" column for all of these entries refers to this document.
このレジストリには、最初に表6の値が入力されています。これらすべてのエントリの「参照」列は、このドキュメントを参照しています。
This specification establishes the "ACE Groupcomm Rekeying Schemes" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.
この仕様は、「制約環境（ACE）の認証と認証」レジストリグループ内の「ACE GroupComm Rekeing Schemes」IANAレジストリを確立します。
Values in this registry are covered by different registration policies as indicated below. Some policies require Expert Review; guidelines are provided in Section 11.14.
このレジストリの値は、以下に示すように、さまざまな登録ポリシーでカバーされています。一部のポリシーでは、専門家のレビューが必要です。ガイドラインはセクション11.14に記載されています。
The columns of this registry are:
このレジストリの列は次のとおりです。
Value:
値：
The value to be used to identify the group rekeying scheme. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".
グループの再キーイングスキームを特定するために使用される値。これらの値は一意でなければなりません。値は、正の整数または負の整数である可能性があります。さまざまな範囲の値は、異なる登録ポリシーを使用しています[RFC8126]。-256〜255の整数値は、「専門家のレビューを伴う標準アクション」として指定されています。-65536から-257、256〜65535の整数値は、「仕様が必要」として指定されています。65535を超える整数値は、「専門家のレビュー」として指定されています。-65536未満の整数値は、「私的使用」としてマークされています。
Name:
名前：
The name of the group rekeying scheme.
グループの再キーイングスキームの名前。
Description:
説明：
This field contains a brief description of the group rekeying scheme.
このフィールドには、グループの再キーイングスキームの簡単な説明が含まれています。
Reference:
参照：
This field contains a pointer to the public specification defining the group rekeying scheme, if one exists.
このフィールドには、存在する場合、グループの再キーイングスキームを定義する公開仕様へのポインターが含まれています。
This registry has been initially populated with the value in Table 4.
このレジストリは、最初に表4に値が入力されています。
The IANA registries established in this document are defined as Expert Review. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude.
このドキュメントで確立されたIANAレジストリは、専門家のレビューとして定義されています。このセクションでは、専門家が探しているものについてのいくつかの一般的なガイドラインを示しますが、それらは理由で専門家に指定されているため、実質的な緯度を与えられるべきです。
Expert Reviewers should take into consideration the following points:
専門家のレビュアーは、次のポイントを考慮する必要があります。
* 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 Track 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 assignments. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of the device it will be used on, and the number of code points left that encode to that size.
* 専門家は、ポイント割り当てを承認する際に、フィールドの予想される使用を考慮する必要があります。標準の追跡ドキュメントの範囲があるという事実は、標準の追跡ドキュメントがその範囲外に割り当てられたポイントを持つことができないことを意味するものではありません。エンコードされた値の長さは、その長さのコードポイントの数、使用されるデバイスのサイズ、およびそのサイズにエンコードするコードポイントの数と比較して計量する必要があります。
[CBOR.Tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<https://www.iana.org/assignments/cbor-tags/>.
[CoAP.Content.Formats]
IANA, "CoAP Content-Formats",
<https://www.iana.org/assignments/core-parameters/>.
[COSE.Algorithms]
IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose/>.
[COSE.Header.Parameters]
IANA, "COSE Header Parameters",
<https://www.iana.org/assignments/cose/>.
[COSE.Key.Types]
IANA, "COSE Key Types",
<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>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[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>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[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>.
[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>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/info/rfc9053>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
[RFC9237] Bormann, C., "An Authorization Information Format (AIF)
for Authentication and Authorization for Constrained
Environments (ACE)", RFC 9237, DOI 10.17487/RFC9237,
August 2022, <https://www.rfc-editor.org/info/rfc9237>.
[RFC9290] Fossati, T. and C. Bormann, "Concise Problem Details for
Constrained Application Protocol (CoAP) APIs", RFC 9290,
DOI 10.17487/RFC9290, October 2022,
<https://www.rfc-editor.org/info/rfc9290>.
[RFC9338] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Countersignatures", STD 96, RFC 9338,
DOI 10.17487/RFC9338, December 2022,
<https://www.rfc-editor.org/info/rfc9338>.
[C509-CERT]
Preuß Mattsson, J., Selander, G., Raza, S., Höglund, J.,
and M. Furuhed, "CBOR Encoded X.509 Certificates (C509
Certificates)", Work in Progress, Internet-Draft, draft-
ietf-cose-cbor-encoded-cert-11, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-11>.
[CoAP-PUBSUB]
Jimenez, J., Koster, M., and A. Keränen, "A publish-
subscribe architecture for the Constrained Application
Protocol (CoAP)", Work in Progress, Internet-Draft, draft-
ietf-core-coap-pubsub-14, 18 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
coap-pubsub-14>.
[GROUP-CoAP]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
11, 24 April 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-groupcomm-bis-11>.
[GROUP-OSCORE]
Tiloca, M., Selander, G., Palombini, F., Preuß Mattsson,
J., and R. Höglund, "Group Object Security for Constrained
RESTful Environments (Group OSCORE)", Work in Progress,
Internet-Draft, draft-ietf-core-oscore-groupcomm-22, 28
August 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-core-oscore-groupcomm-22>.
[OSCORE-DISCOVERY]
Tiloca, M., Amsüss, C., and P. Van der Stok, "Discovery of
OSCORE Groups with the CoRE Resource Directory", Work in
Progress, Internet-Draft, draft-tiloca-core-oscore-
discovery-16, 4 September 2024,
<https://datatracker.ietf.org/doc/html/draft-tiloca-core-
oscore-discovery-16>.
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Specification", RFC 2093,
DOI 10.17487/RFC2093, July 1997,
<https://www.rfc-editor.org/info/rfc2093>.
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture", RFC 2094,
DOI 10.17487/RFC2094, July 1997,
<https://www.rfc-editor.org/info/rfc2094>.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627,
DOI 10.17487/RFC2627, June 1999,
<https://www.rfc-editor.org/info/rfc2627>.
[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>.
[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>.
[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>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[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>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[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>.
[RFC9202] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE)", RFC 9202,
DOI 10.17487/RFC9202, August 2022,
<https://www.rfc-editor.org/info/rfc9202>.
[RFC9203] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"The Object Security for Constrained RESTful Environments
(OSCORE) Profile of the Authentication and Authorization
for Constrained Environments (ACE) Framework", RFC 9203,
DOI 10.17487/RFC9203, August 2022,
<https://www.rfc-editor.org/info/rfc9203>.
[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>.
[RFC9431] Sengul, C. and A. Kirby, "Message Queuing Telemetry
Transport (MQTT) and Transport Layer Security (TLS)
Profile of Authentication and Authorization for
Constrained Environments (ACE) Framework", RFC 9431,
DOI 10.17487/RFC9431, July 2023,
<https://www.rfc-editor.org/info/rfc9431>.
This section lists the requirements for application profiles of this specification for the convenience of application profile designers.
このセクションには、アプリケーションプロファイルデザイナーの利便性のためのこの仕様のアプリケーションプロファイルの要件をリストします。
REQ1: Specify the format and encoding of scope. This includes defining the set of possible roles and their identifiers, as well as the corresponding encoding to use in the scope entries according to the used scope format (see Section 3.1).
req1：スコープの形式とエンコードを指定します。これには、可能な役割のセットとその識別子の定義、および使用されるスコープ形式に従ってスコープエントリで使用する対応するエンコーディングが含まれます（セクション3.1を参照）。
REQ2: If scope uses AIF, register its specific instance of "Toid" and "Tperm" as media type parameters and a corresponding Content-Format, as per the guidelines in [RFC9237].
Req2：ScopeがAIFを使用する場合、[RFC9237]のガイドラインに従って、「TOID」と「TPERM」の特定のインスタンスをメディア型パラメーターおよび対応するコンテンツフォーマットとして登録します。
REQ3: If used, specify the acceptable values for the 'sign_alg' parameter (see Section 3.3.1).
REQ3：使用する場合は、「SIGN_ALG」パラメーターの許容値を指定します（セクション3.3.1を参照）。
REQ4: If used, specify the acceptable values and structure for the 'sign_parameters' parameter (see Section 3.3.1).
REQ4：使用する場合は、「SIGN_PARAMETERS」パラメーターの許容値と構造を指定します（セクション3.3.1を参照）。
REQ5: If used, specify the acceptable values and structure for the 'sign_key_parameters' parameter (see Section 3.3.1).
REQ5：使用する場合は、「SIGN_KEY_PARAMETERS」パラメーターの許容値と構造を指定します（セクション3.3.1を参照）。
REQ6: Specify the acceptable formats for authentication credentials and, if applicable, the acceptable values for the 'cred_fmt' parameter (see Section 3.3.1).
Req6：認証資格情報の許容形式を指定し、該当する場合は「CRED_FMT」パラメーターの許容値を指定します（セクション3.3.1を参照）。
REQ7: If the value of the GROUPNAME URI path and the group name in the access token scope ('gname' in Section 3.1) are not required to coincide, specify the mechanism to map the GROUPNAME value in the URI to the group name (see Section 4.1).
Req7：グループ名URIパスの値とアクセストークンスコープのグループ名（セクション3.1の「GNAME」）が一致する必要がない場合は、URIのグループ名をグループ名にマッピングするメカニズムを指定します（参照セクション4.1）。
REQ8: Define whether the KDC has an authentication credential as required for the correct group operation and if this has to be provided through the 'kdc_cred' parameter (see Sections 4.1 and 4.3.1).
Req8：KDCには、正しいグループ操作に必要な認証資格情報があるかどうか、および「kdc_cred」パラメーターを介してこれを提供する必要があるかどうかを定義します（セクション4.1および4.3.1を参照）。
REQ9: Specify if any part of the KDC interface as defined in this document is not supported by the KDC (see Section 4.1).
REQ9：このドキュメントで定義されているKDCインターフェイスの一部がKDCでサポートされていないかどうかを指定します（セクション4.1を参照）。
REQ10: Register a Resource Type for the group-membership resources, which is used to discover the correct URL for sending a Join Request to the KDC (see Section 4.1).
REQ10：グループメンバーシップリソースのリソースタイプを登録します。これは、KDCに参加要求を送信するための正しいURLを発見するために使用されます（セクション4.1を参照）。
REQ11: Define what specific actions (e.g., CoAP methods) are allowed on each resource that are accessible through the KDC interface, depending on: whether the Client is a current group member; the roles that a Client is authorized to take as per the obtained access token (see Section 3.1); and the roles that the Client has as a current group member.
req11：次のことに応じて、KDCインターフェイスを介してアクセス可能な各リソースで許可されている特定のアクション（COAPメソッドなど）を定義します。クライアントが現在のグループメンバーであるかどうか。クライアントが取得したアクセストークンに従って取得することを許可されている役割（セクション3.1を参照）。クライアントが現在のグループメンバーとして持っている役割。
REQ12: Categorize possible newly defined operations for Clients into primary operations expected to be minimally supported and secondary operations, and provide accompanying considerations (see Section 4.1.1).
Req12：クライアントの可能な新たに定義された操作を、最小限のサポートと二次運用と予想される主要な操作に分類し、それに伴う考慮事項を提供します（セクション4.1.1を参照）。
REQ13: Specify the encoding of group identifiers (see Section 4.2.1).
Req13：グループ識別子のエンコードを指定します（セクション4.2.1を参照）。
REQ14: Specify the approaches used to compute and verify the PoP evidence to include in the 'client_cred_verify' parameter and which of those approaches is used in which case (see Section 4.3.1).
Req14：「client_cred_verify」パラメーターに含まれるポップエビデンスを計算して検証するために使用されるアプローチを指定し、どのアプローチが使用されているのかを指定します（セクション4.3.1を参照）。
REQ15: Specify how the nonce N_S is generated, if the access token is not provided to the KDC through the Token Transfer Request sent to the /authz-info endpoint (e.g., the access token is instead transferred during the establishment of a secure communication association).
Req15： /authz-infoエンドポイントに送信されたトークン転送リクエストを介してアクセストークンがKDCに提供されない場合、Nonce N_Sの生成方法を指定します（たとえば、安全な通信協会の設立中にアクセストークンが転送されます）。
REQ16: Define the initial value of the version number for the group keying material (see Section 4.3.1).
Req16：グループキーイングマテリアルのバージョン番号の初期値を定義します（セクション4.3.1を参照）。
REQ17: Specify the format of the group keying material that is conveyed in the 'key' parameter (see Section 4.3.1).
Req17：「キー」パラメーターで伝えられるグループキーイング素材の形式を指定します（セクション4.3.1を参照）。
REQ18: Specify the acceptable values of the 'gkty' parameter (see Section 4.3.1). For each of them, register a corresponding entry in the "ACE Groupcomm Key Types" IANA registry if such an entry does not exist already.
req18：「gkty」パラメーターの許容値を指定します（セクション4.3.1を参照）。それらのそれぞれについて、そのようなエントリがまだ存在していない場合は、「ACE GroupCommキータイプ」IANAレジストリに対応するエントリを登録します。
REQ19: Specify and register the application profile identifier (see Section 4.3.1).
Req19：アプリケーションプロファイル識別子を指定して登録します（セクション4.3.1を参照）。
REQ20: If used, specify the format and default values of the entries of the CBOR map to include in the 'group_policies' parameter (see Section 4.3.1).
Req20：使用する場合は、cborマップのエントリの形式とデフォルト値を指定して、「group_policies」パラメーターに含めます（セクション4.3.1を参照）。
REQ21: Specify the approaches used to compute and verify the PoP evidence to include in the 'kdc_cred_verify' parameter and which of those approaches is used in which case (see Sections 4.3.1 and 4.5.1). If external signature verifiers are supported, specify how those provide a nonce to the KDC to be used for computing the PoP evidence (see Section 4.5.1).
Req21：「KDC_CRED_VERIFY」パラメーターに含まれるポップエビデンスを計算および検証するために使用されるアプローチを指定し、どのアプローチが使用されているのかを指定します（セクション4.3.1および4.5.1を参照）。外部署名検証がサポートされている場合は、ポップエビデンスの計算に使用されるKDCに非CEを提供する方法を指定します（セクション4.5.1を参照）。
REQ22: Specify the communication protocol that members of the group use to communicate with each other (e.g., CoAP for group communication).
Req22：グループのメンバーが互いに通信するために使用する通信プロトコルを指定します（たとえば、グループコミュニケーションのためのCOAP）。
REQ23: Specify the security protocol that members of the group use to protect the group communication (e.g., Group OSCORE). This must provide encryption, integrity, and replay protection.
REQ23：グループのメンバーがグループ通信を保護するために使用するセキュリティプロトコルを指定します（例：Group Oscore）。これは、暗号化、完全性、およびリプレイ保護を提供する必要があります。
REQ24: Specify how the communication is secured between the Client and the KDC. Optionally, specify a transport profile of ACE [RFC9200] to use between the Client and the KDC (see Section 4.3.1.1).
Req24：クライアントとKDCの間で通信がどのように保護されるかを指定します。オプションで、クライアントとKDCの間で使用するACE [RFC9200]の輸送プロファイルを指定します（セクション4.3.1.1を参照）。
REQ25: Specify the format of the node identifiers of group members (see Sections 4.3.1 and 4.4.1).
Req25：グループメンバーのノード識別子の形式を指定します（セクション4.3.1および4.4.1を参照）。
REQ26: Specify policies at the KDC to handle node identifiers that are included in the 'get_creds' parameter but are not associated with any current group member (see Section 4.4.1).
Req26：「get_creds」パラメーターに含まれるが、現在のグループメンバーに関連付けられていないノード識別子を処理するようにKDCでポリシーを指定します（セクション4.4.1を参照）。
REQ27: Specify the format of (newly generated) individual keying material for group members or of the information to derive such keying material, as well as the corresponding CBOR map key that has to be registered in the "ACE Groupcomm Parameters" registry (see Sections 4.8.1 and 4.8.2).
Req27：グループメンバーまたはそのようなキーイング材料を導出するための情報の（新しく生成された）個々のキーイング資料の形式を指定し、「ACE GroupCommパラメーター」レジストリに登録する対応するCBORマップキーを指定します（セクションを参照4.8.1および4.8.2）。
REQ28: Specify which CBOR tag is used for identifying the semantics of binary scopes, or register a new CBOR tag if a suitable one does not exist already (see Section 7).
REQ28：バイナリスコープのセマンティクスを識別するために使用されるCBORタグを指定するか、適切なCBORタグがまだ存在しない場合は新しいCBORタグを登録します（セクション7を参照）。
REQ29: Categorize newly defined parameters according to the same criteria of Section 8.
Req29：セクション8の同じ基準に従って、新たに定義されたパラメーターを分類します。
REQ30: Define whether Clients must, should, or may support the conditional parameters defined in Section 8 and under which circumstances.
Req30：セクション8およびその状況下で定義されている条件付きパラメーターをクライアントが必要とする必要があるか、またはサポートする必要があるか、またはサポートできるかどうかを定義します。
OPT1: Optionally, if the textual format of scope is used, specify CBOR values to use for abbreviating the role identifiers in the group (see Section 3.1).
OPT1：オプションで、スコープのテキスト形式が使用されている場合、グループの役割識別子を略すために使用するCBOR値を指定します（セクション3.1を参照）。
OPT2: Optionally, specify the additional parameters used in the exchange of Token Transfer Request and Response (see Section 3.3).
OPT2：オプションで、トークン転送要求と応答の交換で使用される追加のパラメーターを指定します（セクション3.3を参照）。
OPT3: Optionally, specify the negotiation of parameter values for signature algorithm and signature keys, if the 'sign_info' parameter is not used (see Section 3.3).
OPT3：オプションで、「SIGN_INFO」パラメーターが使用されていない場合、署名アルゴリズムと署名キーのパラメーター値のネゴシエーションを指定します（セクション3.3を参照）。
OPT4: Optionally, specify possible or required payload formats for specific error cases (see Section 4.1.2).
OPT4：オプションで、特定のエラーケースに対して可能なペイロード形式または必要なペイロード形式を指定します（セクション4.1.2を参照）。
OPT5: Optionally, specify additional identifiers of error types as values of the 'error-id' field within the Custom Problem Detail entry 'ace-groupcomm-error' (see Section 4.1.2).
OPT5：オプションで、エラータイプの追加の識別子を、カスタム問題の詳細エントリ「ACE-GroupComm-Error」内の「エラーID」フィールドの値として指定します（セクション4.1.2を参照）。
OPT6: Optionally, specify the encoding of the 'creds_repo' parameter if the default one is not used (see Section 4.3.1).
OPT6：オプションで、デフォルトのパラメーターが使用されていない場合は、「CREDS_REPO」パラメーターのエンコードを指定します（セクション4.3.1を参照）。
OPT7: Optionally, specify the functionalities implemented at the resource hosted by the Client at the URI indicated in the 'control_uri' parameter, including the encoding of exchanged messages and other details (see Section 4.3.1).
OPT7：オプションで、交換されたメッセージやその他の詳細のエンコードを含む「Control_uri」パラメーターに示されているURIのクライアントがホストするリソースで実装された機能を指定します（セクション4.3.1を参照）。
OPT8: Optionally, specify the behavior of the POST handler of group-membership resources, for the case when it fails to retrieve an authentication credential for the specific Client (see Section 4.3.1).
OPT8：オプションで、特定のクライアントの認証資格情報を取得できない場合、グループメンバーシップリソースのポストハンドラーの動作を指定します（セクション4.3.1を参照）。
OPT9: Optionally, define a default group rekeying scheme to refer to in case the 'rekeying_scheme' parameter is not included in the Join Response (see Section 4.3.1).
OPT9：オプションで、「Rekeying_scheme」パラメーターが参加応答に含まれていない場合に参照するデフォルトのグループの再キーイングスキームを定義します（セクション4.3.1を参照）。
OPT10: Optionally, specify the functionalities implemented at the resource hosted by the Client at the URI indicated in the 'control_group_uri' parameter, including the encoding of exchanged messages and other details (see Section 4.3.1).
OPT10：オプションで、「Control_Group_uri」パラメーターに示されているURIのクライアントがホストするリソースで実装された機能を指定します。
OPT11: Optionally, specify policies that instruct Clients to retain messages and for how long, if those are unsuccessfully decrypted (see Section 4.8.1.1). This makes it possible for Clients to decrypt such messages after obtaining updated keying material.
OPT11：オプションで、クライアントにメッセージを保持するように指示するポリシーを指定します。これにより、クライアントは更新されたキーイング素材を取得した後にそのようなメッセージを解読することができます。
OPT12: Optionally, specify for the KDC to perform a group rekeying when receiving a Key Renewal Request, together with or instead of renewing individual keying material (see Section 4.8.2.1).
OPT12：オプションで、個々のキーイング素材と一緒に、または更新する代わりに、KDCが主要な更新要求を受信するときに再キーイングを実行するように指定します（セクション4.8.2.1を参照）。
OPT13: Optionally, specify how the identifier of a group member's authentication credential is included in requests sent to other group members (see Section 4.9.1.1).
OPT13：オプションで、グループメンバーの認証資格情報の識別子が他のグループメンバーに送信されたリクエストに含まれる方法を指定します（セクション4.9.1.1を参照）。
OPT14: Optionally, specify additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme (see Section 6).
OPT14：オプションで、「ポイントツーポイント」グループの再キーイングスキームのメッセージを再キーイングすることに含める追加情報を指定します（セクション6を参照）。
As defined in Section 8.1 of [RFC9053], future algorithms can be registered in the "COSE Algorithms" registry [COSE.Algorithms] as specifying none or multiple COSE capabilities.
[RFC9053]のセクション8.1で定義されているように、将来のアルゴリズムは、「COSEアルゴリズム」レジストリ[COSE.ALGORITHMS]に登録されていないか、複数のCOSE機能を指定することができます。
To enable the seamless use of such future registered algorithms, this section defines a general, agile format for each 'sign_info_entry' of the 'sign_info' parameter in the Token Transfer Response; see Section 3.3.1.
このような将来の登録されたアルゴリズムのシームレスな使用を有効にするために、このセクションでは、トークン転送応答の「sign_info」パラメーターの各「sign_info_entry」の一般的なアジャイル形式を定義します。セクション3.3.1を参照してください。
If any of the currently registered COSE algorithms are considered, using this general format yields the same structure of 'sign_info_entry' defined in this document, thus ensuring backward compatibility.
現在登録されているCOSEアルゴリズムのいずれかが考慮されている場合、この一般的な形式を使用すると、このドキュメントで定義されている「sign_info_entry」の構造が得られ、したがって、後方互換性が確保されます。
The format of each 'sign_info_entry' (see Section 3.3.1) is generalized as follows.
各「SIGN_INFO_ENTRY」の形式（セクション3.3.1を参照）は、次のように一般化されています。
* 'sign_parameters' includes N >= 0 elements, each of which is a COSE capability of the signature algorithm indicated in 'sign_alg'.
* 「Sign_Parameters」にはn> = 0要素が含まれ、それぞれが「sign_alg」に示されている署名アルゴリズムのCOSE機能です。
In particular, 'sign_parameters' has the same format and value of the COSE capabilities array for the signature algorithm indicated in 'sign_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry [COSE.Algorithms].
特に、「SIGN_PARAMETERS」は、「COSEアルゴリズム」レジストリ[COSE.ALGORITHMS]の「COSEアルゴリズム」の「機能」列のアルゴリズムに指定されているように、「SIGN_ALG」に示されている署名アルゴリズムのCOSE機能アレイと同じ形式と値を持っています。。
* 'sign_key_parameters' is replaced by N elements 'sign_capab', each of which is a CBOR array.
* 「sign_key_parameters」は、n要素「sign_capab」に置き換えられ、それぞれがCBORアレイです。
The i-th 'sign_capab' array (i = 0, ..., N-1) is the array of COSE capabilities for the algorithm capability specified in 'sign_parameters'[i].
i-th 'sign_capab'配列（i = 0、...、n-1）は、「sign_parameters」[i]で指定されたアルゴリズム機能のCOSE機能の配列です。
In particular, each 'sign_capab' array has the same format and value of the COSE capabilities array for the algorithm capability specified in 'sign_parameters'[i].
特に、各「SIGN_CAPAB」アレイには、「SIGN_PARAMETERS」[i]で指定されたアルゴリズム機能のCOSE機能アレイと同じ形式と値があります。
Such a COSE capabilities array is currently defined for the algorithm capability COSE key type in the "Capabilities" column of the "COSE Key Types" registry [COSE.Key.Types].
このようなCOSE機能アレイは現在、「COSEキータイプ」レジストリ[cose.key.types]の「機能」列のアルゴリズム機能COSEキータイプに対して定義されています。
sign_info_entry =
[
id : gname / [+ gname],
sign_alg : int / tstr,
sign_parameters : [* alg_capab : any],
* sign_capab : [* capab : any],
cred_fmt : int / null
]
gname = tstr
Figure 38: 'sign_info_entry' with a General Format
図38：一般的な形式の「Sign_info_entry」
The following individuals were helpful in shaping this document: Christian Amsüss, Carsten Bormann, Roman Danyliw, Martin Duke, Thomas Fossati, Vidhi Goel, Rikard Höglund, Ben Kaduk, Erik Kline, Warren Kumari, Watson Ladd, Daniel Migault, John Preuß Mattsson, Zaheduzzaman Sarker, Jim Schaad, Ludwig Seitz, Göran Selander, Cigdem Sengul, Dave Thaler, Henry Thompson, Peter van der Stok, and Paul Wouters.
次の個人は、この文書の形成に役立ちました：クリスチャン・アムス、カルステン・ボルマン、ロマン・ダニリウ、マーティン・デューク、トーマス・フォッサティ、ヴィディ・ゲエル、リカード・ヘグルンド、ベン・カドゥク、エリック・クライン、ウォーレン・クマリ、ワトソン・ラッド、ダニエル・ミゴールZaheduzzaman Sarker、Jim Schaad、Ludwig Seitz、GöranSelander、Cigdem Sengul、Dave Thaler、Henry Thompson、Peter van der Stok、Paul Wouters。
The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next project CRITISEC, by the H2020 project SIFIS-Home (Grant agreement 952652), and by the EIT-Digital High Impact Initiative ACTIVE.
この文書の作業は、スウェーデンのイノベーションエージェンシーVinnovaとCeltic-Next Project Critisec、H2020 Project Sifis-Home（Grant Agreement 952652）、およびEit-Digital High Impact Inciative Activeによって部分的にサポートされています。
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