Original text:
'key', containing the keying material necessary for the group communication. <del> 'kty', identifying the key type of the key. </del>  The exact format of the 'key' value MUST be defined in applications of this specifications.  Additionally, documents specifying the key <del> format MUST register it in the "ACE Groupcomm Key" registry, defined in iana-key, and MUST register its type in the "ACE Groupcomm Key Type" registry, defined in </del>  Optionally, the Key Distribution Response MAY contain the following parameters, which, if included, MUST have the corresponding values: 9.1. <del> TODO </del>  <del> 9.2. </del>  <del> TODO </del>  <del> 9.3. </del>  This specification establishes the IANA "ACE Groupcomm Profile" registry.  The registry has been created to use the "Expert Review <del> Required" registration procedure RFC8126.  It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well. </del>  The columns of this registry are: Reference: This contains a pointer to the public specification of the profile abbreviation, if one exists. 

Reviewer comments:
Following URL and a chat at IETF103.
AP8: 'pubkeysrepos', as a CBOR array of tstr containing URIs. Hi Jim, Thanks a lot for your detailed review, as you might have seen we have included most comments in the latest version: URL Please note that this version includes also review comments from Peter, which in some cases overlapped, so some text might be reformulated to include both inputs. Inline, detailed comments and some questions. Thanks, Francesca Section 2 - client - write rights and/or read rights. Unless you think that write implies read in which case you should state that FP: Right, we now specify: " It can request write and/or read rights." Section 2 - KDC - should also say what it does in the later parts - FP: Ok, we added the following text: " During the second part (Section 4), which is not based on the ACE Framework, it distributes the keying material." We also added details about the role of the KDC for redistribution of keying material. Section 2 - Dispatcher - If this is a bus, then you are not really communicating with it securely. Anybody can write on it, but people will just ignore what comes out the other end. FP: Right, reformulated in " entity through which the Clients communicate with the group and which distributes messages to the group members." Section 3- A brief description of all of the operations would be appreciated. FP: we have now added several sections to describe the operations. In section 2 (starting with " This document specifies the message flows and formats for:") we describe the high level operations. At the beginning of each section (3. and 4.) we also give an overview of the exchange described in the subsections. Section 3.1 - Can I get authorization for multiple items at a single time? FP: In theory, it would be possible, and that would require to change the format of scope, going from [ group-id, [role1, role2] ] to [ [group-id1, group-id2], [[role1, role2], [role1]] ]. We haven't implemented this change, because it seems to cause a lot of overhead and complexity, for what seems to be a corner case. But if people think this is a valid use case, we can reconsider. We have added a placeholder comment in the md for this. Section 3.1 - Does it make sense to allow for multiple audiences to be on a single KDC? FP: I am not sure I understand the scenario, could you expand on this? (We have added a comment in the md for this as well) Section 4.x - cnf - text does not allow for key identifier FP: Did you get the section wrong? In 4.x we do not use cnf. In which section exactly would you send the kid in the cnf? That should be defined in the Ace framework (and params)... Section X.X - Define a new cnf method to hold the OSCORE context parameters - should it be a normal COSEKey or something new just to makes sure that it is different. FP: This is the same comment as in the OSCORE Profile. Again, I am not sure why we really need a new structure since COSEKey is general enough to transfer all the keying material, with the addition of the couple of new parameters defined. But if you think this is necessary, we can definitely change. Section 3.X - I am not sure if write or POST is a better answer for what the role being requested is. FP: Again, I don't understand this comment. We don't really define what one should use as role, write or POST are both possible. Section 4 - Should one talk about the ability to use OBSERVE as part of key distribution? FP: We added a comment as a placeholder for this in the md. Observe was just briefly mentioned before and not really elaborated. Although it would work, it seems not useful to have it together with a proper rekeying scheme where the KDC takes the initiative anyway. Section 4.x - I am having a hard time trying to figure out the difference between a group and a topic. The text does not always seem to distinguish these well. FP: It was our purpose to keep the text high level enough so that it would apply to both. Does that create any problem/confusion? Seciton 4.1 - POP on client key esp if bound to an identity (Note using it to access the KDC is one POP) FP: Now added the following text at the end of section 4.: " Note that proof-of-possession to bind the access token to the Client is performed by using the proof-of-possession key bound to the access token for establishing secure communication between the Client and the KDC." Section 4.2 - why not use the exp field from OAUTH in the response FP: the exp field from the AS in the response relates to the token. This exp relates to the keying material. Yes, when the token expires the keying material should expire (and that is specified e.g. in the OSCORE profile), but it could expire before/independently as well. Question - does somebody talk about doing key derivation for a new kid showing up and by the way where is the gid FP: It's in oscore-groupcomm that we describe how a new Recipient Context is derived. This document keeps a high livel perspective (so it does not talk about Gid), while in ace-oscoap-join we explain how the current Group ID is provided to a joining node (in the 'serverID' parameter of the COSE Key in the Join Response). Seciton 4.2 - if you are using profile, then you should return it FP: The Key distribution request and response, although inspired by ACE, do not use ACE, so "profile" is not really defined here. The profile is used in the first phase, between C - AS - KDC, and it is returned there. Introduction - introduce the concept of a key management protocol and point to some. Give some basic properties expected from one. FP: Some text was added at the end of the introduction: " If the application requires backward and forward security, updated keying material is generated and distributed to the group members (rekeying), when membership changes. A key management scheme performs the actual distribution of the updated keying material to the group. In particular, the key management scheme rekeys the current group members when a new node joins the group, and the remaining group members when a node leaves the group. This document provides a message format for group rekeying that allows to fulfill these requirements. Rekeying mechanisms can be based on [RFC2093], [RFC2094] and [RFC2627]." Section 5.2 - What is the message to leave - can I leave one scope but not another? Can I just give up a role? FP: We have now added a TBD: format of the message to leave the group placeholder in Section 5.2. We will address this in a future update. The leave is intended per group, so one scope at the time losing all the roles in that group. Giving up a single role while remaining in the group does not require any particular interaction with the GM. It's just sufficient to stop behaving as that role. Seciton 6.1 - assumes scopes are unique across all audiences. Or assumes that I look up the correct token - should have an argument about why this is possible so that people can implement it right FP: We already had the check for the access token for a first time key distribution. We have added the following text in section 6.2: "the KDC receiving a Key Re-Distribution Request MUST check that it is storing a valid Access Token from that client for that scope." We also have added a TODO: defines error response if it does not have it / is not valid. Would that be enough? Comment somewhere about getting strike zones setup correctly for a newly seen sender of messages. Ptr to OSCORE? FP: Sorry I don't understand what you mean by strike zones. Could you expand on that? Jim Ace mailing list EMAIL URL

Revised text:
'key', containing the keying material necessary for the group communication.  <ins> 'kty', identifying the key type of the key.  The set of values can be found in the Key Type column of the "ACE Groupcomm Key". Implementations MUST verify that the key type matches the profile being used, if present, as registered in the "ACE Groupcomm Key" registry. </ins> The exact format of the 'key' value MUST be defined in applications of this specifications.  Additionally, documents specifying the key  <ins> format MUST register it in the "ACE Groupcomm Key" registry, including its name, type and profile to be used with, as defined in the "ACE Groupcomm Key" registry, defined in iana-key. </ins> Optionally, the Key Distribution Response MAY contain the following parameters, which, if included, MUST have the corresponding values: 9.1.  <ins> This specification establishes the IANA "ACE Groupcomm Key" registry. The registry has been created to use the "Expert Review Required" registration procedure.  Expert review guidelines are provided in </ins>  <ins> The columns of this table are: </ins>  <ins> Name: This is a descriptive name that enables easier reference to the item.  The name MUST be unique.  It is not used in the encoding. </ins>  <ins> Key Type Value: This is the value used to identify the keying material.  These values MUST be unique.  The value can be a positive integer, a negative integer, or a string. Profile: This field may contain a descriptive string of a profile to be used with this item.  This should be a value that is in the Name column of the "ACE Groupcomm Profile" registry. Description: This field contains a brief description of the keying material. References: This contains a pointer to the public specification for the format of the keying material, if one exists. This registry has been initially populated by the values in kty.  The specification column for all of these entries will be this document. 9.2. </ins> This specification establishes the IANA "ACE Groupcomm Profile" registry.  The registry has been created to use the "Expert Review  <ins> Required" registration procedure RFC8126.  Expert review guidelines are provided in review.  It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well. </ins> The columns of this registry are: Reference: This contains a pointer to the public specification of the profile abbreviation, if one exists. <ins> 9.3. The IANA registry established in this document is defined as expert review.  This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude. Expert reviewers should take into consideration the following points: Point squatting should be discouraged.  Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as private use are intended for testing purposes and closed environments, code points in other ranges should not be assigned for testing. Specifications are required for the standards track range of point assignment.  Specifications should exist for specification required ranges, but early assignment before a specification is available is considered to be permissible.  Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. Experts should take into account the expected usage of fields when approving point assignment.  The fact that there is a range for standards track documents does not mean that a standards track document cannot have points assigned outside of that range.  The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size. </ins>