Authors, While reviewing this document during Final Review, please resolve (as necessary) the following questions, which are also in GitHub issues (see https://github.com/rfc-editor-drafts/FinalReview-rfc10021/issues).
1) <!--[rfced] FYI - We will do the following when we convert the file to RFCXML: - remove "PRE-" in "PRE-RFC10020" and "PRE-10020" --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!-- [rfced] To clarify the sentence below, which of the two are calculated with the asymmetric keys of the sender and recipient? Symmetric keys or Diffie-Hellman shared secrets? Current: These symmetric keys are derived from Diffie-Hellman shared secrets, calculated with the asymmetric keys of the sender and recipient, allowing for shorter integrity tags and therefore lower message overhead. Perhaps (Diffie-Hellman shared secrets): These symmetric keys are derived from Diffie-Hellman shared secrets, which are calculated with the asymmetric keys of the sender and recipient, allowing for shorter integrity tags and therefore lower message overhead. Or Perhaps (symmetric keys): These symmetric keys are derived from Diffie-Hellman shared secrets and are calculated with the asymmetric keys of the sender and recipient, allowing for shorter integrity tags and therefore lower message overhead. --> 4) <!--[rfced] In this sentence, "required neither to be ... nor to take part" reads oddly. May we update as shown below for clarity? Current: Group Manager: An entity responsible for a group, required neither to be an actual group member nor to take part in the group communication. Perhaps: Group Manager: An entity responsible for a group. A Group Manager is not required to be an actual group member or to participate in group communication. --> 5) <!-- [rfced] Should "reporting" be rephrased as "to report"? Original: A silent server may send unprotected responses, as error responses reporting a Group OSCORE error. Perhaps: A silent server may send unprotected responses as error responses to report a Group OSCORE error. --> 6) <!-- [rfced] For Figure 1, may we place the second sentence of the figure title below the figure as an aside (or as a separate paragraph)? Original: Figure 1: Additions to the OSCORE Security Context. The elements labeled with * and with ^ are relevant only for the group mode and only for the pairwise mode, respectively. Perhaps: Figure 1: Additions to the OSCORE Security Context Note: The elements labeled with * and with ^ are relevant only for the group mode and only for the pairwise mode, respectively. --> 7) <!-- [rfced] FYI - We have removed "HMAC-based" from "HKDF Algorithms" to avoid redundancy, as this would read "HMAC-based HMAC-based Key Derivation Function algorithms" if expanded. Current: The HMAC-based Key Derivation Function (HKDF) Algorithm (see Section 3.1 of [RFC8613]) identifies the used key derivation function, which MUST be one of the HKDF [RFC5869] algorithms defined for COSE (see Section 5.1 of [RFC9053]) and registered at [COSE.Algorithms]. --> 8) <!-- [rfced] FYI - We noticed the use of the <sup> element for superscripts. We have added this element to other superscripts in this document for consistency. Please review each instance and let us know if they appear as intended. --> 9) <!-- [rfced] May we rephrase the sentence below as follows for clarity? Current: The following defines how an endpoint derives the keystream KEYSTREAM, used to encrypt/decrypt the countersignature of an outgoing/incoming message M protected in group mode. Perhaps: The following section defines how an endpoint derives the keystream KEYSTREAM, which is used to encrypt/decrypt the countersignature of an outgoing/incoming message M protected in group mode. --> 10) <!--[rfced] May we update each instance of "hold" to "apply" (and "holds" to "applies") for clarity? One example: Original: Therefore, building on Section 7.3 of [RFC8613], the following properties hold for Group OSCORE: Perhaps: Therefore, building on Section 7.3 of [RFC8613], the following properties apply to Group OSCORE: ... Note that we will leave this instance as is: In fact, as long as the Master Secret is different for different groups and this condition holds over time, keys are different among different groups. --> 11) <!-- [rfced] We are having trouble with "is not set" in these two sentences. If it relates to the parameters, we suggest updating as "that are not set". Also, it mentions "the following parameters" and lists two algorithms. Is this correct? Please review. Original: * The Group Flag is set to 0 and the retrieved Security Context is associated with an OSCORE group, but the endpoint does not support the pairwise mode or any of the following parameters is not set in the Security Context: the AEAD Algorithm and the Pairwise Key Agreement Algorithm. * The Group Flag is set to 1 and the retrieved Security Context is associated with an OSCORE group, but the endpoint does not support the group mode or any of the following parameters is not set in the Security Context: the Group Encryption Algorithm and the Signature Algorithm. Perhaps: * The Group Flag is set to 0 and the retrieved Security Context is associated with an OSCORE group, but the endpoint does not support the pairwise mode or any of the following parameters that are not set in the Security Context: the AEAD Algorithm and the Pairwise Key Agreement Algorithm. * The Group Flag is set to 1 and the retrieved Security Context is associated with an OSCORE group, but the endpoint does not support the group mode or any of the following parameters that are not set in the Security Context: the Group Encryption Algorithm and the Signature Algorithm. --> 12) <!-- [rfced] FYI - We have updated the sentences below to use "and/or" for clarity. Please let us know if this is incorrect. Original: Less constrained endpoints MUST implement at least one of the following and SHOULD implement both: the EdDSA signature algorithm together with the elliptic curve Ed25519 [RFC8032]; the ECDSA signature algorithm together with the elliptic curve P-256. Constrained endpoints MUST implement at least one of the following and, if affordable, SHOULD implement both: the EdDSA signature algorithm together with the elliptic curve Ed25519 [RFC8032]; the ECDSA signature algorithm together with the elliptic curve P-256. ... Less constrained endpoints MUST implement at least one of the following ECDH curves and SHOULD implement both: the X25519 curve [RFC7748]; the P-256 curve. Constrained endpoints MUST implement at least one of the following ECDH curves and, if affordable, SHOULD implement both: the X25519 curve [RFC7748]; the P-256 curve. Current: Less constrained endpoints MUST implement at least one of the following and SHOULD implement both: the EdDSA signature algorithm together with the elliptic curve Ed25519 [RFC8032] and/or the ECDSA signature algorithm together with the elliptic curve P-256. Constrained endpoints MUST implement at least one of the following and, if affordable, SHOULD implement both: the EdDSA signature algorithm together with the elliptic curve Ed25519 [RFC8032] and/or the ECDSA signature algorithm together with the elliptic curve P-256. ... Less constrained endpoints MUST implement at least one of the following ECDH curves and SHOULD implement both: the X25519 curve [RFC7748] and/or the P-256 curve. Constrained endpoints MUST implement at least one of the following ECDH curves and, if affordable, SHOULD implement both: the X25519 curve [RFC7748] and/or the P-256 curve. --> 13) <!-- [rfced] To match the expansion of "ACE" in RFC 9200, we have updated the text as follows. Please review and let us know of any objections. Original: One realization of a Group Manager is specified in [I-D.ietf-ace-key-groupcomm-oscore], where the process by which an endpoint (re-)joins a group is based on the ACE framework for authentication and authorization in constrained environments [RFC9200]. Current: One realization of a Group Manager is specified in [ACE-KEY-GROUP-OSCORE], where the process by which an endpoint (re-)joins a group is based on the Authentication and Authorization for Constrained Environments (ACE) framework [RFC9200]. --> 14) <!-- [rfced] FYI - We have rephrased the sentence below as follows for clarity. Please let us know any objections. Original: An endpoint may leave the group at own initiative, or may be evicted from the group by the Group Manager, e.g., in case the endpoint is compromised, or is suspected to be compromised (as determined by the Group Manager through its own means or based on information that it obtains from a trusted source such as an Intrusion Detection System or an issuer of authentication credentials). Current: An endpoint may leave the group on its own initiative or may be evicted from the group by the Group Manager, e.g., when the endpoint is compromised or is suspected to be compromised (as determined by the Group Manager through its own means or based on information that it obtains from a trusted source, such as an Intrusion Detection System or an issuer of authentication credentials). --> 15) <!-- [rfced] For clarity, may we update the sentence below as follows? Original: From the moment T_start when a Gid is assigned to a group until the moment when a new Gid is assigned to that same group, the following restrictions apply within the group. Perhaps: From the moment a Gid is assigned to a group (T_start) until the moment when a new Gid is assigned to that same group, the following restrictions apply within the group: --> 16) <!--[rfced] In Figure 4, may we update this bullet point for clarity as shown below? Original: * Changing a kid does not need changing the Group ID Perhaps: * When a kid is changed, the Group ID does not need to be changed --> 17) <!-- [rfced] May we rephrase the sentence below for easier readability? Original: This makes particular sense when the recipient is a client, that would hence be able to process incoming responses protected with the old retained Security Context used to protect the associated request. Perhaps: This makes particular sense when the recipient is a client, as it enables the client to process incoming responses protected with the old retained Security Context used for the associated request. --> 18) <!--[rfced] We updated this sentence and added parentheses for easier readability. Please let us know of any objections. Original: That is, other than over the ciphertext, the countersignature is computed over: the ID Context (Gid) and the Partial IV, which are always present in requests; as well as the Sender ID of the message originator, which is always present in requests as well as in responses to requests protected in group mode. Current: That is, in addition to the ciphertext, the countersignature is computed over the ID Context (Gid) and the Partial IV (both of which are always present in requests), as well as the Sender ID of the message originator (which is always present in requests and in responses to requests protected in group mode). --> 19) <!--[rfced] May we update this sentence by adding parentheses for easier readability? Current: Since the signing process also takes the ciphertext of the COSE_Encrypt0 object as input, the countersignature is bound not only to the intended OSCORE group, hence to the triplet (Master Secret, Master Salt, ID Context), but also to a specific Sender ID in that group and to its specific symmetric key used for AEAD encryption, hence to the quartet (Master Secret, Master Salt, ID Context, Sender ID). Perhaps: Since the signing process also takes the ciphertext of the COSE_Encrypt0 object as input, the countersignature is bound not only to the intended OSCORE group (represented by the triplet of Master Secret, Master Salt, and ID Context), but also to a specific Sender ID in that group and its specific symmetric AEAD key (represented by the quartet of Master Secret, Master Salt, ID Context, and Sender ID). --> 20) <!-- [rfced] May we update the sentence structure below as follows (specifically, "ECDH" to "ECDH-based")? Original: Applications using ECDH (except X25519 and X448) based KEM in Section 2.5 are assumed to verify that a peer endpoint's public key is on the expected curve and that the shared secret is not the point at infinity. Perhaps: Applications using ECDH-based (except X25519 and X448) KEM in Section 2.5 are assumed to verify that a peer endpoint's public key is on the expected curve and that the shared secret is not the point at infinity. --> 21) <!--[rfced] Is "listening to requests" correct, or should it be "listening for requests" or "listening for group requests"? Original: Note that a device sending a CoAP request to a CoAP group is not necessarily itself a member of that group: it is a member only if it also has a CoAP server endpoint listening to requests for this CoAP group, sent to the associated IP multicast address and port. Perhaps: Note that a device sending a CoAP request to a CoAP group is not necessarily a member of that group; it is a member only if it also has a CoAP server endpoint listening for group requests on the associated IP multicast address and port. --> 22) <!--[rfced] We note three instances of "are expected to possibly reply", which is confusing. Should it be "are expected to reply" or "might reply"? Please let us know how may we update for clarity. Note that we will also update "to provide" to "in order to provide" in the second paragraph for consistency. Original: Controlled units are expected to possibly reply back to the BACS issuing control commands, in order to report about the execution of the requested operation (e.g., OK, failure, error) and their current operational status. Devices receiving software and firmware updates are expected to possibly reply back, in order to provide a feedback about the execution of the update operation (e.g., OK, failure, error) and their current operational status. Devices receiving parameter and configuration updates are expected to possibly reply back, to provide a feedback about the execution of the update operation (e.g., OK, failure, error) and their current operational status. Perhaps: Controlled units are expected to reply to the BACS issuing control commands in order to report about the execution of the requested operation (e.g., OK, failure, or error) and their current operational status. Devices receiving software and firmware updates are expected to reply back in order to provide feedback about the execution of the update operation (e.g., OK, failure, or error) and their current operational status. Devices receiving parameter and configuration updates are expected to reply in order to provide feedback about the execution of the update operation (e.g., OK, failure, or error) and their current operational status. --> 23) <!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/ en/rfcxml-vocabulary#aside). --> 24) <!--[rfced] Please review each artwork element and let us know if any should be marked as sourcecode (or another element) instead. In addition, please consider whether the "type" attribute of any sourcecode element should be set and/or has been set correctly (note that we updated "CDDL" to "cddl" per the list below and added "cbor-diag" to the applicable figures in Sections 4.3.1 and 4.3.2). The current list of preferred values for "type" is available at https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> 25) <!-- [rfced] Abbreviations a) If there are no objections, we will update the abbreviations "Group ID" and "Gid" to "GID" for consistency according to the abbreviation listed on https://rpc-wiki.rfc-editor.org/doku.php?id=abbrev_list. b) FYI - We have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Additionally, we have removed repetitive abbreviation expansions throughout the document, e.g., Group Identifier (Gid). --> 26) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether the term "master" should be updated. Common replacements in the RFC Series include "primary", "main", "host", "leader", or "orchestrator". --> Thank you. Madison Church and Karen Moore RFC Production Center On Jul 17, 2026, at 3:49 PM, [email protected] wrote: *****IMPORTANT***** RFC Author(s): -------------- Your document has now entered Final Review (previously AUTH48). The document was edited in kramdown-rfc as part of the RPC pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). Final Review is being handled in GitHub as part of the GitHub pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test). Your document is available for review at: https://github.com/rfc-editor-drafts/FinalReview-rfc10021 Please do the following: a) accept your invitations to join the repo as collaborators. b) see the README for details on the Final Review process: https://github.com/rfc-editor-drafts/FinalReview-rfc10021/blob/Approved/README.md c) review the edits in the RPC-edits pull request: https://github.com/rfc-editor-drafts/FinalReview-rfc10021/pulls d) address the issues: https://github.com/rfc-editor-drafts/FinalReview-rfc10021/issues Once the content of the .md file is stable, we will convert it to .xml and provide the .html, .pdf, .txt, and .xml files for review. You and your coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Once the document has been reviewed and approved by all of the authors, it will be published as an RFC. If an author is no longer available, there are several remedies; see the Unavailable Authors section (https://authors.ietf.org/rfc-publication-process#unavailable-authors). Details on the status of your Final Review are here: https://queue.rfc-editor.org/final-review/rfc10021/ Please let us know if you have any questions. Thank you for your cooperation, RFC Production Center -------------------------------------- RFC 10021 (draft-ietf-core-oscore-groupcomm) Title : Group Object Security for Constrained RESTful Environments (Group OSCORE) Author(s) : M. Tiloca, G. Selander, F. Palombini, J. Preuß Mattsson, R. Höglund WG Chair(s) : Marco Tiloca, Jaime Jimenez, Carsten Bormann Area Director(s) : Mike Bishop, Gorry Fairhurst -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
