]> RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden marco.tiloca@ri.se

Security ACE Working Group Internet-Draft RFC 9594 defines a Key Distribution Center (KDC) to provision keying material for secure group communication, using the Authentication and Authorization for Constrained Environments (ACE) framework. An instance of KDC is the Group Manager for provisioning keying material in group communication scenarios that use the Constrained Application Protocol (CoAP) and the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). To make the pairwise mode of Group OSCORE post-quantum secure, it is possible to rely on a quantum-resistant Key Encapsulation Mechanism (KEM) as the Pairwise Key Agreement Algorithm used to derive pairwise keys. This document extends the interface of the ACE-based Group Manager to enable the exchange of KEM public keys and KEM ciphertexts among group members via the Group Manager, thus making the derivation of pairwise keys in Group OSCORE post-quantum secure. Discussion Venues Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (ace@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Building on Object Security for Constrained RESTful Environments (OSCORE) , the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) provides end-to-end security for the Constrained Application Protocol (CoAP) when used in group communication setups . An OSCORE group is associated with a Group Manager, i.e., an entity responsible for managing identifiers and keying material in the group and for handling the join process to add group members, among other tasks. As a notable feature, two group members can exchange messages protected with the pairwise mode of Group OSCORE (see ), achieving pairwise data confidentiality and source authentication by means of integrity tags. That is, the message sender performs authenticated encryption of the CoAP message by using a symmetric pairwise key that is exclusively shared with another group member as the intended message recipient. Symmetric pairwise keys are derived from a pairwise shared secret, which in turn is computed from the asymmetric keys of the message sender and recipient, ensuring authenticated key agreement. In the event that a Cryptographically Relevant Quantum Computer (CRQC) is constructed, drop-in replacements are not available for the Pairwise Key Agreement Algorithm (see ), which is used to compute the shared secret from which pairwise keys are derived (see ). In particular, the available Pairwise Key Agreement Algorithms are based on a direct Elliptic Curve Diffie-Hellman Static-Static key agreement . At the time of writing, there is no standardized Diffie-Hellman/Non-Interactive Key Exchange (DH/NIKE) that can be used for post-quantum secure establishment of the shared secret, which makes the pairwise mode of Group OSCORE vulnerable to quantum attacks. This can be addressed by using a quantum-resistant Key Encapsulation Mechanism (KEM), such as ML-KEM , as the Pairwise Key Agreement Algorithm used to derive pairwise keys . Building on the Authentication and Authorization for Constrained Environments (ACE) framework , the specification defines a Key Distribution Center (KDC) to provision keying material for secure group communication. The specification is an application profile of and defines an instance of KDC, i.e., the Group Manager for provisioning keying material in group communication scenarios that use CoAP and the security protocol Group OSCORE. This document extends the interface of the Group Manager defined in to enable the exchange of KEM public keys and KEM ciphertexts among group members via the Group Manager. This facilitates the use of a KEM-based Pairwise Key Agreement Algorithm, thus making the derivation of pairwise keys in Group OSCORE post-quantum secure. updates how the requirements listed in are additionally fulfilled.

Terminology 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 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with:

• The terms and concepts related to Concise Data Definition Language (CDDL) , Concise Binary Object Representation (CBOR) , and CBOR Object Signing and Encryption (COSE) .
• The terms and concepts related to CoAP and group communication for CoAP .
• The terms and concepts for protection and processing of CoAP messages through OSCORE and through Group OSCORE in group communication scenarios. These especially include:
  • Group Manager, as the entity responsible for one or more groups where communications are secured with Group OSCORE.
  • Authentication credential, as the set of information associated with an entity, including that entity's public key and parameters associated with the public key.
  • Group mode: the mode of Group OSCORE providing group-level data confidentiality and providing source authentication through a signature embedded in the protected CoAP message (see ).
  • Pairwise mode: the mode of Group OSCORE used for providing pairwise secure communication between two members of an OSCORE group (see ).
  • Pairwise keys: symmetric keys used to process messages with the pairwise mode of Group OSCORE.
  • Pairwise Key Agreement Algorithm: the algorithm used in Group OSCORE for computing a pairwise shared secret from which pairwise keys are derived (see ).
• The alternative derivation of pairwise keys as defined in , for the case where the Pairwise Key Agreement Algorithm used in the OSCORE group is a quantum-resistant Key Encapsulation Mechanism (KEM).

Furthermore, readers are expected to be familiar with:

• The terms and concepts described in the ACE framework for authentication and authorization . The terminology for entities in the considered architecture is defined in OAuth 2.0 . This includes Client (C), Resource Server (RS), and Authorization Server (AS). Unless otherwise indicated, 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. The CoAP definition, which is "[a]n entity participating in the CoAP protocol" , is not used in this document.
• The terms and concepts related to the message formats and processing specified in , for provisioning and renewing keying material in group communication scenarios by using the ACE framework, through a Key Distribution Center (KDC) acting as Resource Server. These include the abbreviations REQx and OPTx denoting the numbered mandatory-to-address and optional-to-address requirements, respectively. In particular, the abbreviations REQx and OPTx refer to the requirements initially specified in and possibly updated in of the present document.
• The terms and concepts related to the application profile of specified in , which defines the Group Manager as an instance of KDC to provision keying material for Group OSCORE. These especially include:
  • Requester: member of an OSCORE group that sends request messages to other members of the group.
  • Responder: member of an OSCORE group that receives request messages from other members of the group. A responder may reply, by sending a response message to the requester which has sent the request message.
  • Monitor: member of an OSCORE group that is configured as a responder and never sends response messages protected with Group OSCORE. This corresponds to the term "silent server" used in .
  • Signature-only group: an OSCORE group that uses only the group mode (see ).
  • Pairwise-only group: an OSCORE group that uses only the pairwise mode (see ).
  • GROUPNAME: The text string used in URIs to identify a group. Once established, it is invariant. Its value coincides with the group name of the associated group.
  • 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.

Finally, this document uses the following term:

• KEM-based group: an OSCORE group that uses the pairwise mode and uses a KEM as Pairwise Key Agreement Algorithm.

Notations Throughout this document, examples for CBOR data items are expressed in CBOR extended diagnostic notation as defined in and ("diagnostic notation"). Diagnostic notation comments are often used to provide a textual representation of the parameters' keys and values. In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in of . For example, {e'kem_ciphertext': h'ccfa0151...1948', e'kem_pubkey_hash': h'55fc1eaa...ae05'} stands for {37: h'ccfa0151...1948', 38: h'55fc1eaa...ae05'}. Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in of . Finally, please delete this note.

Overview of New Operations This document extends the interface of the Group Manager defined in as follows. When a node exchanges a Token Transfer Request and Token Transfer Response with the Group Manager (see , the node can ask the Group Manager to provide information about the KEM-based groups that the node has been authorized to join. This is defined in . When a node joins a KEM-based group (see ):

• The Join Request sent to the Group Manager can include a KEM public key of the node to be stored at the Group Manager. This is defined in and .
• The Join Response from the Group Manager specifies the KEM used as Pairwise Key Agreement Algorithm in the group, together with corresponding parameters. This is defined in and .

When a member of a KEM-based group retrieves updated keying material from the Group Manager (see ), the Key Distribution Response from the Group Manager specifies the KEM used as Pairwise Key Agreement Algorithm in the group, together with corresponding parameters. This is defined in . When a signature verifier retrieves from the Group Manager data required to verify signatures of messages protected with the group mode of Group OSCORE and sent to a KEM-based group (see ), the Signature Verification Data Response from the Group Manager specifies the KEM used as Pairwise Key Agreement Algorithm in the group, together with corresponding parameters. This is defined in . According to the new resources defined in , a member P of a KEM-based group can perform the following actions by interacting with the Group Manager:

• Upload at the Group Manager an own KEM public key intended to any and exactly one other member of the group. This is defined in .
• Retrieve the number of own KEM public keys that are currently stored at the Group Manager as intended to other members of the group. This is defined in .
• Discard all its own KEM public keys stored at the Group Manager as intended to other members of the group. This is defined in .
• Retrieve from the Group Manager a KEM public key that a specific other group member Q uploaded at the Group Manager as intended to other members of the group. This is defined in .
• Upload at the Group Manager a KEM ciphertext, which is intended to a specific other group member Q and is computed by P using a KEM public key of Q. This is defined in .
• Retrieve from the Group Manager the KEM ciphertext that a specific other group member Q uploaded at the Group Manager as intended to P. This is defined in .

defines the operations that the group member P can perform by accessing the new resources above. Editor's note: further extend the interface at the Group Manager, to also cover the case where the KEM-based group is specifically a pairwise-only group.

Token Transferring In addition to what is defined in , the following applies to the exchange of Token Transfer Request and Token Transfer Response originally defined in .

• The Token Transfer Request MAY additionally contain the following parameter, which, if included, MUST have the corresponding values defined below (OPT2):
  • 'pqkem_info' defined in of this document, with value the CBOR simple value null (0xf6) to request information about the quantum-resistant KEM used as Pairwise Key Agreement Algorithm, the KEM algorithm parameters, the KEM key parameters, and the exact format of authentication credentials used in the KEM-based groups that the Client has been authorized to join. This is relevant if the joining node supports the pairwise mode of Group OSCORE .
  Alternatively, the joining node may retrieve this information by other means.
• If the 'pqkem_info' parameter is present in the Token Transfer Response, the following applies for each element 'pqkem_info_entry'.
  • 'id' is associated exclusively with OSCORE groups that are KEM-based groups.
  • 'pqkem_alg' takes value from the "Value" column of the "COSE Algorithms" registry .
  • 'pqkem_parameters' has the same format and value of the COSE capabilities array for the KEM algorithm indicated in 'pqkem_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry .
  • 'pqkem_key_parameters' has the same format and value of the COSE capabilities array for the COSE key type of the keys used with the KEM algorithm indicated in 'pqkem_alg', as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry .
  • 'cred_fmt' takes value from the "Label" column of the "COSE Header Parameters" registry . To align with , acceptable values denote a format of authentication credential that provides the public key as well as a comprehensive set of information related to the public key algorithm. The same considerations provided in on acceptable formats currently available for the 'cred_fmt' element of 'sign_info' apply.
  The Group Manager omits the 'pqkem_info' parameter in the Token Transfer Response even if 'pqkem_info' is included in the Token Transfer Request, in the case that all the OSCORE groups that the Client is authorized to join are not KEM-based groups.

Note that, other than through the above parameters as defined in , the joining node may have obtained such information by alternative means. For example, information conveyed in the 'pqkem_info' parameter may have been pre-configured, or the joining node may early retrieve it, e.g., by using the approach described in to discover the OSCORE group and the link to the associated group-membership resource at the Group Manager.

'pqkem_info' Parameter The 'pqkem_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 ). This parameter allows the Client and the RS to exchange information about a quantum-resistant KEM as well as about the authentication credentials and public keys to accordingly use for deriving shared secrets. Its exact semantics and content are application specific. In application profiles that build on , this parameter is used to exchange information about the KEM as well as about the authentication credentials and public keys to be used with it, in the groups indicated by the transferred access token as per its 'scope' claim (see ). When used in the Token Transfer Request sent to the KDC (see ), the 'pqkem_info' parameter specifies the CBOR simple value null (0xf6). This is done to ask for information about the KEM and about the authentication credentials used to compute shared secrets and pairwise keys, in the groups that the Client has been authorized to join or interact with. When used in the following Token Transfer Response from the KDC (see ), the 'pqkem_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 KEM parameters and about authentication credentials for one or more groups and is formatted as follows.

• 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'.
• The second element 'pqkem_alg' is a CBOR integer or a text string that indicates the KEM algorithm used in the groups identified by the 'gname' values. For application profiles of that use the 'pqkem_info' parameter, it is REQUIRED to define specific values that 'pqkem_alg' can take, which are selected from the set of quantum-resistant KEM algorithms of the "COSE Algorithms" registry .
• The third element 'pqkem_parameters' is a CBOR array that indicates the parameters of the KEM used in the groups identified by the 'gname' values. Its content depends on the value of 'pqkem_alg'. For application profiles of that use the 'pqkem_info' parameter, it is REQUIRED to define the possible values and structure for the elements of 'pqkem_parameters'.
• The fourth element 'pqkem_key_parameters' is a CBOR array that indicates the parameters of the key used with the KEM in the groups identified by the 'gname' values. Its content depends on the value of 'pqkem_alg'. For application profiles of that use the 'pqkem_info' parameter, it is REQUIRED to define the possible values and structure for the elements of 'pqkem_key_parameters'.
• 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 , 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). For application profiles of that use the 'pqkem_info' parameter, it is REQUIRED to define specific values to use for 'cred_fmt', consistent with the acceptable formats of authentication credentials.

If 'pqkem_info' is included in the Token Transfer Request, the KDC SHOULD include the 'pqkem_info' parameter in the Token Transfer Response, as per the format defined above. Note that the field 'id' of each 'pqkem_info_entry' specifies the name or array of group names to which that 'pqkem_info_entry' applies. As an exception, the KDC MAY omit the 'pqkem_info' parameter in the Token Transfer Response even if 'pqkem_info' is included in the Token Transfer Request, in the case that none of the groups that the Client is authorized to join uses a KEM algorithm to derive shared secrets. The CDDL notation of the 'pqkem_info' parameter is given below. This format is consistent with every KEM algorithm currently registered by , i.e., with algorithms that have only the COSE key type as their COSE capability. of this document describes how the format of each 'pqkem_info_entry' can be generalized for possible future registered algorithms that have a different set of COSE capabilities.

Group Joining Building on , this section specifies additions to the joining process that are relevant when the joined group is a KEM-based group.

Send the Join Request In addition to what is defined in , the following applies at a joining node when sending a Join Request message for joining a KEM-based group. If the joining node requests to (re-)join the group not exclusively as a monitor, the Join Request message MAY include the following parameter:

• 'client_kem_pubkey': encoded as a CBOR byte string, whose value is a KEM public key newly generated by the joining node and whose CBOR label is registered in . Consistent with the KEM used as Pairwise Key Agreement Algorithm in the group, the joining node generates the specified KEM public key and the corresponding KEM private key. As associated with the group in question, the joining node stores the generated key pair, together with the SHA-256 hash of the KEM public key as the corresponding identifier.

Editor's note: once also covered the case of a KEM-based group that is a pairwise-only group, explain here that other (to-be-defined) resources at the Group Manager are used by the joining node in such case, so that the joining node remains able to prove possession of its own private key upon joining the group, through a MAC used as PoP evidence and encoded by the 'client_cred_verify' parameter of the Join Request.

Receive the Join Request In addition to what is defined in , the following applies at the Group Manager when receiving a Join Request message for joining a KEM-based group. If the joining node is going to join the group exclusively as a monitor, then the Group Manager silently ignores the 'client_kem_pubkey' parameter, if present. Otherwise, in the case that the 'client_kem_pubkey' parameter is present in the Join Request, the Group Manager retrieves the joining node's KEM public key specified therein. If the Group Manager is currently storing the maximum admitted number of KEM public keys for that joining node in the group, the Group Manager MUST reply with a 5.03 (Service Unavailable) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 13 ("Reached limit of KEM public keys"). If the KEM public key is not compatible with the KEM used as Pairwise Key Agreement Algorithm in the group, the Group Manager MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 14 ("KEM public key incompatible with the group configuration"). In the case that the Group Manager replies with a 4.00 (Bad Request) error response with Content-Format "application/ace-groupcomm+cbor", the format of the CBOR map conveyed in the response payload is updated as follows (OPT4), consistent with the fact that the group is a KEM-based group:

• Differently from the case considered in in which the group is not a KEM-based group, the CBOR map MUST NOT contain the parameters 'ecdh_info' and 'kdc_dh_creds'.
• The CBOR map MUST contain the 'pqkem_info' parameter, whose CBOR label is registered in . This parameter has the same format of 'pqkem_info_resp' defined in and includes a single element 'pqkem_info_entry', which pertains to the OSCORE group that the joining node has tried to join with the Join Request.

Editor's note: once also covered the case of a KEM-based group that is a pairwise-only group, explain here that other (to-be-defined) resources at the Group Manager are used by the joining node in such case, so that the joining node remains able to prove possession of its own private key upon joining the group, through a MAC used as PoP evidence and encoded by the 'client_cred_verify' parameter of the Join Request.

Send the Join Response If the processing of the Join Request is successful and the group targeted by the Join Request is a KEM-based group, the Group Manager proceeds as defined in , with the following modifications. In the case that the joining node has not taken exclusively the role of monitor, the Group Manager performs also the following actions. After having registered the joining node NODENAME as a member of the OSCORE group GROUPNAME as described in , the handler that processed the Join Request creates two additional resources associated with the joining node, unless those resources already exist (i.e., in the case of a group re-joining):

• /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys (see ). Upon creating the resource, its representation is set to the CBOR unsigned integer encoding the value 0.
• /ace-group/GROUPNAME/nodes/NODENAME/kem-ciphertexts (see ).

When the Group Manager sends the Join Response, the following applies:

• If the joining node has not taken exclusively the role of monitor, the Join Response MUST include the 'max_kem_pubkeys' parameter, which is registered in of this document. The parameter is encoded as a CBOR unsigned integer, and it specifies the maximum number of KEM public keys that the Group Manager stores as associated with the same Client within the group.
• The content of the 'key' parameter is updated as follows (REQ17), consistent with the fact that the group is a KEM-based group:
  • Differently from the case considered in in which the group is not a KEM-based group, the parameters 'ecdh_alg' and 'ecdh_params' MUST NOT be included.
  • The 'pqkem_alg' parameter MUST be included, specifying the KEM used as Pairwise Key Agreement Algorithm in the group for computing the shared secret to derive the pairwise keys for the pairwise mode. This parameter takes values from the "Value" column of the "COSE Algorithms" registry .
  • The 'pqkem_params' parameter MUST be included, specifying the parameters of the KEM used as Pairwise Key Agreement Algorithm. This parameter is a CBOR array, which includes the following two elements:
    • 'pqkem_alg_capab': a CBOR array, with the same format and value of the COSE capabilities array for the KEM algorithm indicated in 'pqkem_alg', as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry .
    • 'pqkem_key_type_capab': a CBOR array, with the same format and value of the COSE capabilities array for the COSE key type of the keys used with the KEM algorithm indicated in 'pqkem_alg', as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry .

The format of 'key' defined above is consistent with every KEM algorithm currently registered by , i.e., with algorithms that have only the COSE key type as their COSE capability. of this document describes how the format of the 'key' parameter can be generalized for possible future registered algorithms that have a different set of COSE capabilities. If the Join Request included the 'client_kem_pubkey' parameter and the joining node has not joined the group exclusively as a monitor, the Group Manager performs the following actions:

• The Group Manager stores the KEM public key specified in the 'client_kem_pubkey' parameter, as the latest KEM public key generated by the joining node and pertaining to the group. Furthermore, the Group Manager associates the KEM public key with the OSCORE Sender ID assigned to the joining node in the group. The assigned OSCORE Sender ID is specified by the 'group_senderId' parameter within the 'key' parameter of the Join Response (see ). The Group Manager MUST keep this association up-to-date over time, in the event that the joining node changes its OSCORE Sender ID in the group.
• The Group Manager updates the representation of the resource at /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys to reflect the number of currently stored KEM public keys generated by the group member NODENAME and pertaining to the group. That is, if such number is N upon receiving the Join Request, the updated resource representation is the CBOR unsigned integer encoding the value (N + 1).

Editor's note: once also covered the case of a KEM-based group that is a pairwise-only group, explain here that other (to-be-defined) resources at the Group Manager are used by the joining node in such case. That allows the joining node to compute and include in the Join Request a KEM ciphertext. Building on that, the Group Manager remains able to prove possession of its own private key, through a MAC used as PoP evidence and encoded by the 'kdc_cred_verify' parameter of the Join Response.

Receive the Join Response Upon receiving a Join Response resulting from having joined a KEM-based group, the joining node proceeds as defined in , with the following modifications.

• If the group is a pairwise-only group, the PoP evidence is a MAC. The joining node recomputes the MAC through the same process that is taken by the Group Manager when computing the value of the 'kdc_cred_verify' parameter (see ), with the difference that ... TBD Editor's note: once also covered the case of a KEM-based group that is a pairwise-only group, explain here that other (to-be-defined) resources at the Group Manager are used by the joining node in such case. That allows the joining node to compute and include in the Join Request a KEM ciphertext. Building on that, the Group Manager remains able to prove possession of its own private key, through a MAC used as PoP evidence and encoded by the 'kdc_cred_verify' parameter of the Join Response.
• When processing the 'key' parameter of the Join Response, the following applies:
  • If both the parameters 'ecdh_alg' and 'pqkem_alg' are absent, the parameter Pairwise Key Agreement Algorithm in the Common Context of the Group OSCORE Security Context is not set.
• The joining node MUST NOT use the pairwise mode of Group OSCORE to process messages in the group, if the 'key' parameter of the Join Response does not include both the parameters 'alg' and 'ecdh_alg' or both the parameters 'alg' and 'pqkem_alg'.

Retrieve Updated Keying Material Building on , the following two subsections define additions to the operations by which a member of a KEM-based group retrieves updated security parameters and group keying material from the Group Manager.

Get Group Keying Material This section builds on and updates what is defined in . After successfully processing a Key Distribution Request as a GET request to the endpoint /ace-group/GROUPNAME, the Group Manager composes the Key Distribution Response as defined in , with the following modifications.

• If the requesting group member does not have exclusively the role of monitor, the Key Distribution Response MUST include the 'max_kem_pubkeys' parameter, whose encoding and semantics is the same as in the Join Response (see of the present document).
• The 'key' parameter is formatted as defined in of the present document, with the difference that it does not include the 'group_SenderId' parameter.

Get Group Keying Material and OSCORE Sender ID This section builds on and updates what is defined in . After successfully processing a Key Distribution Request as a GET request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME, the Group Manager composes the Key Distribution Response as defined in , with the following modifications.

• If the requesting group member does not have exclusively the role of monitor, the Key Distribution Response MUST include the 'max_kem_pubkeys' parameter, whose encoding and semantics is the same as in the Join Response (see of the present document).
• The 'key' parameter is formatted as defined in of the present document. If the requesting group member has exclusively the role of monitor, then the 'key' parameter does not include the 'group_SenderId' parameter. Note that, in any other case, the current Sender ID of the group member is not specified as a separate parameter, but instead by the 'group_SenderId' parameter within the 'key' parameter.

Retrieve Signature Verification Data Building on , the following defines additions to the operations by which a signature verifier retrieves from the Group Manager data required to verify signatures of messages protected with the group mode of Group OSCORE and sent to a group. After successfully processing a Signature Verification Data Request as a GET request to the endpoint /ace-group/GROUPNAME/verif-data, the Group Manager composes the Signature Verification Data Response as defined in , with the following modifications.

• Of the parameters present in the Join Response message (see of the present document), only the parameters 'gkty', 'key', 'num', 'exp', 'exi', and 'ace_groupcomm_profile' are present in the Signature Verification Data Response. The 'key' parameter includes only the following data:
  • The parameters 'hkdf', 'contextId', 'cred_fmt', 'gp_enc_alg', 'sign_alg', and 'sign_params'. These parameters MUST be present.
  • The 'alg' parameter. This parameter MUST NOT be present if the group is a signature-only group. Otherwise, it MUST be present.
  • The 'ecdh_alg' parameter. This parameter MUST NOT be present if the group is a signature-only group or is a KEM-based group. Otherwise, it MUST be present.
  • The 'pqkem_alg' parameter. This parameter MUST NOT be present if the group is not a KEM-based group. Otherwise, it MUST be present.

Interface at the Group Manager In addition to what is specified in , this document extends the interface at the Group Manager by defining the new sub-resources specified in , , , and . The Group Manager hosts those resources for each KEM-group that it is responsible for. In addition to what is defined in , each handler of each new resource performs the following verifications.

• The handler verifies that the requesting Client is a current member of the group. If the verification fails, the handler replies with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . 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").
• The handler verifies that the requesting Client has not exclusively the role of monitor in the group. If the verification fails, the handler replies with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . 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").
• The handler verifies that the OSCORE group identified by GROUPNAME is currently active (see ). If the verification fails, the handler replies with a 5.03 (Service Unavailable) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 9 ("Group currently not active"). The method to set the current group status is out of the scope of this document, and it is defined for the administrator interface of the Group Manager specified in .

provides a summary of the CoAP methods that are permitted to use for accessing the new resources at the Group Manager, for nodes with different roles in the group (REQ11).

/ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys The Group Manager creates this resource after successfully processing a Join Request, if and only if both the following conditions hold:

• The OSCORE group GROUPNAME is a KEM-group.
• The resource does not already exist and, through the processed Join Request, the node NODENAME has joined the group GROUPNAME not exclusively as a monitor. This takes into account the case where the node re-joins the group possibly changing roles (i.e., sometimes exclusively as a monitor, while sometimes not), which does not result in re-creating the resource and re-initializing its representation.

The resource representation is a CBOR unsigned integer, which encodes the number of KEM public keys that are generated by the node NODENAME as a member of the group GROUPNAME and are currently stored at the Group Manager as intended to other members of the group. When creating the resource, its representation is set to the CBOR unsigned integer encoding the value 0 (see ). This resource implements the POST, GET, and PUT handlers. Each handler of this resource verifies that the node name of the requesting Client is equal to NODENAME used in the url-path. If the verification fails, the handler replies with a 4.03 (Forbidden) error response.

POST Handler The handler expects a POST request whose payload is a CBOR map, which includes a KEM public key generated by the requesting Client and intended to any and exactly one other member of the group (see ). If all verifications succeed, the handler replies with a 2.04 (Changed) response specifying the updated resource representation, i.e., the updated number of KEM public keys that the Group Manager currently stores as generated by the node NODENAME and pertaining to the group GROUPNAME. The payload of the response is formatted as defined in .

GET Handler The handler expects a GET request. If all verifications succeed, the handler replies with a 2.05 (Content) response specifying the current resource representation, i.e., the number of KEM public keys that the Group Manager currently stores as generated by the node NODENAME and pertaining to the group GROUPNAME. The payload of the response is formatted as defined in . The Group Manager SHOULD make the resource at /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys also observable , thus making it possible for the node NODENAME to subscribe for updates about the resource representation, instead of limiting the node to only rely on polling.

PUT Handler The handler expects a PUT request, whose payload is the CBOR unsigned integer encoding the value 0 (see ). If all verifications succeed, the handler replies with a 2.04 (Changed) response specifying the updated resource representation, i.e., the updated number (0) of KEM public keys that the Group Manager currently stores as generated by the node NODENAME and pertaining to the group GROUPNAME. The payload of the response is formatted as defined in .

/ace-group/GROUPNAME/kem-pub-keys The Group Manager creates this resource upon establishing the OSCORE group GROUPNAME, if and only if the group is a KEM-group. This resource implements the POST handler.

POST Handler The handler expects a POST request whose payload is a CBOR map, specifying a set of OSCORE Sender IDs associated with members of the group (see ). If all verifications succeed, the handler replies with a 2.04 (Changed) response specifying a set of KEM public keys, each of which generated by a member of the group indicated in the request. The payload of the response is formatted as defined in .

/ace-group/GROUPNAME/nodes/NODENAME/kem-ciphertexts The Group Manager creates this resource after successfully processing a Join Request, if and only if both the following conditions hold:

• The OSCORE group GROUPNAME is a KEM-group.
• The resource does not already exist and, through the processed Join Request, the node NODENAME has joined the group GROUPNAME not exclusively as a monitor. This takes into account the case where the node re-joins the group possibly changing roles (i.e., sometimes exclusively as a monitor, while sometimes not), which does not result in re-creating the resource.

This resource implements the POST handler.

POST Handler The handler expects a POST request whose payload is a CBOR map, specifying a KEM ciphertext computed by the requesting Client for another member of the group, together with related information associated with that group member (see ). The handler verifies that the node name of the requesting Client is equal to NODENAME used in the url-path. If the verification fails, the handler replies with a 4.03 (Forbidden) error response. If all verifications succeed, the handler replies with a 2.04 (Changed) response that has no payload.

/ace-group/GROUPNAME/kem-ciphertexts The Group Manager creates this resource upon establishing the OSCORE group GROUPNAME, if and only if the group is a KEM-group. This resource implements the POST handler.

POST The handler expects a POST request whose payload is a CBOR map, specifying the OSCORE Sender ID associated with a specific member of the group that computed a KEM ciphertext intended to the requesting Client (see ). If all verifications succeed, the handler replies with a 2.04 (Changed) response, specifying a KEM ciphertext intended to the requesting Client, together with related information associated with the requesting Client. The payload of the response is formatted as defined in .

Permitted Methods below extends Table 2 of and summarizes the CoAP methods that are permitted for accessing different resources at the Group Manager, for (non-)members of a group with group name GROUPNAME, and considering different roles. The last two rows of the table apply to a node with node name NODENAME. The table uses the following abbreviations.

• G = CoAP method GET
• P = CoAP method POST
• Pu = CoAP method PUT
• Type1 = Member as a Requester and/or Responder
• Type2 = Member as a Monitor
• Type3 = Non-member (authorized to be signature verifier)
• Type4 = Non-member (not authorized to be signature verifier)

Permitted CoAP Methods on the Group Manager Resources

Resource	Type1	Type2	Type3	Type4
/ace-group/GROUPNAME/kem-pub-keys	P	-	-	-
/ace-group/GROUPNAME/kem-ciphertexts	P	-	-	-
/ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys	G P Pu	-	-	-
/ace-group/GROUPNAME/nodes/NODENAME/kem-ciphertexts	P	-	-	-

Operations Supported by Clients Building on what is defined in and in , and with reference to the additional resources at the Group Manager defined in of the present document, a Client with node name NODENAME that supports the pairwise mode of Group OSCORE and joins a KEM-based group GROUPNAME not exclusively as a monitor is expected to support all the operations available at such additional resources and the corresponding interactions with the Group Manager (REQ12), i.e.:

• POST request to /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys, in order to upload at the Group Manager an own KEM public key as intended to any and exactly one other member of the group GROUPNAME.
• GET request to /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys, in order to retrieve the number of own KEM public keys that are currently stored at the Group Manager as intended to other members of the group GROUPNAME.
• PUT request to /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys, in order to discard all its own KEM public keys stored at the Group Manager as intended to other members of the group GROUPNAME.
• POST request to /ace-group/GROUPNAME/kem-pub-keys, in order to retrieve from the Group Manager a set of KEM public keys, each of which generated by another member of the group GROUPNAME.
• POST request to /ace-group/GROUPNAME/nodes/NODENAME/kem-ciphertexts, in order to upload at the Group Manager a KEM ciphertext computed by the requesting Client for another member of the group GROUPNAME, together with related information associated with that group member.
• POST request to /ace-group/GROUPNAME/kem-ciphertexts, in order to retrieve from the Group Manager a KEM ciphertext intended to the requesting Client, together with related information associated with the requesting Client.

Additional Interactions with the Group Manager This section defines the possible interactions with the Group Manager, in addition to those specified in . These additional interactions are relevant only for members of a KEM-based group that support the pairwise mode of Group OSCORE and have not exclusively the role of monitor in the group.

Upload a KEM Public Key A group member can upload at the Group Manager an own KEM public key, intended to any and exactly one other member of the group. To this end, the group member sends a KEM Public Key Upload Request to the Group Manager. That is, the group member sends a CoAP POST request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys at the Group Manager defined in , where GROUPNAME is the name of the OSCORE group and NODENAME is the node name of the group member. The request MUST have Content-Format "application/ace-groupcomm+cbor". The payload of the request is formatted as a CBOR map, which MUST contain the following field with the value specified below:

• 'client_kem_pubkey': encoded as a CBOR byte string, whose value is the binary representation of a KEM public key newly generated by the requesting Client.

If the Group Manager is currently storing the maximum admitted number of KEM public keys for that joining node in the group, the Group Manager MUST reply with a 5.03 (Service Unavailable) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 13 ("Reached limit of KEM public keys"). If the KEM public key is not compatible with the KEM used as Pairwise Key Agreement Algorithm in the group, the Group Manager MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 14 ("KEM public key incompatible with the group configuration"). If all verifications succeed, the Group Manager performs the following actions:

• The Group Manager stores the KEM public key specified in the 'client_kem_pubkey' parameter, as the latest KEM public key generated by the requesting Client and pertaining to the group. Furthermore, the Group Manager associates the KEM public key with the OSCORE Sender ID of the requesting Client in the group. The Group Manager MUST keep this association up-to-date over time, in the event that the requesting Client changes its OSCORE Sender ID in the group.
• The Group Manager updates the resource representation to reflect the number of currently stored KEM public keys generated by the requesting Client and pertaining to the group. That is, if such number is N upon receiving the KEM Public Key Upload Request, the updated resource representation is the CBOR unsigned integer encoding the value (N + 1).

Then, the Group Manager replies with a 2.04 (Changed) KEM Public Key Upload Response, which MUST have Content-Format "application/cbor". The payload of the response specifies the latest, just updated resource representation, i.e., the CBOR unsigned integer encoding the value (N + 1). After receiving the KEM Public Key Upload Response, the group member stores the KEM public key uploaded at the Group Manager, the corresponding KEM private key, and the SHA-256 hash of the KEM public key as the corresponding identifier. gives an overview of the exchange described above, while shows an example of KEM Public Key Upload Request-Response.

Message Flow of KEM Public Key Upload Request-Response | | POST /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys | | | |<------- KEM Public Key Upload Response: 2.04 (Changed) -------| | | ]]>

Example of KEM Public Key Upload Request-Response

Retrieve Number of Available Own KEM Public Keys A group member can retrieve from the Group Manager the number of own KEM public keys that the Group Manager currently stores as pertaining to the group. To this end, the group member sends a KEM Public Key Number Request to the Group Manager. That is, the group member sends a CoAP GET request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys at the Group Manager defined in , where GROUPNAME is the name of the OSCORE group and NODENAME is the node name of the group member. The 2.05 (Content) KEM Public Key Number Response MUST have Content-Format "application/cbor". The payload of the response specifies the current resource representation, i.e., it is a CBOR unsigned integer encoding the number of KEM public keys that the Group Manager currently stores as generated by the node NODENAME and pertaining to the group GROUPNAME. gives an overview of the exchange described above, while shows an example of KEM Public Key Number Request-Response.

Message Flow of KEM Public Key Number Request-Response | | GET /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys | | | |<------- KEM Public Key Number Response: 2.05 (Content) -------| | | ]]>

Example of KEM Public Key Number Request-Response

Discard Own KEM Public Keys A group member can request the Group Manager to delete from its local storage all the KEM public keys generated by the group member and pertaining to the group. To this end, the group member sends a KEM Public Key Discard Request to the Group Manager. That is, the group member sends a CoAP PUT request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys at the Group Manager defined in , where GROUPNAME is the name of the OSCORE group and NODENAME is the node name of the group member. The request MUST have Content-Format "application/cbor". The payload of the request is the CBOR unsigned integer encoding the value 0. If the Group Manager receives a KEM Public Key Discard Request whose payload is different from the CBOR unsigned integer encoding the value 0, the Group Manager MUST reply with a 4.00 (Bad Request) error response. If all verifications succeed, the Group Manager performs the following actions. First, the Group Manager deletes from its local storage all the KEM public keys generated by the node NODENAME and pertaining to the group GROUPNAME. Then, the Group Manager updates the resource representation to be the CBOR unsigned integer encoding the value 0. Finally, the Group Manager replies with a 2.04 (Changed) KEM Public Key Discard Response, which MUST have Content-Format "application/cbor". The payload of the response specifies the latest, just updated resource representation, i.e., the CBOR unsigned integer encoding the value 0. After receiving the KEM Public Key Discard Response, the group member deletes from its local storage all its own KEM public keys that it uploaded at the Group Manager as pertaining to the group GROUPNAME, as well as the corresponding KEM private keys and SHA-256 hashes of the KEM public keys as the corresponding identifiers. gives an overview of the exchange described above, while shows an example of KEM Public Key Discard Request-Response.

Message Flow of KEM Public Key Discard Request-Response | | PUT /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys | | | |<------ KEM Public Key Discard Response: 2.04 (Changed) -------| | | ]]>

Example of KEM Public Key Discard Request-Response

Retrieve KEM Public Keys of Group Members A group member can retrieve from the Group Manager a KEM public key generated by another group member. To this end, the group member sends a KEM Public Key Retrieval Request to the Group Manager. That is, the group member sends a CoAP POST request to the endpoint /ace-group/GROUPNAME/kem-pub-keys at the Group Manager defined in , where GROUPNAME is the name of the OSCORE group. The request MUST have Content-Format "application/ace-groupcomm+cbor". The payload of the request is formatted as a CBOR map, which MUST contain the following field with the value specified below:

• 'peer_identifiers': encoded as a CBOR array. Each element of the array is a CBOR byte string, whose value is the OSCORE Sender ID of a member of the group GROUPNAME. The array MUST NOT be empty, MUST NOT include an element that specifies the OSCORE Sender ID of the requesting Client, and MUST NOT include multiple elements that specify the same OSCORE Sender ID.

When receiving a KEM Public Key Retrieval Request, the Group Manager MUST reply with a 4.00 (Bad Request) response if the CBOR array REQ_ARRAY conveyed as request payload is empty, or any of its elements specifies the OSCORE Sender ID of the requesting Client, or it includes multiple elements that specify the same OSCORE Sender ID. Otherwise, if all verifications succeed, the Group Manager performs the following actions.

• The Group Manager composes a CBOR array RESP_ARRAY of N elements, where N is the number of elements of REQ_ARRAY. Each element of RESP_ARRAY is provisionally set to the CBOR simple value null (0xf6).
• The Group Manager sequentially considers the elements of REQ_ARRAY. When considering the i-th element of REQ_ARRAY, the Group Manager checks whether it is currently storing any KEM public key that was uploaded by the group member NODENAME of the group GROUPNAME identified by the OSCORE Sender ID specified by the array element under consideration. If the Group Manager is not storing any such KEM public key, the Group Manager moves on to consider the next element of REQ_ARRAY (if any). Otherwise, the Group Manager sets the i-th element of RESP_ARRAY as a CBOR byte string, whose value is the binary representation of the oldest KEM public key stored for the identified group member. Then, the Group Manager deletes that oldest KEM public key from its local storage, and it updates the representation of the resource at /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys to reflect the number of currently stored KEM public keys generated by the group member NODENAME and pertaining to the group. That is, if such number is N upon receiving the KEM Public Key Retrieval Request, the updated resource representation is the CBOR unsigned integer encoding the value (N - 1). After that, the Group Manager moves on to consider the next element of REQ_ARRAY (if any).

Then, the Group Manager replies with a 2.04 (Changed) KEM Public Key Retrieval Response, which MUST have Content-Format "application/ace-groupcomm+cbor". The payload of the response is formatted as a CBOR map, which MUST contain the following field with the value specified below:

• 'kem_pubkeys': specifying the CBOR array RESP_ARRAY.

gives an overview of the exchange described above, while shows an example of KEM Public Key Retrieval Request-Response.

Message Flow of KEM Public Key Retrieval Request-Response | | POST /ace-group/GROUPNAME/kem-pub-keys | | | |<----- KEM Public Key Retrieval Response: 2.04 (Changed) ------| | | ]]>

Example of KEM Public Key Retrieval Request-Response

Upload a KEM Ciphertext A group member P can upload at the Group Manager a KEM ciphertext intended to another group member Q, with such KEM ciphertext computed by P using a KEM public key of Q. To this end, the group member sends a KEM Ciphertext Upload Request to the Group Manager. That is, the group member P sends a CoAP POST request to the endpoint /ace-group/GROUPNAME/nodes/NODENAME/kem-ciphertexts at the Group Manager defined in , where GROUPNAME is the name of the OSCORE group and NODENAME is the node name of the group member P. The request MUST have Content-Format "application/ace-groupcomm+cbor". The payload of the request is formatted as a CBOR map, which MUST contain the following fields with the value specified below:

• 'kem_ciphertext': encoded as a CBOR byte string, whose value is the KEM ciphertext computed by P and intended to Q. The KEM ciphertext encapsulates a shared secret computed by P and intended to Q. Consistent with what is specified in , P uses the shared secret to derive its Pairwise Sender Key associated with Q. That is, such Pairwise Sender Key is used by P for processing outgoing messages protected with the pairwise mode of Group OSCORE and intended to Q.
• 'kem_pubkey_hash': encoded as a CBOR byte string, whose value is the SHA-256 hash of Q's KEM public key that P used to compute the ciphertext specified in the 'kem_ciphertext' parameter.
• 'group_senderId': encoded as a CBOR byte string, whose value is the OSCORE Sender ID of Q in the group.

When receiving a KEM Ciphertext Upload Request, the Group Manager MUST reply with a 4.00 (Bad Request) response if any of the following conditions holds:

• The 'group_senderId' parameter specifies an OSCORE Sender ID that is not associated with any current member of the group.
• The 'group_senderId' parameter specifies the OSCORE Sender ID of the requesting Client. The Group Manager ultimately identifies the requesting Client (and thereby determines its Sender ID in the group) by means of the secure communication association that it has with the requesting Client.

If the KEM ciphertext specified in the 'kem_ciphertext' parameter of the KEM Ciphertext Upload Request is not compatible with the KEM used as Pairwise Key Agreement Algorithm in the group, the Group Manager MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to "application/concise-problem-details+cbor" and is formatted as defined in . Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 15 ("KEM ciphertext incompatible with the group configuration"). Otherwise, if all verifications succeed, the Group Manager stores a tuple composed of the following elements, as pertaining to the group GROUPNAME:

• The KEM ciphertext specified in the 'kem_ciphertext' parameter of the KEM Ciphertext Upload Request.
• The hash of the KEM public key of Q specified in the 'kem_pubkey_hash' parameter of the KEM Ciphertext Upload Request.
• The OSCORE Sender ID of Q in the group specified in the 'group_senderId' parameter of the KEM Ciphertext Upload Request, as identifying the intended consumer of the KEM ciphertext.
• The OSCORE Sender ID of P in the group as identifying the producer of the KEM ciphertext, which the Group Manager determines as the current Sender ID of the requesting Client in the group.

The Group Manager MUST keep up-to-date the stored tuple over time, in the event that any of the two group members P and Q changes its OSCORE Sender ID in the group. If a new KEM ciphertext is uploaded at the Group Manager together with the same consumer Sender ID and producer Sender ID for which another KEM ciphertext is already stored for the group GROUPNAME, then the latest uploaded KEM ciphertext and accompanying hash of the KEM public key MUST overwrite the current ones in the tuple stored for those two Sender IDs. Finally, the Group Manager replies with a 2.04 (Changed) KEM Ciphertext Upload Response, which has no payload. gives an overview of the exchange described above, while shows an example of KEM Ciphertext Upload Request-Response.

Message Flow of KEM Ciphertext Upload Request-Response | | POST /ace-group/GROUPNAME/nodes/NODENAME/kem-ciphertexts | | | |<------- KEM Ciphertext Upload Response: 2.04 (Changed) -------| | | ]]>

Example of KEM Ciphertext Upload Request-Response

Retrieve a KEM Ciphertext A group member P can retrieve from the Group Manager the KEM ciphertext that a specific other group member Q computed and uploaded at the Group Manager as intended to P. To this end, the group member P sends a KEM Ciphertext Retrieval Request to the Group Manager. That is, the group member P sends a CoAP POST request to the endpoint /ace-group/GROUPNAME/kem-ciphertexts at the Group Manager defined in , where GROUPNAME is the name of the OSCORE group. The request MUST have Content-Format "application/ace-groupcomm+cbor". The payload of the request is formatted as a CBOR map, which MUST contain the following field with the value specified below:

• 'group_senderId': encoded as a CBOR byte string, whose value is the OSCORE Sender ID of Q in the group.

When receiving a KEM Ciphertext Retrieval Request, the Group Manager MUST reply with a 4.00 (Bad Request) response if any of the following conditions holds:

• The 'group_senderId' parameter specifies an OSCORE Sender ID that is not associated with any current member of the group.
• The 'group_senderId' parameter specifies the OSCORE Sender ID of the requesting Client. The Group Manager ultimately identifies the requesting Client (and thereby determines its Sender ID in the group) by means of the secure communication association that it has with the requesting Client.

Otherwise, if all verifications succeed, the Group Manager checks whether it is storing a tuple pertaining to the group GROUPNAME such that both the following conditions hold:

• The OSCORE Sender ID of the producer of the KEM ciphertext is the Sender ID specified in the 'group_senderId' parameter of the KEM Ciphertext Retrieval Request.
• The OSCORE Sender ID of the intended consumer of the KEM ciphertext is the Sender ID of the requesting Client in the group.

If no such tuple is found, the Group Manager replies with a 2.04 (Changed) KEM Ciphertext Retrieval Response that has no payload. Instead, if such a tuple is found, the Group Manager retrieves from the tuple the KEM ciphertext CT as well as the hash HASH of the KEM public key used to compute CT. Then, the Group Manager deletes the tuple from its local storage. After that, the Group Manager replies with a 2.04 (Changed) KEM Ciphertext Retrieval Response, which 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 value specified below:

• 'kem_ciphertext': encoded as a CBOR byte string, whose value is the KEM ciphertext CT retrieved above.
• 'kem_pubkey_hash': encoded as a CBOR byte string, whose value is the hash HASH retrieved above.

When receiving a KEM Ciphertext Retrieval Response conveying a payload, the requesting Client P performs the following steps:

• It retrieves the hash specified in the 'kem_pubkey_hash' parameter of the KEM Ciphertext Retrieval Response, and it uses the hash to retrieve the corresponding pair (KEM public key, KEM private key) from its local storage. That is, P retrieves the pair such that the hash from the KEM Ciphertext Retrieval Response is equal to the hash of the KEM public key within the pair.
• If such a pair is found, P uses the KEM private key within the pair to decrypt the KEM ciphertext specified in the 'kem_ciphertext' parameter of the KEM Ciphertext Retrieval Response, thereby retrieving the shared secret computed by the other group member Q. Consistent with what is specified in , P uses the shared secret to derive its Pairwise Recipient Key associated with Q. That is, such Pairwise Recipient Key is used by P for processing incoming messages from Q that are protected with the pairwise mode of Group OSCORE and intended to P. Finally, P deletes from its local storage the found pair (KEM public key, KEM private key) as well as the hash of the KEM public key as the corresponding identifier.

gives an overview of the exchange described above, while shows an example of KEM Ciphertext Retrieval Request-Response.

Message Flow of KEM Ciphertext Retrieval Request-Response | | POST /ace-group/GROUPNAME/kem-ciphertexts | | | |<----- KEM Ciphertext Retrieval Response: 2.04 (Changed) ------| | | ]]>

Example of KEM Ciphertext Retrieval Request-Response

Removal of a Group Member In addition to what is defined in , the Group Manager performs the following actions when removing a node NODENAME from a KEM-based group GROUPNAME.

• The Group Manager deletes from its local storage the leaving node's KEM public keys that the leaving node uploaded at the Group Manager, as intended to other members of the group.
• The Group Manager deletes from its local storage the KEM ciphertexts that the leaving node uploaded as intended to other members of the group, as well as the KEM ciphertexts that other members of the group uploaded as intended to the leaving node. The Group Manager also deletes the stored tuples pertaining to the deleted ciphertexts above, as including:
  • The hash of the KEM public key used to compute the pertaining KEM ciphertext.
  • The OSCORE Sender IDs identifying the producer and the intended consumer of the pertaining KEM ciphertext.

The resources at /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys and at /ace-group/GROUPNAME/nodes/NODENAME/kem-ciphertexts are deleted when deleting their parent resource at /ace-group/GROUPNAME/nodes/NODENAME (see ).

ACE Groupcomm Parameters In addition to what is defined in and , this document defines additional parameters used during the second part of the message exchange with the Group Manager, i.e., after the exchange of Token Transfer Request and Response (see ). The table below summarizes them and specifies the CBOR key to use instead of the full descriptive name. Note that the media type "application/ace-groupcomm+cbor" MUST be used when these parameters are transported in the respective message fields. ACE Groupcomm Parameters

Name	CBOR Key	CBOR Type	Reference
max_kem_pubkeys	22	uint	[RFC-XXXX]
client_kem_pubkey	35	bstr	[RFC-XXXX]
kem_pubkeys	36	array	[RFC-XXXX]
kem_ciphertext	37	bstr	[RFC-XXXX]
kem_pubkey_hash	38	bstr	[RFC-XXXX]
pqkem_info	39	array	[RFC-XXXX]

Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph. The Group Manager is expected to support all the parameters above. Instead, a Client is required to support the parameters above as specified below (REQ29):

• The following parameters MUST be supported by a Client that intends to join a KEM-based group and to use the pairwise mode of Group OSCORE to process messages in the group:
  • max_kem_pubkeys.
  • client_kem_pubkey.
  • kem_pubkeys.
  • kem_ciphertext.
  • kem_pubkey_hash.
• 'pqkem_info' MUST be supported by a Client that intends to join a KEM-based group.

ACE Groupcomm Error Identifiers In addition to what is defined in and , this document defines new values that the Group Manager can use as error identifiers (OPT5). 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 ). ACE Groupcomm Error Identifiers

Value	Description
13	Reached limit of KEM public keys
14	KEM public key incompatible with the group configuration
15	KEM ciphertext incompatible with the group configuration

If the Client supports the problem-details format and the Custom Problem Detail entry 'ace-groupcomm-error' defined in , and it is able to understand the error specified in the 'error-id' field therein, then the Client may 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.

• In the case of error 13, the Client should refrain from uploading at the Group Manager an own KEM public key intended to group members of the targeted group, until a pre-defined amount of time has elapsed or the Group Manager indicates that the number of the Client's currently stored KEM public keys is below the limit. In a group with group name GROUPNAME, a Client with name NODENAME can obtain that indication by sending a GET request to /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys (see and ). If the resource is observable , the Client can additionally subscribe for updates about the resource representation, instead of only relying on polling.
• In the case of error 14, the Client has to self-generate a different pair of KEM public key and KEM private key, as aligned to the Pairwise Key Agreement Algorithm and parameters used in the targeted group. After that, the Client should provide the Group Manager with the new KEM public key.
• In the case of error 15, the Client should retrieve from the Group Manager a different KEM public key associated with the other group member for which the KEM ciphertext was computed. After that, the Client computes a KEM ciphertext using the latest retrieved KEM public key and uploads the KEM ciphertext at the Group Manager.

Default Values for Group Configuration Parameters Building on what is defined in , this section defines additional default values that the Group Manager refers to for the configuration parameters of a KEM-based group, in the case that values for those parameters are not explicitly specified when creating and configuring the group (for example, by means of the admin interface defined in ). These default values are RECOMMENDED to use for the configuration parameters. Exceptionally, the Group Manager MAY choose different default values instead of those recommended in this section. A possible reason is to ensure that each of those are consistent with what the Group Manager supports, e.g., in terms of the Pairwise Key Agreement Algorithm used in the OSCORE group. This ensures that the Group Manager is able to perform the operations defined in this document. For example, if the KEM-based group is specifically a pairwise-only group, this ensures that the Group Manager is able to achieve proof of possession of a joining node's private key, as well as to provide a joining node with its own authentication credential and the associated proof-of-possession evidence. Editor's note: in the document body, explicitly cover the case where the KEM-based group is specifically a pairwise-only group. The following builds on the "COSE Algorithms" registry and the "COSE Key Types" registry .

• For 'max_kem_pubkeys', the Group Manager SHOULD consider the value 200 as the maximum number of KEM public keys that the Group Manager stores at any given time as associated with the same Client within the same group.
• For the Pairwise Key Agreement Algorithm 'pqkem_alg' used to compute quantum secure shared secrets in the group, the Group Manager SHOULD use ML-KEM-512 (COSE algorithm encoding: TBD) registered by , which indicates the ML-KEM-512 parameter set of the standard ML-KEM . In such case, the parameter 'pqkem_params' (see ) specifies the array [[AKP], [AKP]]. This indicates to use the COSE key type AKP registered by .

Editor's note: at the moment, the configuration parameters above are not reflected by an admin interface such as that defined in . That interface can also be updated, in order for an Administrator to (re-)configure an OSCORE group as per those parameters too.

Security Considerations The security considerations from , , and hold for this document too. The security considerations for the specific KEM used as Pairwise Key Agreement Algorithm in the OSCORE group also apply. Editor's note: add further security considerations.

IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

OAuth Parameters IANA is asked to register the following entry in the "OAuth Parameters" registry within the "OAuth Parameters" registry group, following the procedure specified in .

• Name: pqkem_info
• Parameter Usage Location: client-rs request, rs-client response
• Change Controller: IETF
• Reference: [RFC-XXXX]

OAuth Parameters CBOR Mappings IANA is asked to register the following entry in the "OAuth Parameters CBOR Mappings" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group, following the procedure specified in .

• Name: pqkem_info
• CBOR Key: TBD (value between 1 and 255)
• Value Type: Null or array
• Reference: [RFC-XXXX]
• Original Specification: [RFC-XXXX]

ACE Groupcomm Parameters IANA is asked to register the following entries to the "ACE Groupcomm Parameters" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.

• Name: max_kem_pubkeys
• CBOR Key: 22 (suggested)
• CBOR Type: unsigned integer
• Reference: [RFC-XXXX]

• Name: client_kem_pubkey
• CBOR Key: 35 (suggested)
• CBOR Type: bstr
• Reference: [RFC-XXXX]

• Name: kem_pubkeys
• CBOR Key: 36 (suggested)
• CBOR Type: array
• Reference: [RFC-XXXX]

• Name: kem_ciphertext
• CBOR Key: 37 (suggested)
• CBOR Type: bstr
• Reference: [RFC-XXXX]

• Name: kem_pubkey_hash
• CBOR Key: 38 (suggested)
• CBOR Type: bstr
• Reference: [RFC-XXXX]

• Name: pqkem_info
• CBOR Key: 39 (suggested)
• CBOR Type: array
• Reference: [RFC-XXXX]

OSCORE Security Context Parameters IANA is asked to register the following entries in the "OSCORE Security Context Parameters" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.

• Name: pqkem_alg
• CBOR Label: 14 (suggested)
• CBOR Type: text string / integer
• Registry: Values
• Description: OSCORE Pairwise Key Agreement Algorithm Value, identifying a Key Encapsulation Mechanism (KEM)
• Reference: [RFC-XXXX]

• Name: pqkem_params
• CBOR Label: 15 (suggested)
• CBOR Type: array
• Registry: Capabilities, Capabilities
• Description: OSCORE Pairwise Key Agreement Algorithm Parameters, when that algorithm is a Key Encapsulation Mechanism (KEM)
• Reference: [RFC-XXXX]

ACE Groupcomm Errors IANA is asked to register the following entries in the "ACE Groupcomm Errors" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.

• Value: 13 (suggested)
• Description: Reached limit of KEM public keys.
• Reference: [RFC-XXXX]

• Value: 14 (suggested)
• Description: KEM public key incompatible with the group configuration.
• Reference: [RFC-XXXX]

• Value: 15 (suggested)
• Description: KEM ciphertext incompatible with the group configuration.
• Reference: [RFC-XXXX]

References Normative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807. 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. This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. RISE AB Ericsson AB This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. Nokia Nokia University of the Bundeswehr Munich This document describes conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) with CBOR Object Signing and Encryption (COSE). RISE AB Group communication for the Constrained Application Protocol (CoAP) can be protected end-to-end by using the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). The pairwise mode of Group OSCORE provides authenticated encryption of CoAP messages, by means of symmetric keys that two group members establish only among themselves to achieve pairwise secure communication. This document defines the use of quantum-resistant Key Encapsulation Mechanisms (KEMs) as Pairwise Key Agreement Algorithm of Group OSCORE, enabling post-quantum secure derivation of the symmetric keys used in the pairwise mode. The Group Manager facilitates the exchange of KEM public keys and KEM ciphertexts among group members. NIST IANA IANA IANA IANA IANA IANA IANA IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References RISE AB RISE AB Ericsson AB Group communication for the Constrained Application Protocol (CoAP) can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible for handling the joining of new group members, as well as for managing and distributing the group keying material. This document defines a RESTful admin interface at the Group Manager that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The Authentication and Authorization for Constrained Environments (ACE) framework is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof of possession, and server authentication. RISE AB Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document defines how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group can be used to protect communications in multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments.

Profile Requirements This section updates how the requirements listed in are additionally fulfilled. The following includes only the requirements for which the present document provides an update.

Mandatory-to-Address Requirements The mandatory-to-address requirements initially specified in are updated as below.

• REQ11: Define what specific actions (e.g., CoAP methods) are allowed on each resource 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; and the roles that the Client has as a current group member: see and of the present document.
• REQ12: Categorize possible newly defined operations for Clients into primary operations expected to be minimally supported and secondary operations, and provide accompanying considerations: see and of the present document.
• REQ14: TBD Editor's note: Approaches used to compute and verify the PoP evidence to include in the 'client_cred_verify' parameter. Reference from and , once also covered the case of a KEM-based group that is a pairwise-only group, with the joining node still able to prove possession of its own private key upon joining the group, through a MAC used as PoP evidence and encoded by the 'client_cred_verify' parameter of the Join Request.
• REQ17: Specify the format of the group keying material that is conveyed in the 'key' parameter: see and of the present document.
• REQ21: TBD Editor's note: Approaches used to compute and verify the PoP evidence to include in the 'kdc_cred_verify' parameter. Reference from and , once also covered the case of a KEM-based group that is a pairwise-only group, with the Group Manager still able to prove possession of its own private key, through a MAC used as PoP evidence and encoded by the 'kdc_cred_verify' parameter of the Join Response.
• REQ29: Categorize newly defined parameters according to the same criteria of : see and of the present document.

Optional-to-Address Requirements The optional-to-address requirements initially specified in are updated as below.

• OPT2: Optionally, specify the additional parameters used in the exchange of Token Transfer Request and Response:
  • 'ecdh_info', to negotiate the ECDH algorithm, ECDH algorithm parameters, ECDH key parameters, and exact format of authentication credentials used in the group, in the case that the joining node supports the pairwise mode of Group OSCORE (see ).
  • 'kdc_dh_creds', to ask for and retrieve the Group Manager's Diffie-Hellman authentication credentials, in the case that the joining node supports the pairwise mode of Group OSCORE and the access token authorizes to join pairwise-only groups (see ).
  • 'pqkem_info', to negotiate the quantum-resistant KEM used as Pairwise Key Agreement Algorithm, the KEM algorithm parameters, the KEM key parameters, and exact format of authentication credentials used in the group, in the case that the group is a KEM-based group and the joining node supports the pairwise mode of Group OSCORE (see of the present document).
• OPT4: Optionally, specify possible or required payload formats for specific error cases: send a 4.00 (Bad Request) error response to a Join Request (see and of the present document).
• 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 Sections and of as well as and of the present document.

Extensibility for Future COSE Algorithms As defined in , future algorithms can be registered in the "COSE Algorithms" registry as specifying none or multiple COSE capabilities. To enable the seamless use of such future registered algorithms, this section defines a general, agile format for:

• Each 'pqkem_info_entry' of the 'pqkem_info' parameter in the Token Transfer Response (see ). describes the analogous general format for each 'sign_info_entry' of the 'sign_info' parameter in the Token Transfer Response (see of this document). describes the analogous general format for each 'ecdh_info_entry' of the 'ecdh_info' parameter in the Token Transfer Response (see of this document).
• The 'pqkem_params' parameter within the 'key' parameter (see ), as part of the response payloads used in , , and .

If any of the currently registered COSE algorithms is considered, using this general format yields the same structure defined in this document for the items above, thus ensuring backward compatibility.

Format of 'pqkem_info_entry' The format of each 'pqkem_info_entry' (see and ) is generalized as follows.

• 'pqkem_parameters' includes N >= 0 elements, each of which is a COSE capability of the KEM algorithm indicated in 'pqkem_alg'. In particular, 'pqkem_parameters' has the same format and value of the COSE capabilities array for the KEM algorithm indicated in 'pqkem_alg', as specified for that algorithm in the 'Capabilities' column of the "COSE Algorithms" registry .
• 'pqkem_key_parameters' is replaced by N elements 'pqkem_capab', each of which is a CBOR array. The i-th 'pqkem_capab' array (i = 0, ..., N-1) is the array of COSE capabilities for the algorithm capability specified in 'pqkem_parameters'[i]. In particular, each 'pqkem_capab' array has the same format and value of the COSE capabilities array for the algorithm capability specified in 'pqkem_parameters'[i]. 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 .

The CDDL notation of the 'pqkem_info_entry' parameter is given below.

'pqkem_info_entry' with General Format

Format of 'key' In addition to what is defined in , the format of 'key' (see and of the present document) is generalized as follows.

• The 'pqkem_params' array includes M+1 elements, whose exact structure and value depend on the value of the KEM algorithm specified in 'pqkem_alg'.
  • The first element, i.e., 'pqkem_params'[0], is the array of the M COSE capabilities for the KEM algorithm, as specified for that algorithm in the "Capabilities" column of the "COSE Algorithms" registry (see ).
  • Each following element 'pqkem_params'[i], i.e., with index i > 0, is the array of COSE capabilities for the algorithm capability specified in 'pqkem_params'[0][i-1].
  For example, if 'pqkem_params'[0][0] specifies the key type as capability of the algorithm, then 'pqkem_params'[1] is the array of COSE capabilities for the COSE key type associated with the KEM algorithm, as specified for that key type in the "Capabilities" column of the "COSE Key Types" registry (see ).

CDDL Model

CDDL Model

Acknowledgments The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next project CYPRESS.