ACE Working Group M. Tiloca Internet-Draft RISE AB Intended status: Standards Track 6 July 2026 Expires: 7 January 2027 Quantum-Resistant Key Encapsulation Mechanisms (KEMs) via the OSCORE Group Manager Using Authentication and Authorization for Constrained Environments (ACE) draft-tiloca-ace-oscore-gm-kem-00 Abstract 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 This note is to be removed before publishing as an RFC. 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 https://mailarchive.ietf.org/arch/browse/ace/. Source for this draft and an issue tracker can be found at https://gitlab.com/crimson84/draft-tiloca-ace-oscore-gm-kem. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Tiloca Expires 7 January 2027 [Page 1] Internet-Draft KEMs via the OSCORE Group Manager July 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Overview of New Operations . . . . . . . . . . . . . . . . . 8 3. Token Transferring . . . . . . . . . . . . . . . . . . . . . 9 3.1. 'pqkem_info' Parameter . . . . . . . . . . . . . . . . . 11 4. Group Joining . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Send the Join Request . . . . . . . . . . . . . . . . . . 14 4.2. Receive the Join Request . . . . . . . . . . . . . . . . 14 4.3. Send the Join Response . . . . . . . . . . . . . . . . . 16 4.4. Receive the Join Response . . . . . . . . . . . . . . . . 18 5. Retrieve Updated Keying Material . . . . . . . . . . . . . . 19 5.1. Get Group Keying Material . . . . . . . . . . . . . . . . 19 5.2. Get Group Keying Material and OSCORE Sender ID . . . . . 19 6. Retrieve Signature Verification Data . . . . . . . . . . . . 20 7. Interface at the Group Manager . . . . . . . . . . . . . . . 21 7.1. /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys . . . . 22 7.1.1. POST Handler . . . . . . . . . . . . . . . . . . . . 22 7.1.2. GET Handler . . . . . . . . . . . . . . . . . . . . . 23 7.1.3. PUT Handler . . . . . . . . . . . . . . . . . . . . . 23 Tiloca Expires 7 January 2027 [Page 2] Internet-Draft KEMs via the OSCORE Group Manager July 2026 7.2. /ace-group/GROUPNAME/kem-pub-keys . . . . . . . . . . . . 23 7.2.1. POST Handler . . . . . . . . . . . . . . . . . . . . 23 7.3. /ace-group/GROUPNAME/nodes/NODENAME/kem-ciphertexts . . . 24 7.3.1. POST Handler . . . . . . . . . . . . . . . . . . . . 24 7.4. /ace-group/GROUPNAME/kem-ciphertexts . . . . . . . . . . 24 7.4.1. POST . . . . . . . . . . . . . . . . . . . . . . . . 25 7.5. Permitted Methods . . . . . . . . . . . . . . . . . . . . 25 7.6. Operations Supported by Clients . . . . . . . . . . . . . 26 8. Additional Interactions with the Group Manager . . . . . . . 27 8.1. Upload a KEM Public Key . . . . . . . . . . . . . . . . . 27 8.2. Retrieve Number of Available Own KEM Public Keys . . . . 29 8.3. Discard Own KEM Public Keys . . . . . . . . . . . . . . . 31 8.4. Retrieve KEM Public Keys of Group Members . . . . . . . . 32 8.5. Upload a KEM Ciphertext . . . . . . . . . . . . . . . . . 35 8.6. Retrieve a KEM Ciphertext . . . . . . . . . . . . . . . . 38 9. Removal of a Group Member . . . . . . . . . . . . . . . . . . 41 10. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . . . 42 11. ACE Groupcomm Error Identifiers . . . . . . . . . . . . . . . 43 12. Default Values for Group Configuration Parameters . . . . . . 44 13. Security Considerations . . . . . . . . . . . . . . . . . . . 45 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 14.1. OAuth Parameters . . . . . . . . . . . . . . . . . . . . 46 14.2. OAuth Parameters CBOR Mappings . . . . . . . . . . . . . 46 14.3. ACE Groupcomm Parameters . . . . . . . . . . . . . . . . 46 14.4. OSCORE Security Context Parameters . . . . . . . . . . . 48 14.5. ACE Groupcomm Errors . . . . . . . . . . . . . . . . . . 49 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 15.1. Normative References . . . . . . . . . . . . . . . . . . 49 15.2. Informative References . . . . . . . . . . . . . . . . . 53 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 53 A.1. Mandatory-to-Address Requirements . . . . . . . . . . . . 53 A.2. Optional-to-Address Requirements . . . . . . . . . . . . 54 Appendix B. Extensibility for Future COSE Algorithms . . . . . . 55 B.1. Format of 'pqkem_info_entry' . . . . . . . . . . . . . . 56 B.2. Format of 'key' . . . . . . . . . . . . . . . . . . . . . 57 Appendix C. CDDL Model . . . . . . . . . . . . . . . . . . . . . 57 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 58 1. Introduction Building on Object Security for Constrained RESTful Environments (OSCORE) [RFC8613], the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) [I-D.ietf-core-oscore-groupcomm] provides end-to-end security for the Constrained Application Protocol (CoAP) [RFC7252] when used in group communication setups [I-D.ietf-core-groupcomm-bis]. An OSCORE group is associated with a Group Manager, i.e., an entity responsible for Tiloca Expires 7 January 2027 [Page 3] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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 Section 8 of [I-D.ietf-core-oscore-groupcomm]), 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 Section 2.1.10 of [I-D.ietf-core-oscore-groupcomm]), which is used to compute the shared secret from which pairwise keys are derived (see Section 2.5.1 of [I-D.ietf-core-oscore-groupcomm]). In particular, the available Pairwise Key Agreement Algorithms are based on a direct Elliptic Curve Diffie-Hellman Static-Static key agreement [NIST-800-56A]. 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 [FIPS203], as the Pairwise Key Agreement Algorithm used to derive pairwise keys [I-D.tiloca-core-group-oscore-kem]. Building on the Authentication and Authorization for Constrained Environments (ACE) framework [RFC9200], the specification [RFC9594] defines a Key Distribution Center (KDC) to provision keying material for secure group communication. The specification [I-D.ietf-ace-key-groupcomm-oscore] is an application profile of [RFC9594] 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. Tiloca Expires 7 January 2027 [Page 4] Internet-Draft KEMs via the OSCORE Group Manager July 2026 This document extends the interface of the Group Manager defined in [I-D.ietf-ace-key-groupcomm-oscore] 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. Appendix A updates how the requirements listed in Appendix A of [I-D.ietf-ace-key-groupcomm-oscore] are additionally fulfilled. 1.1. 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 [RFC2119] [RFC8174] 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) [RFC8610], Concise Binary Object Representation (CBOR) [RFC8949], and CBOR Object Signing and Encryption (COSE) [RFC9052][RFC9053]. * The terms and concepts related to CoAP [RFC7252] and group communication for CoAP [I-D.ietf-core-groupcomm-bis]. * The terms and concepts for protection and processing of CoAP messages through OSCORE [RFC8613] and through Group OSCORE [I-D.ietf-core-oscore-groupcomm] 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 Section 7 of [I-D.ietf-core-oscore-groupcomm]). - Pairwise mode: the mode of Group OSCORE used for providing pairwise secure communication between two members of an OSCORE group (see Section 8 of [I-D.ietf-core-oscore-groupcomm]). Tiloca Expires 7 January 2027 [Page 5] Internet-Draft KEMs via the OSCORE Group Manager July 2026 - 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 Section 2.1.10 of [I-D.ietf-core-oscore-groupcomm]). * The alternative derivation of pairwise keys as defined in [I-D.tiloca-core-group-oscore-kem], 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 [RFC9200]. The terminology for entities in the considered architecture is defined in OAuth 2.0 [RFC6749]. This includes Client (C), Resource Server (RS), and Authorization Server (AS). Unless otherwise indicated, the term "endpoint" is used here following its OAuth definition [RFC6749], 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" [RFC7252], is not used in this document. * The terms and concepts related to the message formats and processing specified in [RFC9594], 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 Appendix A of [I-D.ietf-ace-key-groupcomm-oscore] and possibly updated in Appendix A of the present document. * The terms and concepts related to the application profile of [RFC9594] specified in [I-D.ietf-ace-key-groupcomm-oscore], 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. Tiloca Expires 7 January 2027 [Page 6] Internet-Draft KEMs via the OSCORE Group Manager July 2026 - 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 [I-D.ietf-core-oscore-groupcomm]. - Signature-only group: an OSCORE group that uses only the group mode (see Section 7 of [I-D.ietf-core-oscore-groupcomm]). - Pairwise-only group: an OSCORE group that uses only the pairwise mode (see Section 8 of [I-D.ietf-core-oscore-groupcomm]). - 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. 1.2. Notations Throughout this document, examples for CBOR data items are expressed in CBOR extended diagnostic notation as defined in Section 8 of [RFC8949] and Appendix G of [RFC8610] ("diagnostic notation"). 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 Figure 14 of Appendix C. 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'}. Tiloca Expires 7 January 2027 [Page 7] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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 Figure 14 of Appendix C. Finally, please delete this note. 2. Overview of New Operations This document extends the interface of the Group Manager defined in [I-D.ietf-ace-key-groupcomm-oscore] as follows. When a node exchanges a Token Transfer Request and Token Transfer Response with the Group Manager (see Section 5.3 of [I-D.ietf-ace-key-groupcomm-oscore], 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 Section 3. When a node joins a KEM-based group (see Section 6 of [I-D.ietf-ace-key-groupcomm-oscore]): * 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 Section 4.1 and Section 4.2. * 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 Section 4.3 and Section 4.4. When a member of a KEM-based group retrieves updated keying material from the Group Manager (see Section 9.1 of [I-D.ietf-ace-key-groupcomm-oscore]), 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 Section 5. 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 Section 9.6 of [I-D.ietf-ace-key-groupcomm-oscore]), 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 Section 6. According to the new resources defined in Section 7, a member P of a KEM-based group can perform the following actions by interacting with the Group Manager: Tiloca Expires 7 January 2027 [Page 8] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * 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 Section 7.1.1. * 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 Section 7.1.2. * Discard all its own KEM public keys stored at the Group Manager as intended to other members of the group. This is defined in Section 7.1.3. * 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 Section 7.2. * 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 Section 7.3. * 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 Section 7.4. Section 8 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. 3. Token Transferring In addition to what is defined in Section 5.3 of [I-D.ietf-ace-key-groupcomm-oscore], the following applies to the exchange of Token Transfer Request and Token Transfer Response originally defined in Section 3.3 of [RFC9594]. * 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 Section 3.1 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 Tiloca Expires 7 January 2027 [Page 9] Internet-Draft KEMs via the OSCORE Group Manager July 2026 authorized to join. This is relevant if the joining node supports the pairwise mode of Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 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 [IANA.COSE.Algorithms]. - '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 [IANA.COSE.Algorithms]. - '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 [IANA.COSE.Key.Types]. - 'cred_fmt' takes value from the "Label" column of the "COSE Header Parameters" registry [IANA.COSE.Header.Parameters]. To align with Section 2.4 of [I-D.ietf-core-oscore-groupcomm], 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 Section 3.3 of [RFC9594] 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 Section 3.3 of [RFC9594], 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 Tiloca Expires 7 January 2027 [Page 10] Internet-Draft KEMs via the OSCORE Group Manager July 2026 joining node may early retrieve it, e.g., by using the approach described in [I-D.tiloca-core-oscore-discovery] to discover the OSCORE group and the link to the associated group-membership resource at the Group Manager. 3.1. '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 Section 5.10.1 of [RFC9200]). 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 [RFC9594], 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 Section 3.2 of [RFC9594]). When used in the Token Transfer Request sent to the KDC (see Section 3.3 of [RFC9594]), 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 Section 3.3 of [RFC9594]), 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. Tiloca Expires 7 January 2027 [Page 11] Internet-Draft KEMs via the OSCORE Group Manager July 2026 For application profiles of [RFC9594] 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 [IANA.COSE.Algorithms]. * 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 [RFC9594] 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 [RFC9594] 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 [IANA.COSE.Header.Parameters], with some of those values also indicating the type of container to use for exchanging the authentication credentials with the KDC (e.g., a chain or bag of certificates). For application profiles of [RFC9594] 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. Tiloca Expires 7 January 2027 [Page 12] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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 [RFC8610] of the 'pqkem_info' parameter is given below. pqkem_info = pqkem_info_req / pqkem_info_resp pqkem_info_req = null ; in the Token Transfer ; Request to the KDC pqkem_info_resp = [+ pqkem_info_entry] ; in the Token Transfer ; Response from the KDC pqkem_info_entry = [ id: gname / [+ gname], pqkem_alg: int / tstr, pqkem_parameters: [any], pqkem_key_parameters: [+ parameter: any], cred_fmt: int / null ] gname = tstr This format is consistent with every KEM algorithm currently registered by [I-D.ietf-jose-pqc-kem], i.e., with algorithms that have only the COSE key type as their COSE capability. Appendix B 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. 4. Group Joining Building on Section 6 of [I-D.ietf-ace-key-groupcomm-oscore], this section specifies additions to the joining process that are relevant when the joined group is a KEM-based group. Tiloca Expires 7 January 2027 [Page 13] Internet-Draft KEMs via the OSCORE Group Manager July 2026 4.1. Send the Join Request In addition to what is defined in Section 6.1 of [I-D.ietf-ace-key-groupcomm-oscore], 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 Section 14.3. 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 [SHA-256] 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. 4.2. Receive the Join Request In addition to what is defined in Section 6.2 of [I-D.ietf-ace-key-groupcomm-oscore], 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. Tiloca Expires 7 January 2027 [Page 14] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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" [RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594]. 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" [RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594]. 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 Section 6.2 of [I-D.ietf-ace-key-groupcomm-oscore] 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 Section 14.3. This parameter has the same format of 'pqkem_info_resp' defined in Section 3.1 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. Tiloca Expires 7 January 2027 [Page 15] Internet-Draft KEMs via the OSCORE Group Manager July 2026 4.3. 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 Section 6.3 of [I-D.ietf-ace-key-groupcomm-oscore], 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 Section 4.3.1 of [RFC9594], 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 Section 7.1). 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 Section 7.3). 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 Section 14.3 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 Section 6.3 of [I-D.ietf-ace-key-groupcomm-oscore] in which the group is not a KEM-based group, the parameters 'ecdh_alg' and 'ecdh_params' MUST NOT be included. Tiloca Expires 7 January 2027 [Page 16] Internet-Draft KEMs via the OSCORE Group Manager July 2026 - 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 [IANA.COSE.Algorithms]. - 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: o '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 [IANA.COSE.Algorithms]. o '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 [IANA.COSE.Key.Types]. The format of 'key' defined above is consistent with every KEM algorithm currently registered by [I-D.ietf-jose-pqc-kem], i.e., with algorithms that have only the COSE key type as their COSE capability. Appendix B.2 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 Section 6.3 of [I-D.ietf-ace-key-groupcomm-oscore]). 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. Tiloca Expires 7 January 2027 [Page 17] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * 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. 4.4. Receive the Join Response Upon receiving a Join Response resulting from having joined a KEM- based group, the joining node proceeds as defined in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore], 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 Section 6.3 of [I-D.ietf-ace-key-groupcomm-oscore]), 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. Tiloca Expires 7 January 2027 [Page 18] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * 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'. 5. Retrieve Updated Keying Material Building on Section 9.1 of [I-D.ietf-ace-key-groupcomm-oscore], 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. 5.1. Get Group Keying Material This section builds on and updates what is defined in Section 9.1.1 of [I-D.ietf-ace-key-groupcomm-oscore]. 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 Section 9.1.1 of [I-D.ietf-ace-key-groupcomm-oscore], 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 Section 4.3 of the present document). * The 'key' parameter is formatted as defined in Section 4.3 of the present document, with the difference that it does not include the 'group_SenderId' parameter. 5.2. Get Group Keying Material and OSCORE Sender ID This section builds on and updates what is defined in Section 9.1.2 of [I-D.ietf-ace-key-groupcomm-oscore]. 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 Section 9.1.2 of [I-D.ietf-ace-key-groupcomm-oscore], with the following modifications. Tiloca Expires 7 January 2027 [Page 19] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * 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 Section 4.3 of the present document). * The 'key' parameter is formatted as defined in Section 4.3 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. 6. Retrieve Signature Verification Data Building on Section 9.6 of [I-D.ietf-ace-key-groupcomm-oscore], 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 Section 9.6 of [I-D.ietf-ace-key-groupcomm-oscore], with the following modifications. * Of the parameters present in the Join Response message (see Section 4.3 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. Tiloca Expires 7 January 2027 [Page 20] Internet-Draft KEMs via the OSCORE Group Manager July 2026 - The 'pqkem_alg' parameter. This parameter MUST NOT be present if the group is not a KEM-based group. Otherwise, it MUST be present. 7. Interface at the Group Manager In addition to what is specified in Section 8 of [I-D.ietf-ace-key-groupcomm-oscore], this document extends the interface at the Group Manager by defining the new sub-resources specified in Section 7.1, Section 7.2, Section 7.3, and Section 7.4. The Group Manager hosts those resources for each KEM-group that it is responsible for. In addition to what is defined in Section 4.1.2 of [RFC9594], 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" [RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594]. 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" [RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594]. 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 Section 8.2 of [I-D.ietf-ace-key-groupcomm-oscore]). 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" [RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594]. 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"). Tiloca Expires 7 January 2027 [Page 21] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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 [I-D.ietf-ace-oscore-gm-admin]. Section 7.5 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). 7.1. /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 Section 4.3). 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. 7.1.1. 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 Section 8.1). 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 Tiloca Expires 7 January 2027 [Page 22] Internet-Draft KEMs via the OSCORE Group Manager July 2026 currently stores as generated by the node NODENAME and pertaining to the group GROUPNAME. The payload of the response is formatted as defined in Section 8.1. 7.1.2. 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 Section 8.2. The Group Manager SHOULD make the resource at /ace- group/GROUPNAME/nodes/NODENAME/kem-pub-keys also observable [RFC7641], 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. 7.1.3. PUT Handler The handler expects a PUT request, whose payload is the CBOR unsigned integer encoding the value 0 (see Section 8.3). 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 Section 8.3. 7.2. /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. 7.2.1. 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 Section 8.4). Tiloca Expires 7 January 2027 [Page 23] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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 Section 8.4. 7.3. /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. 7.3.1. 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 Section 8.5). 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. 7.4. /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. Tiloca Expires 7 January 2027 [Page 24] Internet-Draft KEMs via the OSCORE Group Manager July 2026 7.4.1. 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 Section 8.6). 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 Section 8.6. 7.5. Permitted Methods Table 1 below extends Table 2 of [I-D.ietf-ace-key-groupcomm-oscore] 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) Tiloca Expires 7 January 2027 [Page 25] Internet-Draft KEMs via the OSCORE Group Manager July 2026 +=================================+=======+=======+=======+=======+ | Resource | Type1 | Type2 | Type3 | Type4 | +=================================+=======+=======+=======+=======+ | /ace-group/GROUPNAME/kem-pub- | P | - | - | - | | keys | | | | | +---------------------------------+-------+-------+-------+-------+ | /ace-group/GROUPNAME/kem- | P | - | - | - | | ciphertexts | | | | | +---------------------------------+-------+-------+-------+-------+ | /ace- | G P | - | - | - | | group/GROUPNAME/nodes/NODENAME/ | Pu | | | | | kem-pub-keys | | | | | +---------------------------------+-------+-------+-------+-------+ | /ace- | P | - | - | - | | group/GROUPNAME/nodes/NODENAME/ | | | | | | kem-ciphertexts | | | | | +---------------------------------+-------+-------+-------+-------+ Table 1: Permitted CoAP Methods on the Group Manager Resources 7.6. Operations Supported by Clients Building on what is defined in Section 4.1.1 of [RFC9594] and in Section 8.6 of [I-D.ietf-ace-key-groupcomm-oscore], and with reference to the additional resources at the Group Manager defined in Section 7 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. Tiloca Expires 7 January 2027 [Page 26] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * 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. 8. Additional Interactions with the Group Manager This section defines the possible interactions with the Group Manager, in addition to those specified in [I-D.ietf-ace-key-groupcomm-oscore]. 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. 8.1. 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 Section 7.1.1, 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. Tiloca Expires 7 January 2027 [Page 27] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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" [RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594]. 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" [RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594]. 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 [SHA-256] of the KEM public key as the corresponding identifier. Tiloca Expires 7 January 2027 [Page 28] Internet-Draft KEMs via the OSCORE Group Manager July 2026 Figure 1 gives an overview of the exchange described above, while Figure 2 shows an example of KEM Public Key Upload Request-Response. Group Group Member Manager | | | KEM Public Key Upload Request | |-------------------------------------------------------------->| | POST /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys | | | |<------- KEM Public Key Upload Response: 2.04 (Changed) -------| | | Figure 1: Message Flow of KEM Public Key Upload Request-Response Request: Header: POST (Code=0.02) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "nodes" Uri-Path: "c101" Uri-Path: "kem-pub-keys" Content-Format: 261 (application/ace-groupcomm+cbor) Payload (in CBOR diagnostic notation): { e'client_kem_pubkey': h'4199...6c5a' / elided for brevity / } Response: Header: Changed (Code=2.04) Content-Format: 60 (application/cbor) Payload (in CBOR diagnostic notation): 5 Figure 2: Example of KEM Public Key Upload Request-Response 8.2. 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. Tiloca Expires 7 January 2027 [Page 29] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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 Section 7.1.2, 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. Figure 3 gives an overview of the exchange described above, while Figure 4 shows an example of KEM Public Key Number Request-Response. Group Group Member Manager | | | KEM Public Key Number Request | |-------------------------------------------------------------->| | GET /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys | | | |<------- KEM Public Key Number Response: 2.05 (Content) -------| | | Figure 3: Message Flow of KEM Public Key Number Request-Response Request: Header: GET (Code=0.01) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "nodes" Uri-Path: "c101" Uri-Path: "kem-pub-keys" Response: Header: Content (Code=2.05) Content-Format: 60 (application/cbor) Payload (in CBOR diagnostic notation): 5 Figure 4: Example of KEM Public Key Number Request-Response Tiloca Expires 7 January 2027 [Page 30] Internet-Draft KEMs via the OSCORE Group Manager July 2026 8.3. 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 Section 7.1.3, 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 [SHA-256] of the KEM public keys as the corresponding identifiers. Figure 5 gives an overview of the exchange described above, while Figure 6 shows an example of KEM Public Key Discard Request-Response. Tiloca Expires 7 January 2027 [Page 31] Internet-Draft KEMs via the OSCORE Group Manager July 2026 Group Group Member Manager | | | KEM Public Key Discard Request | |-------------------------------------------------------------->| | PUT /ace-group/GROUPNAME/nodes/NODENAME/kem-pub-keys | | | |<------ KEM Public Key Discard Response: 2.04 (Changed) -------| | | Figure 5: Message Flow of KEM Public Key Discard Request-Response Request: Header: PUT (Code=0.03) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "nodes" Uri-Path: "c101" Uri-Path: "kem-pub-keys" Content-Format: 60 (application/cbor) Payload (in CBOR diagnostic notation): 0 Response: Header: Changed (Code=2.04) Content-Format: 60 (application/cbor) Payload (in CBOR diagnostic notation): 0 Figure 6: Example of KEM Public Key Discard Request-Response 8.4. 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 Section 7.2.1, where GROUPNAME is the name of the OSCORE group. Tiloca Expires 7 January 2027 [Page 32] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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 Tiloca Expires 7 January 2027 [Page 33] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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. Figure 7 gives an overview of the exchange described above, while Figure 8 shows an example of KEM Public Key Retrieval Request- Response. Group Group Member Manager | | | KEM Public Key Retrieval Request | |-------------------------------------------------------------->| | POST /ace-group/GROUPNAME/kem-pub-keys | | | |<----- KEM Public Key Retrieval Response: 2.04 (Changed) ------| | | Figure 7: Message Flow of KEM Public Key Retrieval Request-Response Tiloca Expires 7 January 2027 [Page 34] Internet-Draft KEMs via the OSCORE Group Manager July 2026 Request: Header: POST (Code=0.02) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "kem-pub-keys" Content-Format: 261 (application/ace-groupcomm+cbor) Payload (in CBOR diagnostic notation): { / peer_identifiers / 15: [h'01', h'02', h'03'] } Response: Header: Changed (Code=2.04) Content-Format: 261 (application/ace-groupcomm+cbor) Payload (in CBOR diagnostic notation): { e'kem_pubkeys': [ h'acb6...976e', / elided for brevity / h'bbf2...ae88', / elided for brevity / null ] } Figure 8: Example of KEM Public Key Retrieval Request-Response 8.5. 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 Section 7.3, 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: Tiloca Expires 7 January 2027 [Page 35] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * '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 Section 3 of [I-D.tiloca-core-group-oscore-kem], 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 [SHA-256] 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" [RFC9290] and is formatted as defined in Section 4.1.2 of [RFC9594]. 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: Tiloca Expires 7 January 2027 [Page 36] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * 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. Figure 9 gives an overview of the exchange described above, while Figure 10 shows an example of KEM Ciphertext Upload Request-Response. Group Group Member Manager | | | KEM Ciphertext Upload Request | |-------------------------------------------------------------->| | POST /ace-group/GROUPNAME/nodes/NODENAME/kem-ciphertexts | | | |<------- KEM Ciphertext Upload Response: 2.04 (Changed) -------| | | Figure 9: Message Flow of KEM Ciphertext Upload Request-Response Tiloca Expires 7 January 2027 [Page 37] Internet-Draft KEMs via the OSCORE Group Manager July 2026 Request: Header: POST (Code=0.02) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "nodes" Uri-Path: "c101" Uri-Path: "kem-ciphertexts" Content-Format: 261 (application/ace-groupcomm+cbor) Payload (in CBOR diagnostic notation): { e'kem_ciphertext': h'1388...aa42', / elided for brevity / e'kem_pubkey_hash': h'9bef...ccd2', / elided for brevity / / group_senderId / 21: h'07' } Response: Header: Changed (Code=2.04) Figure 10: Example of KEM Ciphertext Upload Request-Response 8.6. 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 Section 7.4.1, 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: Tiloca Expires 7 January 2027 [Page 38] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * 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. Tiloca Expires 7 January 2027 [Page 39] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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 Section 3 of [I-D.tiloca-core-group-oscore-kem], 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. Figure 11 gives an overview of the exchange described above, while Figure 12 shows an example of KEM Ciphertext Retrieval Request- Response. Group Group Member Manager | | | KEM Ciphertext Retrieval Request | |-------------------------------------------------------------->| | POST /ace-group/GROUPNAME/kem-ciphertexts | | | |<----- KEM Ciphertext Retrieval Response: 2.04 (Changed) ------| | | Figure 11: Message Flow of KEM Ciphertext Retrieval Request-Response Tiloca Expires 7 January 2027 [Page 40] Internet-Draft KEMs via the OSCORE Group Manager July 2026 Request: Header: POST (Code=0.02) Uri-Host: "kdc.example.com" Uri-Path: "ace-group" Uri-Path: "g1" Uri-Path: "kem-ciphertexts" Content-Format: 261 (application/ace-groupcomm+cbor) Payload (in CBOR diagnostic notation): { / group_senderId / 21: h'00' } Response: Header: Changed (Code=2.04) Content-Format: 261 (application/ace-groupcomm+cbor) Payload (in CBOR diagnostic notation): { e'kem_ciphertext': h'1388...aa42', / elided for brevity / e'kem_pubkey_hash': h'9bef...ccd2' / elided for brevity / } Figure 12: Example of KEM Ciphertext Retrieval Request-Response 9. Removal of a Group Member In addition to what is defined in Section 10 of [I-D.ietf-ace-key-groupcomm-oscore], 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. Tiloca Expires 7 January 2027 [Page 41] Internet-Draft KEMs via the OSCORE Group Manager July 2026 - 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 Section 5 of [RFC9594]). 10. ACE Groupcomm Parameters In addition to what is defined in Section 8 of [RFC9594] and Section 12 of [I-D.ietf-ace-key-groupcomm-oscore], 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 Section 5.3 of [I-D.ietf-ace-key-groupcomm-oscore]). 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. +===================+==========+===========+============+ | 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] | +-------------------+----------+-----------+------------+ Table 2: ACE Groupcomm Parameters 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): Tiloca Expires 7 January 2027 [Page 42] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * 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. 11. ACE Groupcomm Error Identifiers In addition to what is defined in Section 9 of [RFC9594] and Section 13 of [I-D.ietf-ace-key-groupcomm-oscore], 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" [RFC9290], as values of the 'error-id' field within the Custom Problem Detail entry 'ace-groupcomm-error' (see Section 4.1.2 of [RFC9594]). +=======+==========================================================+ | 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 | +-------+----------------------------------------------------------+ Table 3: ACE Groupcomm Error Identifiers If the Client supports the problem-details format [RFC9290] and the Custom Problem Detail entry 'ace-groupcomm-error' defined in Section 4.1.2 of [RFC9594], 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. Tiloca Expires 7 January 2027 [Page 43] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * 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 Section 7.1.2 and Section 8.2). If the resource is observable [RFC7641], 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. 12. Default Values for Group Configuration Parameters Building on what is defined in Section 14 of [I-D.ietf-ace-key-groupcomm-oscore], 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 [I-D.ietf-ace-oscore-gm-admin]). 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. Tiloca Expires 7 January 2027 [Page 44] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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 [IANA.COSE.Algorithms] and the "COSE Key Types" registry [IANA.COSE.Key.Types]. * 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 [I-D.ietf-jose-pqc-kem], which indicates the ML- KEM-512 parameter set of the standard ML-KEM [FIPS203]. In such case, the parameter 'pqkem_params' (see Section 4.3) specifies the array [[AKP], [AKP]]. This indicates to use the COSE key type AKP registered by [RFC9964]. Editor's note: at the moment, the configuration parameters above are not reflected by an admin interface such as that defined in [I-D.ietf-ace-oscore-gm-admin]. That interface can also be updated, in order for an Administrator to (re-)configure an OSCORE group as per those parameters too. 13. Security Considerations The security considerations from [RFC9200], [RFC9594], and [I-D.ietf-ace-key-groupcomm-oscore] 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. Tiloca Expires 7 January 2027 [Page 45] Internet-Draft KEMs via the OSCORE Group Manager July 2026 14. 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. 14.1. OAuth Parameters IANA is asked to register the following entry in the "OAuth Parameters" registry [IANA.OAuth.Parameters] within the "OAuth Parameters" registry group, following the procedure specified in Section 11.2 of [RFC6749]. * Name: pqkem_info * Parameter Usage Location: client-rs request, rs-client response * Change Controller: IETF * Reference: [RFC-XXXX] 14.2. OAuth Parameters CBOR Mappings IANA is asked to register the following entry in the "OAuth Parameters CBOR Mappings" registry [IANA.OAuth.CBOR.Mappings] within the "Authentication and Authorization for Constrained Environments (ACE)" registry group, following the procedure specified in Section 8.10 of [RFC9200]. * Name: pqkem_info * CBOR Key: TBD (value between 1 and 255) * Value Type: Null or array * Reference: [RFC-XXXX] * Original Specification: [RFC-XXXX] 14.3. ACE Groupcomm Parameters IANA is asked to register the following entries to the "ACE Groupcomm Parameters" registry [IANA.ACE.Groupcomm.Parameters] within the "Authentication and Authorization for Constrained Environments (ACE)" registry group. * Name: max_kem_pubkeys Tiloca Expires 7 January 2027 [Page 46] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * 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] Tiloca Expires 7 January 2027 [Page 47] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * Name: pqkem_info * CBOR Key: 39 (suggested) * CBOR Type: array * Reference: [RFC-XXXX] 14.4. OSCORE Security Context Parameters IANA is asked to register the following entries in the "OSCORE Security Context Parameters" registry [IANA.OSCORE.Security.Context.Parameters] within the "Authentication and Authorization for Constrained Environments (ACE)" registry group. * Name: pqkem_alg * CBOR Label: 14 (suggested) * CBOR Type: text string / integer * Registry: [IANA.COSE.Algorithms] 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: [IANA.COSE.Algorithms] Capabilities, [IANA.COSE.Key.Types] Capabilities * Description: OSCORE Pairwise Key Agreement Algorithm Parameters, when that algorithm is a Key Encapsulation Mechanism (KEM) * Reference: [RFC-XXXX] Tiloca Expires 7 January 2027 [Page 48] Internet-Draft KEMs via the OSCORE Group Manager July 2026 14.5. ACE Groupcomm Errors IANA is asked to register the following entries in the "ACE Groupcomm Errors" registry [IANA.ACE.Groupcomm.Errors] 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] 15. References 15.1. Normative References [FIPS203] "Module-Lattice-Based Key-Encapsulation Mechanism Standard", NIST FIPS 203, August 2024, . [I-D.ietf-ace-key-groupcomm-oscore] Tiloca, M. and F. Palombini, "Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE)", Work in Progress, Internet-Draft, draft-ietf-ace-key-groupcomm-oscore-21, 14 March 2026, . Tiloca Expires 7 January 2027 [Page 49] Internet-Draft KEMs via the OSCORE Group Manager July 2026 [I-D.ietf-core-groupcomm-bis] Dijk, E. and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 18, 10 February 2026, . [I-D.ietf-core-oscore-groupcomm] Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., and R. Höglund, "Group Object Security for Constrained RESTful Environments (Group OSCORE)", Work in Progress, Internet-Draft, draft-ietf-core-oscore-groupcomm-28, 23 December 2025, . [I-D.ietf-jose-pqc-kem] Reddy.K, T., Banerjee, A., and H. Tschofenig, "Post- Quantum Key Encapsulation Mechanisms (PQ KEMs) for COSE", Work in Progress, Internet-Draft, draft-ietf-jose-pqc-kem- 06, 6 July 2026, . [I-D.tiloca-core-group-oscore-kem] Tiloca, M., "Using Quantum-Resistant Key Encapsulation Mechanisms (KEMs) in the Pairwise Mode of Group Object Security for Constrained RESTful Environments (Group OSCORE)", Work in Progress, Internet-Draft, draft-tiloca- core-group-oscore-kem-00, 6 July 2026, . [IANA.ACE.Groupcomm.Errors] IANA, "ACE Groupcomm Errors", . [IANA.ACE.Groupcomm.Parameters] IANA, "ACE Groupcomm Parameters", . [IANA.COSE.Algorithms] IANA, "COSE Algorithms", . Tiloca Expires 7 January 2027 [Page 50] Internet-Draft KEMs via the OSCORE Group Manager July 2026 [IANA.COSE.Header.Parameters] IANA, "COSE Header Parameters", . [IANA.COSE.Key.Types] IANA, "COSE Key Types", . [IANA.OAuth.CBOR.Mappings] IANA, "OAuth Parameters CBOR Mappings", . [IANA.OAuth.Parameters] IANA, "OAuth Parameters", . [IANA.OSCORE.Security.Context.Parameters] IANA, "OSCORE Security Context Parameters", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Tiloca Expires 7 January 2027 [Page 51] Internet-Draft KEMs via the OSCORE Group Manager July 2026 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, . [RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, . [RFC9290] Fossati, T. and C. Bormann, "Concise Problem Details for Constrained Application Protocol (CoAP) APIs", RFC 9290, DOI 10.17487/RFC9290, October 2022, . [RFC9594] Palombini, F. and M. Tiloca, "Key Provisioning for Group Communication Using Authentication and Authorization for Constrained Environments (ACE)", RFC 9594, DOI 10.17487/RFC9594, September 2024, . [RFC9964] Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May 2026, . Tiloca Expires 7 January 2027 [Page 52] Internet-Draft KEMs via the OSCORE Group Manager July 2026 [SHA-256] NIST, "Secure Hash Standard", NIST FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4 , August 2015, . 15.2. Informative References [I-D.ietf-ace-oscore-gm-admin] Tiloca, M., Höglund, R., Van der Stok, P., and F. Palombini, "Admin Interface for the OSCORE Group Manager", Work in Progress, Internet-Draft, draft-ietf-ace-oscore- gm-admin-17, 26 March 2026, . [I-D.tiloca-core-oscore-discovery] Tiloca, M., Amsüss, C., and P. Van der Stok, "Discovery of OSCORE Groups with the CoRE Resource Directory", Work in Progress, Internet-Draft, draft-tiloca-core-oscore- discovery-19, 2 March 2026, . [NIST-800-56A] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography - NIST Special Publication 800-56A, Revision 3", April 2018, . Appendix A. Profile Requirements This section updates how the requirements listed in Appendix A of [I-D.ietf-ace-key-groupcomm-oscore] are additionally fulfilled. The following includes only the requirements for which the present document provides an update. A.1. Mandatory-to-Address Requirements The mandatory-to-address requirements initially specified in Appendix A.1 of [I-D.ietf-ace-key-groupcomm-oscore] 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 Tiloca Expires 7 January 2027 [Page 53] Internet-Draft KEMs via the OSCORE Group Manager July 2026 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 Section 8.5 of [I-D.ietf-ace-key-groupcomm-oscore] and Section 7.5 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 Section 8.6 of [I-D.ietf-ace-key-groupcomm-oscore] and Section 7.6 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 Section 4.1 and Section 4.2, 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 Section 6.3 of [I-D.ietf-ace-key-groupcomm-oscore] and Section 4.3 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 Section 4.3 and Section 4.4, 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 Section 8 of [RFC9594]: see Section 12 of [I-D.ietf-ace-key-groupcomm-oscore] and Section 10 of the present document. A.2. Optional-to-Address Requirements The optional-to-address requirements initially specified in Appendix A.2 of [I-D.ietf-ace-key-groupcomm-oscore] are updated as below. Tiloca Expires 7 January 2027 [Page 54] Internet-Draft KEMs via the OSCORE Group Manager July 2026 * 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 Section 5.3 of [I-D.ietf-ace-key-groupcomm-oscore]). - '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 Section 5.3 of [I-D.ietf-ace-key-groupcomm-oscore]). - '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 Section 3 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 Section 6.2 of [I-D.ietf-ace-key-groupcomm-oscore] and Section 4.2 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 13 and 17.11 of [I-D.ietf-ace-key-groupcomm-oscore] as well as Section 11 and Section 14.5 of the present document. Appendix B. Extensibility for Future COSE Algorithms As defined in Section 8.1 of [RFC9053], future algorithms can be registered in the "COSE Algorithms" registry [IANA.COSE.Algorithms] 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 Section 3.1). Tiloca Expires 7 January 2027 [Page 55] Internet-Draft KEMs via the OSCORE Group Manager July 2026 Appendix B of [RFC9594] describes the analogous general format for each 'sign_info_entry' of the 'sign_info' parameter in the Token Transfer Response (see Section 3 of this document). Appendix B.1 of [I-D.ietf-ace-key-groupcomm-oscore] describes the analogous general format for each 'ecdh_info_entry' of the 'ecdh_info' parameter in the Token Transfer Response (see Section 3 of this document). * The 'pqkem_params' parameter within the 'key' parameter (see Section 4.3), as part of the response payloads used in Section 4.3, Section 5.1, and Section 5.2. 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. B.1. Format of 'pqkem_info_entry' The format of each 'pqkem_info_entry' (see Section 3 and Section 3.1) 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 [IANA.COSE.Algorithms]. * '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 [IANA.COSE.Key.Types]. The CDDL notation [RFC8610] of the 'pqkem_info_entry' parameter is given below. Tiloca Expires 7 January 2027 [Page 56] Internet-Draft KEMs via the OSCORE Group Manager July 2026 pqkem_info_entry = [ id: gname / [+ gname], pqkem_alg: int / tstr, pqkem_parameters : [* pqkem_capab: any], * pqkem_capab: [* capab: any], cred_fmt: int / null ] gname = tstr Figure 13: 'pqkem_info_entry' with General Format B.2. Format of 'key' In addition to what is defined in Appendix B.2 of [I-D.ietf-ace-key-groupcomm-oscore], the format of 'key' (see Section 6.3 of [I-D.ietf-ace-key-groupcomm-oscore] and Section 4.3 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 [IANA.COSE.Algorithms] (see Section 8.1 of [RFC9053]). - 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 [IANA.COSE.Key.Types] (see Section 8.2 of [RFC9053]). Appendix C. CDDL Model This section is to be removed before publishing as an RFC. Tiloca Expires 7 January 2027 [Page 57] Internet-Draft KEMs via the OSCORE Group Manager July 2026 ; ACE Groupcomm Parameters client_kem_pubkey = 35 kem_pubkeys = 36 kem_ciphertext = 37 kem_pubkey_hash = 38 Figure 14: 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. Author's Address Marco Tiloca RISE AB Isafjordsgatan 22 SE-164 40 Kista Sweden Email: marco.tiloca@ri.se Tiloca Expires 7 January 2027 [Page 58]