Re: [Ace] draft-ietf-ace-key-groupcomm-13

[Marco Tiloca <[e-mail]>]

Hi Cigdem,

Thanks for the follow-up feedback! I believe your points are now all 
captured in the Editor's copy on Github.

Please, find inline my replies to your four latest points, marked as " 
==>MT2".

Best,
/Marco

On 2021-10-11 17:36, Cigdem Sengul wrote:
> Hello Marco,
>
> Apologies for getting back to you late, I was/am snowed under at work.
> But I've also read through the previous interim discussion as well.
> In general, I think  everything is much clearer now.
> Some more comments inline, mostly OKing your suggestions (and removing 
> some previous ones where we are in agreement, and there is no feedback 
> sought).
> Kind regards,
> --Cigdem
>
>
> On Wed, Sep 1, 2021 at 9:27 PM Marco Tiloca <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Cigdem,
>
>     Thank you very much for your review! Please, find my replies
>     inline marked as "==>MT".
>
>     Best,
>     /Marco
>
>     On 2021-08-25 23:52, Cigdem Sengul wrote:
>>
>>     Hello,
>>     Here is also my review, as promised. I agree with Göran's
>>     comments and tried not to repeat them (but I realise I have the
>>     same concern about the presentation of Section 4 - more details
>>     below).
>>     *General comments:*
>>     The draft is quite thorough in providing details about how a
>>     node, as a participant of group communication, can get
>>     authorisation, join/get information about and leave the group,
>>     how a node can be removed, and how the key information is
>>     provided to protect the group communication. In the pub-sub
>>     draft, we take advantage of all these resources to secure pub-sub
>>     communication.
>>     In addition to some questions I have about resources (in my
>>     detailed comments), most of my comments are focused on improving
>>     the readability of the draft. As Göran also mentioned, after
>>     defining the available resources, it would be good to explain the
>>     flows and then give details of endpoints and examples. This way,
>>     it would be possible to understand first the primitives available
>>     for securing group communication, then have more detail important
>>     for the implementation.
>
>     ==>MT
>     I believe that the proposal to address this point in the review
>     from Göran [1][1reply] can help here too. I re-include it below
>     for convenience.
>
>     1) Merging the points from the bullet list of Section 4.0 into the
>     corresponding resource description of Section 4.1, while still
>     preserving the forward pointers. This can make it easier to map
>     between actions from a client point of view with resources at the
>     KDC, even though no details have been introduced yet.
>
>     2) Separately moving each Section 4.2-4.10 right after the
>     corresponding handler section, now numbered 4.1.x.y. After that, a
>     better structuring can also be achieved, so that:
>
>     - Section 4.1 is renamed "Overview of the Interface at the KDC".
>     - The following sections lose one numbering level, e.g. current
>     4.1.1 "ace-group" becomes 4.2 "ace-group".
>     - Each Section 4.x can be about a KDC resource. This in turn
>     includes 4.x.y with a handler description for resource x, followed
>     by 4.x.y.z with the example for handler y or resource x (taken
>     from current Sections 4.2-4.10).
>
>     That is:
>
>     4. Keying Material Provisioning and Group Membership Management
>
>     4.1 Overview of the Interface at the KDC
>
>     4.2 ace-group
>     4.2.1 FETCH handler
>     4.2.1.1 Example <Content from current Section 4.2>
>
>     4.3 ace-group/GROUPNAME
>     4.3.1 POST handler
>     4.3.1.1 Example <Content from current Section 4.3>
>     4.3.2 GET handler
>     4.3.1.1 Example <currently missing>
>
>     ...
>
>
>     How does it look?
>
>
>     [1]
>     https://mailarchive.ietf.org/arch/msg/ace/pr2gBhvqy9j8AfUdQVTZLwamXac/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Face%2Fpr2gBhvqy9j8AfUdQVTZLwamXac%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524510355%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sY%2Fi1al%2FDXzqr7JFhSJBU1P6WMogxGdeAhT8KoxpIT8%3D&reserved=0>
>
>     [1reply]
>     https://mailarchive.ietf.org/arch/msg/ace/dEU04pB3u-iYNBwSlfjJaqkEvgo/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Face%2FdEU04pB3u-iYNBwSlfjJaqkEvgo%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524520321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fjWpy921q1BNpx5ZwLMoFfGCGosc8r2yWMaM9SWPpsY%3D&reserved=0>
>
>     <==
>
>
> [CS: I think this would make things a lot more clear, yes.]
>
>
>>     Also,  reading the draft, it was first not clear how the rekeying
>>     was supported, whether it was a push/poll based solution, i.e.,
>>     whether the KDC pushes new keys or the group participants query
>>     for the new key information.  Both options are supported, but it
>>     would be nice to have one clear section on this with a
>>     recommendation (Sections 4.4 and 4.5 look like the main sections
>>     for this, but there are several instances throughout the text
>>     rekeying is mentioned.)
>
>     ==>MT
>     I think most of the useful content is in the bullet list in
>     Section 4.4. Instead, Section 4.5 is about renewing "individual
>     keying material" (e.g. an OSCORE Sender ID), and is not related to
>     the group rekeying.
>
>     Here's a possible way forward. We can introduce a new section
>     specific on group rekeying, with the alternatives from Section
>     4.4. Then, this section can be pointed by (at least) Sections 4.5,
>     5 and 9.1.
>
>     As to what can be recommended, I started to think of something
>     like the following:
>
>     - The KDC should make /ace-group/GROUPNAME observable, hence
>     supporting a distribution approach based on notifications.
>
>     - If the joining node does not plan to observe
>     /ace-group/GROUPNAME , the joining node MUST specify 'control_uri'
>     in the joining request.
>
>     - The KDC must support at least one push-based approach, minimally
>     a point-to-point one. More efficient alternatives, e.g. based on
>     multicast, remain possible.
>
>     - If the Group Manager rekeys the group members point-to-point,
>     the Group Manager sends the rekeying message to a certain group
>     member either as a notification (if the group member is registered
>     as an observer of /ace-group/GROUPNAME) or as a request to the
>     resource of the group member at 'control_uri' (if the group member
>     is not registered as an observer).
>
>        If neither of the two is possible (which means the group member
>     is not complying with the above), the group member would miss a
>     rekeying. Later on, after having failed to successfully exchange
>     secure messages with other peers in the group, the group member
>     will have to align itself in a pull fashion, by sending a GET
>     request to ace-group/GROUPNAME or ace-group/GROUPNAME/nodes/NODENAME.
>
>
>     What do you think?
>     <==
>
> [CS: I think combined with what you shared after the previous interim 
> meeting, it's getting a lot more clear how rekeying is supported, and 
> signaled to the group participants.]
>
>
>>     Finally, I've read the draft linearly and revised my comments if
>>     something I questioned was answered later; however, I've kept the
>>     comment to show where someone can be puzzled, and a forward
>>     pointer to the correct section may be appropriate. My comments
>>     are within [CS: ]. I hope you find them useful.
>
>     ==>MT
>     Thanks! Please, see also my replies in line.
>     <==
>
>>
>>     *Detailed comments:*
>>
>>
>>     ACE Working Group           F. Palombini
>>     Internet-Draft           Ericsson AB
>>     Intended status: Standards Track             M. Tiloca
>>     Expires: 13 January 2022               RISE AB
>>               12 July 2021
>>
>>
>>                Key Provisioning for Group Communication using ACE
>>     draft-ietf-ace-key-groupcomm-13
>>
>>
>>     [SNIP]
>>
>>     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
>>        described in
>>     [I-D.ietf-ace-oauth-authz][I-D.ietf-cose-rfc8152bis-stru
>>        ct][I-D.ietf-cose-rfc8152bis-algs], such as Authorization
>>     Server (AS)
>>        and Resource Server (RS).
>>
>>        This document uses names or identifiers for groups and nodes. 
>>     Their
>>        different meanings are summarized here:
>>
>>        *  "Group name" is the invariant once established identifier
>>     of the
>>           group.  It is used in the communication between AS, RS and
>>     Client
>>           to identify the group.
>>
>>     [CS: This has confused me earlier with the distinction of
>>     security and application
>>     group not being clear at the time. Would it be possible to
>>     emphasise this is a Security Group
>>     Name?]
>
>     ==>MT
>     Even better, we can add an earlier definition of "Group",
>     clarifying that it is a security group. Something like:
>
>     "Group: a set of nodes that share group keying material and
>     security parameters used to protect their communications. That is,
>     the term refers to a "security group". This is not to be confused
>     with an "application group", which has relevance at the
>     application level and whose members share a common pool of
>     resources or content."
>
>     It shouldn't be necessary to explicitly point to the definition of
>     "application group" and "security group" given in
>     draft-ietf-core-groupcomm-bis.
>     <==
>
> [CS: Excellent]
>
>>
>>     2.  Overview
>>
>>        The full procedure can be separated in two phases: the first one
>>        follows the ACE framework, between Client, AS and KDC; the
>>     second one
>>        is the key distribution between Client and KDC.  After the two
>>     phases
>>        are completed, the Client is able to participate in the group
>>        communication, via a Dispatcher entity.
>>
>>
>>            +------------+  +-----------+
>>            |     AS     |                  |  KDC    |
>>            |            |        .-------->|         |
>>            +------------+       /  +-----------+
>>                  ^             /
>>                  |            /
>>                  v           /       +-----------+
>>            +------------+   /      +------------+        |+-----------+
>>            |   Client   |<-'       | Dispatcher |        ||+-----------+
>>            |            |<-------->|    |<------->||   Group   |
>>            +------------+          +------------+         +|  members  |
>>              +-----------+
>>
>>                       Figure 1: Key Distribution Participants
>>
>>        The following participants (see Figure 1) take part in the
>>        authorization and key distribution.
>>
>>        *  Client (C): node that wants to join the group
>>     communication.  It
>>           can request write and/or read rights.
>>
>>        *  Authorization Server (AS): same as AS in the ACE Framework; it
>>           enforces access policies, and knows if a node is allowed to
>>     join a
>>           given group with write and/or read rights.
>>
>>        *  Key Distribution Center (KDC): maintains the keying material to
>>           protect group communications, and provides it to Clients
>>           authorized to join a given group. During the first part of the
>>           exchange (Section 3), it takes the role of the RS in the ACE
>>           Framework.  During the second part (Section 4), which is
>>     not based
>>           on the ACE Framework, it distributes the keying material.  In
>>           addition, it provides the latest keying material to group
>>     members
>>           when requested or, if required by the application, when
>>     membership
>>           changes.
>>
>>     [CS: It is not clear to me whether the KDC is programmed to rekey
>>     when membership
>>     changes or that needs to be invoked as a request from one of the
>>     group communication
>>     participants (which may have, say, a coordinator role). (Again,
>>     this is clarified later,
>>     but each time I saw it, it triggered the same question.)]
>
>     ==>MT
>     This will be clarified in a dedicated section about group rekeying
>     (see the comments at the beginning of this reply).
>
>     In short, a rekeying is started only by the KDC, due to different
>     possible reasons, and can be done through different distribution
>     approaches. There is no such thing like a "request for rekeying
>     the group".
>     <==
>
> [CS: +1]
>
>
>>
>>
>>
>>     Palombini & Tiloca       Expires 13 January 2022              
>>      [Page 5]
>>     
>>     Internet-Draft  Key Provisioning for Group Communication      
>>     July 2021
>>
>>
>>        *  Dispatcher: entity through which the Clients communicate
>>     with the
>>           group and which distributes messages to the group members.
>>           Examples of dispatchers are: the Broker node in a pub-sub
>>     setting;
>>           a relayer node for group communication that delivers group
>>           messages as multiple unicast messages to all group members; an
>>           implicit entity as in a multicast communication setting, where
>>           messages are transmitted to a multicast IP address and
>>     delivered
>>           on the transport channel.
>>
>>     [CS:Is a Dispatcher always needed? Clients initiating unicast
>>     messages to other
>>     group members directly p2p?]
>
>     ==>MT
>     That's a good point. We can clarify that the Dispatcher enforces
>     the distribution of a message intended to multiple recipients. A
>     single-recipient message (even though intended to another member
>     of the security/application group) can be reached by alternative,
>     more direct means.
>     <==
>
> [CS: +1]
>
>>
>>
>>     3.  Authorization to Join a Group
>>
>>       [SNIP]
>>
>>     3.1.  Authorization Request
>>
>>        The Authorization Request sent from the Client to the AS is
>>     defined
>>        in Section 5.8.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the
>>        following parameters, which, if included, MUST have the
>>     corresponding
>>        values:
>>
>>        *  'scope', containing the identifier of the specific groups, or
>>           topics in the case of pub-sub, that the Client wishes to
>>     access,
>>           and optionally the roles that the Client wishes to take.
>>
>>     [CS: I think we have to include that a pub-sub model may also
>>     group nodes
>>     based on something other than topics, even though we've written
>>     the pub-sub
>>     profile based on topic(or topic filter)-based group identifiers.
>>     Maybe this is
>>     better given just as an example?]
>
>     ==>MT
>     How about simply the following?
>
>     "'scope', containing the identifier of the specific groups, e.g.
>     of topics in the case of pub-sub, that ..."
>     <==
>
> [CS: Yes, that's great.]
>
>
>>
>>
>>     Palombini & Tiloca       Expires 13 January 2022              
>>      [Page 8]
>>     
>>     Internet-Draft  Key Provisioning for Group Communication      
>>     July 2021
>>
>>
>>           By default, each entry is encoded as specified by
>>           [I-D.ietf-ace-aif].  The object identifier Toid corresponds
>>     to the
>>           group name and MUST be encoded as a tstr.  The permission set
>>           Tperm indicates the roles that the client wishes to take in the
>>           group.  It is up to the application profiles to define Tperm
>>           (REQ2) and register Toid and Tperm to fit the use case.  An
>>           example of scope using the AIF format is given in Figure 4.
>>
>>           Otherwise, each scope entry can be defined as a CBOR array,
>>     which
>>           contains:
>>
>>     [CS: Two options. One recommended? (Though I see that this is
>>     better clarified
>>     below when explaining extended scope format and how KDC may
>>     support multiple...
>>     Maybe a forward reference?)]
>
>     ==>MT
>     I would recommend the option using AIF as more compact, but it
>     really depends on how important/necessary it is for the
>     application to have roles expressed in a compact way. I can see
>     that the pub-sub profile uses text strings for those.
>
>     Maybe it's just fine to do something like the following:
>
>     - Expand the paragraph above to mention that the default option
>     based on AIF allows for more compact scopes (since roles are
>     expressed in a more compact way), and thus is preferable for
>     application profiles that aim to achieve compact scopes,
>     especially if they define multiple possible roles and their
>     coexistence for a same node.
>
>     - Point to Section 6 as to the extended format for semantics
>     disambiguation. Note that this extension applies to a scope
>     encoded as a byte string (although beyond the scopes defined in
>     this document and its profiles), which is the case for both the
>     alternatives in Figure 4 and Figure 5, since the actual 'scope'
>     claim is encoded as a byte string in either case. This is also
>     evident from the examples in Figure 28 and Figure 29, respectively.
>     <==
>
> [CS: I think what you suggest would read fine.]
>
>
>>
>>           -  As first element, the identifier of the specific group or
>>              topic, encoded as a tstr.
>>
>>           -  Optionally, as second element, the role (or CBOR array of
>>              roles) that the Client wishes to take in the group.  This
>>              element is optional since roles may have been
>>     pre-assigned to
>>              the Client, as associated to its verifiable identity
>>              credentials.  Alternatively, the application may have
>>     defined a
>>              single, well-known role for the target resource(s) and
>>              audience(s).
>>
>>     [CS: What happens if a Client uses the option to select a role
>>     but mismatches what
>>     is pre-assigned. I expect it's overwritten with what's
>>     pre-programmed at the AS?
>>     Is there an error message for the mismatch? e.g., "Request
>>     inconsistent with the current roles"]
>
>     ==>MT
>     I think you mean that: a role A was configured as legitimate for
>     the Client on the AS; the Client asks for a token that grants role B.
>
>     In this case, the Client is simply not supposed to be authorized
>     to take role B. I would expect the AS to return an error response
>     with code "invalid_scope", i.e. "The requested scope is invalid,
>     unknown, malformed, or exceeds the scope granted by the resource
>     owner" (see Section 5.2 of RFC 6749).
>
>     Overall, this does not deviate from what defined in the ACE
>     framework, in its Sections 5.8.1-5.8.3. The Section 3.1 of this
>     document with the text quoted above is pointing to Section 5.8.1
>     of the ACE framework.
>     <==
>     [CS: Actually my comment was more for the text: " Optionally, as
>     second element, the role (or CBOR array of roles) that the Client
>     wishes to take in the group." as if the client can wish for a role
>     even if it is pre-assigned, and thought the return of an error in
>     this case should be explained in the text.]
>

==>MT2
Ok, there is no intention to admit a Client sending an Authorization 
Request to extend the access policies pre-configured on the AS by the 
Resource Owner. Rephrased as follows in order to avoid confusion:

In the section "Authorization Request"

OLD
... that the Client wishes to access, and optionally the roles that the 
Client wishes to take.

NEW
... that the Client requests to access, and optionally the roles that 
the Client requests to have in those groups.


In the section "Authorization Response"

OLD
The Authorization Response sent from the AS to the Client is defined in 
Section 5.8.2 of [I-D.ietf-ace-oauth-authz].

NEW
The AS processes the Authorization Request as defined in 
[I-D.ietf-ace-oauth-authz], especially verifying that the Client is 
authorized to access the specified groups with the requested roles, or 
possibly a subset of those. In case of successful verification, the 
Authorization Response sent from the AS to the Client is also defined in 
[I-D.ietf-ace-oauth-authz].
<==

>>
>>           In each entry, the encoding of the role identifiers is
>>     application
>>           specific, and part of the requirements for the application
>>     profile
>>           (REQ2).  In particular, the application profile may specify
>>     CBOR
>>           values to use for abbreviating role identifiers (OPT7).
>>
>>           An example of CDDL definition [RFC8610] of scope using the
>>     format
>>           above, with group name and role identifiers encoded as text
>>           strings is given in Figure 5.
>>
>>     [CS: is->are]
>
>     ==>MT
>     Isn't the subject "example" ? It can be anyway rephrased as
>     "Figure 5 provides an example of ..."
>     <==
>
> [CS: Ah, yes. I took it as "group name and role identifiers". Thanks 
> for rephrasing.]
>
>
>>
>>     3.3.  Token Post
>>
>>                         [Snip]
>>        The joining node MAY ask for this information from the KDC in the
>>        same message it uses to POST the token to the RS.  In such a case,
>>        the message MUST have Content-Format set to application/ace+cbor
>>        defined in Section 8.16 of [I-D.ietf-ace-oauth-authz].  The
>>     message
>>        payload MUST be formatted as a CBOR map, which MUST include the
>>        access token.  The CBOR map MAY additionally include the following
>>        parameter, which, if included, MUST have the corresponding values:
>>
>>        *  'sign_info' defined in Section 3.3.1, encoding the CBOR simple
>>           value Null to require information about the signature
>>     algorithm,
>>           signature algorithm parameters, signature key parameters and on
>>           the exact encoding of public keys used in the group.
>>
>>        Alternatively, the joining node may retrieve this information by
>>        other means.
>>     [CS: Reference to them?]
>
>     ==>MT
>     I can add a commented informative reference to
>     draft-tiloca-core-oscore-discovery.
>
>     That document is practically focused on the Group OSCORE case
>     covered by ace-key-groupcomm-oscore (where it is in fact referred
>     to), but the overall idea has general applicability to the
>     discovering of security groups where different protocols are used.
>     All in all, it's about discovering the links to join a security
>     group, along with attributes describing how the group works.
>
>     Beside that, "other means" can include pre-configuration or other
>     early discovery/learning processes that a group member would go
>     through before joining. I'm not sure what good, general references
>     about that can be added.
>     <==
>     [CS: OK thanks, otherwise "other means" is too vague, and does not
>     give any hints to what may be acceptable.]
>>
>>        After successful verification, the Client is authorized to receive
>>        the group keying material from the KDC and join the group.
>>
>>        The KDC replies to the Client with a 2.01 (Created) response,
>>     using
>>        Content-Format "application/ace+cbor".
>>
>>        The payload of the 2.01 response is a CBOR map.  If the access
>>     token
>>        contains a role that requires the Client to send its own
>>     public key
>>        to the KDC when joining the group, the CBOR map MUST include the
>>        parameter 'kdcchallenge' defined in Section 3.3.2, specifying a
>>        dedicated challenge N_S generated by the KDC.  The Client uses
>>     this
>>        challenge to prove possession of its own private key (see the
>>        'client_cred_verify' parameter in Section 4).  Note that the
>>     payload
>>        format of the response deviates from the one defined in the ACE
>>        framework (see Section 5.10.1 of [I-D.ietf-ace-oauth-authz]),
>>     which
>>        has no payload.
>>
>>        The KDC MUST store the 'kdcchallenge' value associated to the
>>     Client
>>        at least until it receives a join request from it (see Section
>>     4.3),
>>        to be able to verify that the Client possesses its own private
>>     key.
>>
>>     [CS: OK, just to clarify? the kdcchallenge is generated and
>>     returned in the Authorisation
>>     response, and the client uses it to prove ownership of public key
>>     on join request.
>>     It may be useful to specify more clearly when the challenge
>>     parameter is used.
>>     (This is clarified much later; I feel explaining the possible
>>     flows using the resources
>>     beforehand would be better, as I comment later as well.]
>
>     ==>MT
>     'kdcchallenge' is included in the response to the Token posting
>     (the Authorization Response is part of the earlier exchange with
>     the AS).
>
>     The paragraph above can explicitly mention the later Joining
>     Request, and that N_S is used as part of a PoP input to compute
>     the PoP evidence.
>     <==
>
> [CS: +1]
>
>
>>
>>        The same challenge MAY be reused several times by the Client, to
>>        generate a new proof of possession, e.g., in case of update of the
>>
>>
>>
>>     Palombini & Tiloca       Expires 13 January 2022              
>>     [Page 12]
>>     
>>     Internet-Draft  Key Provisioning for Group Communication      
>>     July 2021
>>
>>
>>        public key, or to join a different group with a different signing
>>        key, so it is RECOMMENDED that the KDC keeps storing the
>>        'kdcchallenge' after the first join is processed as well.  If
>>     the KDC
>>        has already discarded the 'kdcchallenge', that will trigger an
>>     error
>>        response with a newly generated 'kdcchallenge' that the Client can
>>        use to restart the join process, as specified in Section 4.3.
>>
>>        If 'sign_info' is included in the request, the KDC MAY include the
>>        'sign_info' parameter defined in Section 3.3.1, with the same
>>        encoding.  Note that the field 'id' takes the value of the
>>     group name
>>        for which the 'sign_info_entry' applies to.
>>
>>     [CS: This MAY mean that even if the client has sign_info, the KDC
>>     may not return this information? What's the reason for this?]
>
>     ==>MT
>     A possible reason is that the group indicated in the token does
>     not use signatures to ensure source authentication. The client
>     doesn't know that and just uses 'sign_info' as usual in its
>     request. In that case, the KDC has nothing to say about
>     'sign_info'. Also, it is up to the application profile and its
>     associated secure group communication protocol to have already
>     defined alternative means to achieve source authentication in the
>     group. This will be clarified better.
>
>     A case in point is in ace-key-groupcomm-oscore , when a group uses
>     only the pairwise mode of Group OSCORE. In that "extreme" but
>     possible case, communication among group members occurs only
>     one-to-one, and source communication is achieved by pairwise
>     symmetric encryption keys. These are in turn derived from the
>     group key material and the asymmetric keys of the two peers in
>     question. Hence, there is no set of information to convey with
>     'sign_info', while other specific parameters defined in
>     ace-key-groupcomm-oscore transport information required to perform
>     those operations (e.g. algorithms and parameters).
>     <==
>
> [CS: With this explanation, it's more clear]
>
>
>>     [Snip]
>>
>>
>>     3.3.1.  'sign_info' Parameter
>>
>>     [CS: It is confusing to read about sign_info in two places (in
>>     the previous section and this section). Maybe defer
>>     all sign_info -related information to this section?]
>
>     ==>MT
>     I've seen it as a common practice to have a parameter defined in a
>     dedicated section, here Section 3.3.1, so that its definition
>     abstracting from any particular use can be referred by possible
>     other documents or by IANA registrations. The intent here is to
>     define a new parameter first of all for OAuth and ACE (see the
>     later registrations in Sections 10.3 and 10.4).
>
>     The previous Section 3.3.0 defines the specific use of 'sign_info'
>     in this document, consistent with the general definition.
>
>     Does it make sense?
>     <==
>
> [CS: OK]
>
>
>>
>>     [SNIP]
>>
>>
>>     3.3.2.  'kdcchallenge' Parameter
>>     [CS: The same comment as above, either explained here or above...
>>     Otherwise
>>     repetitious]
>
>     ==>MT
>     See the comment above about 'sign_info'.
>     <==
>
> [CS: OK. ]
>
>
>>     [SNIP]
>>
>>     4.  Keying Material Provisioning and Group Membership Management
>>
>>     [SNIP]
>>
>>
>>     4.1.  Interface at the KDC
>>
>>        The KDC is configured with the following resources.  Note that the
>>        root url-path "ace-group" given here are default names:
>>        implementations are not required to use these names, and can
>>     define
>>        their own instead.  Each application profile of this specification
>>        MUST register a Resource Type for the root url-path (REQ7),
>>     and that
>>        Resource Type can be used to discover the correct url to access at
>>        the KDC.  This Resource Type can also be used at the GROUPNAME
>>     sub-
>>        resource, to indicate different application profiles for different
>>        groups.  The Interface Description (if=) Link Target Attribute
>>     value
>>        ace.group is registered (Section 10.10) and can be used to
>>     describe
>>        this interface.
>>
>>        *  /ace-group: this resource is invariant once established and
>>           indicates that this specification is used.  If other
>>     applications
>>           run on a KDC implementing this specification and use this same
>>           resource, these applications will collide, and a mechanism
>>     will be
>>           needed to differentiate the endpoints. This resource
>>     supports the
>>           FETCH method.
>>
>>        *  /ace-group/GROUPNAME: one sub-resource to /ace-group is
>>           implemented for each group the KDC manages.
>>
>>           If the value of the GROUPNAME URI path and the group name
>>     in the
>>           access token scope ('gname' in Section 3.2) do not match,
>>     the KDC
>>           MUST implement a mechanism to map the GROUPNAME value in
>>     the URI
>>           to the group name, in order to retrieve the right group (REQ1).
>>
>>     [CS: While I understand the purpose of the statement above,
>>     it reads confusing.
>>     What if the mismatch is an error? E.g., the wrong token is provided
>>     for the call, and it should be not authorised, no?]
>
>     ==>MT
>     Well, if the token was found valid and stored, the KDC grants
>     access to /ace-group/GROUPNAME , where GROUPNAME is the result of
>     the (possibly identity-)mapping from gname.
>
>     At the same time, the Client has to target the correct URI
>     /ace-group/GROUPNAME . This does not require the Client to be
>     aware of the exact gname -> GROUPNAME mapping performed by the
>     KDC, but just to know the right URI (which is up to a separate
>     discovering/learning task).
>
>     If the mismatch is an actual mistake, meaning the Client uses a
>     wrong URI for the group gname, the KDC will reply with an error
>     response as per the ACE framework, in this case returning a 4.03
>     (Forbidden), see Section 5.10.2 of the ACE framework document.
>
>     Do you think it is worth to include these clarifications?
>     <==
>
> [CS: OK, but it was not clear to me why KDC would want to keep an 
> alternative naming. I think without understanding that, it felt 
> awkward to
> read that KDC MUST implement the mapping.]

==>MT2
The word "match" is probably the source of confusion here. Now rephrased 
as below. Admitting an alternative naming was an early design choice to 
simply allow flexibility.

OLD
If the value of the GROUPNAME URI path and the group name in the access 
token scope ('gname' in Section 3.2) do not match, the KDC MUST 
implement ...

NEW
If the value of the GROUPNAME URI path and the group name in the access 
token scope ('gname' in Section 3.2) are not required to coincide, the 
KDC MUST implement ...
<==

>
>>
>>           Each resource contains the symmetric group keying material for
>>           that group.  These resources support the GET and POST methods.
>>
>>        *  /ace-group/GROUPNAME/pub-key: this resource is invariant once
>>           established and contains the public keys of all group members.
>>           This resource supports the GET and FETCH methods.
>>
>>     [CS: All group members do not need to have public keys, e.g., For
>>     pub-sub, its only publishers]
>
>     ==>MT
>     Right, this is also related to another comment in the review from
>     Göran. Some particular group members, e.g. depending on their
>     role, may have no use of some resources. This means they will not
>     send requests to those resources.
>
>     On the other hand, the KDC provides such resources and an
>     interface to access them for the group members for which it makes
>     sense. It's probably up to an application profile to clarify that
>     the interaction to a particular resource is not expected/relevant
>     by particular group members.
>     <==
>
> [CS: OK]
>
>
>>
>>        *  /ace-group/GROUPNAME/policies: this resource is invariant once
>>           established and contains the group policies.  This resource
>>           supports the GET method.
>>
>>
>>     Palombini & Tiloca       Expires 13 January 2022              
>>     [Page 17]
>>     
>>     Internet-Draft  Key Provisioning for Group Communication      
>>     July 2021
>>
>>
>>        *  /ace-group/GROUPNAME/num: this resource is invariant once
>>           established and contains the version number for the symmetric
>>           group keying material.  This sub-resource supports the GET
>>     method.
>>
>>        *  /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace-
>>           group/GROUPNAME is implemented for each node in the group
>>     the KDC
>>           manages.  These resources are identified by the node name
>>     (in this
>>           example, the node name has value NODENAME).  Each resource
>>           contains the group and individual keying material for that
>>     node.
>>           These resources support the GET, PUT and DELETE methods.
>>
>>        *  /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one
>>     sub-resource to
>>           /ace-group/GROUPNAME/nodes/NODENAME is implemented for each
>>     node
>>           in the group the KDC manages.  These resources are
>>     identified by
>>           the node name (in this example, the node name has value
>>     NODENAME).
>>           Each resource contains the individual public keying
>>     material for
>>           that node.  These resources support the POST method.
>>     [CS: It also supports FETCH and GET, as detailed later?]
>
>     ==>MT
>     No, this resource supports only POST requests, for the node with
>     name NODENAME to provide a new public key of its own.
>
>     The resource related to public keys as supporting both GET and
>     FETCH requests is rather /ace-group/GROUPNAME/pub-key . This is
>     not individually associated to a group member, and it is
>     accessible by any group member to retrieve the public keys now
>     used in the group.
>     <==
>
> [CS: OK, makes sense - i missed the Uri difference]
>
>
>>
>>        It is REQUIRED of the application profiles of this
>>     specification to
>>        define what operations (e.g., CoAP methods) are allowed on each
>>        resource, for each role defined in Section 3.1 according to REQ2
>>        (REQ8).
>>
>>     [CS: Just to clarify again, this spec supports the above detailed
>>     operations,
>>     and it is REQUIRED that the profile, which uses this profile,
>>     further constrains the operations
>>     and who is allowed to access. And the access may not be based on
>>     only role, e.g.
>>     NODENAME may be able to PUT under nodes/NODENAME?]
>
>     ==>MT
>     The idea was that in every application profile the KDC supports
>     all these operations. At the same time, I can imagine that an
>     application profile really not needing some functionalities may
>     just declare some of the KDC resources not relevant and not have
>     them altogether. Also, the KDC of an application profile may add
>     new resources to provide additional functionalities.
>
>     Taking the perspective of a group member:
>
>     - It is already intended that a node with name NODENAME can access
>     only node-based sub-resources exactly under nodes/NODENAME. That
>     is, it cannot access node-based sub-resources of another node.
>     This is ensured by the consistency checks in the handlers of those
>     resources (see, for instance, Section 4.1.6.1).
>
>     - The quoted sentence and REQ8 require application profiles to
>     further define/limit the access to the KDC resources, based on the
>     role that a node trying to access that resource has in the group.
>     In ace-key-groupcomm-oscore , this requirement is fulfilled in its
>     Section 5.5 by means of Figure 2.
>     <==
>
> [CS: OK]
>
>>
>>        [SNIP]
>>
>>
>>     Palombini & Tiloca       Expires 13 January 2022              
>>     [Page 19]
>>     
>>     Internet-Draft  Key Provisioning for Group Communication      
>>     July 2021
>>
>>
>>        *  'scope', with value the specific resource at the KDC that the
>>           Client is authorized to access, i.e., group or topic name, and
>>           role(s).  This value is a CBOR byte string wrapping one scope
>>           entry, as defined in Section 3.1.
>>
>>        *  'get_pub_keys', if the Client wishes to receive the public
>>     keys of
>>           the other nodes in the group from the KDC.  This parameter
>>     may be
>>           present if the KDC stores the public keys of the nodes in the
>>           group and distributes them to the Client; it is useless to have
>>           here if the set of public keys of the members of the group is
>>           known in another way, e.g., it was provided by the AS. 
>>     Note that
>>           including this parameter may result in a large message size for
>>           the following response, which can be inconvenient for resource-
>>           constrained devices.
>>
>>           The parameter's value is either the CBOR simple value Null,
>>     or a
>>           non-empty CBOR array containing the following three elements.
>>
>>           -  The first element, namely 'inclusion_flag', encodes the CBOR
>>              simple value True.
>>
>>     [CS: Maybe explained what this flag signifies, as I see it's true by
>>     default for this handler, and may not be for other handlers (It's
>>     explained
>>     much later)]
>
>     ==>MT
>     Sure, will do. For example, some explanation can be moved up from
>     the later paragraph "Also note that the array of node identifiers ..."
>     <==
>
> [CS: +1]
>
>>     [SNIP]
>>
>>     Palombini & Tiloca       Expires 13 January 2022              
>>     [Page 20]
>>     
>>     Internet-Draft  Key Provisioning for Group Communication      
>>     July 2021
>>
>>        [SNIP]
>>
>>
>>
>>        *  'control_uri', with value a full URI, encoded as a CBOR text
>>           string.  If 'control_uri' is supported by the Client, the
>>     Client
>>           acts as a CoAP server and hosts a resource at this specific
>>     URI.
>>           The KDC MAY use this URI to send CoAP requests to the Client
>>           (acting as CoAP server in this exchange), for example for
>>           individual provisioning of new keying material when
>>     performing a
>>           group rekeying (see Section 4.4), or to inform the Client
>>     of its
>>           removal from the group Section 5.
>>
>>     [CS: So the above are KDC initiated? I think it needs to be
>>     clarified what
>>     mechanisms are expected to be initiated by KDC. If this uri is
>>     not present,
>>     how does the KDC rekey?]
>
>     ==>MT
>     See the proposal in one of the comments at the beginning of the
>     review. Some key points are restated here:
>
>     - Yes, the rekeying is initiated by the KDC (due to possibly
>     different reasons) and it's not something that can be requested.
>     There will be a new dedicated section on the possible approaches
>     for the actual distribution.
>
>     - An alternative to sending requests to the member's resource at
>     'control_uri' is to rely on observe notifications. A group member
>     not wishing to observe must provide 'control_uri' in the Joining
>     Request.
>     <==
>
> [CS: OK - this is fine as proposed to be described.]
>
>>
>>     [SNIP]
>>
>>        If an eligible public key for the Client is neither present in the
>>        'client_cred' field nor already stored, it is RECOMMENDED that the
>>        handler stops the processing and responds with a 4.00 (Bad
>>     Request)
>>        error message.  Applications profiles MAY define alternatives
>>     (OPT6).
>>
>>        If all the verifications above succeed, the handler performs the
>>        following actions.
>>
>>        *  The handler adds the Client to the list of current members
>>     of the
>>           group.
>>
>>        *  The handler assigns a name identifier NODENAME to the
>>     Client, and
>>           creates a sub-resource to /ace-group/GROUPNAME/ at the KDC
>>     (e.g.,
>>           "/ace-group/GROUPNAME/nodes/NODENAME").
>>
>>        *  The handler associates the node identifier NODENAME to the
>>     access
>>           token and the secure session for the Client.
>>
>>        *  If the KDC manages the group members' public keys:
>>
>>           -  The handler associates the retrieved Client's public key
>>     to the
>>              node identifier NODENAME and to the access token.
>>
>>     [CS: shouldn't this be better  - (nodename, groupname,
>>     accesstoken, public key),
>>     or my assumption is invalid, one public key per client, not per
>>     group?]
>
>     ==>MT
>     Yes, you're right, and as you say, a public key is indeed possibly
>     used by the same client in multiple groups, as per the previous
>     comment. So, the same access token that possibly grants access to
>     multiple groups might end up being associated to the different
>     involved public keys of the node.
>
>     The missing link to groupname will be made explicit. That was the
>     intent, though perhaps carried out too concisely in the
>     immediately following paragraph here below, where the public key
>     used by the client in the group is added to the overall set of
>     public keys in the group.
>     <==
>
> [CS: OK]
>
>
>>
>>
>>
>>     [SNIP]
>>
>>
>>        *  'group_policies', with value a CBOR map, whose entries
>>     specify how
>>           the group handles specific management aspects.  These
>>     include, for
>>           instance, approaches to achieve synchronization of sequence
>>           numbers among group members.  The elements of this field are
>>           registered in the "ACE Groupcomm Policy" Registry.  This
>>           specification defines the three elements "Sequence Number
>>           Synchronization Method", "Key Update Check Interval" and
>>           "Expiration Delta", which are summarized in Figure 9. 
>>     Application
>>           profiles that build on this document MUST specify the exact
>>           content format and default value of included map entries
>>     (REQ17).
>>
>>     [CS: So these MUST be specified, but I am still unclear whether
>>     Key updates
>>     are push/poll based, e.g., there are places where it reads like
>>     it is KDC initiated.
>>     So, key update check interval is 0, for example, if it's always
>>     push-based?]
>
>     ==>MT
>     The inclusion of this parameter is optional in the Joining
>     Response, but profiles must specify details about its single
>     information elements, for the case when the parameter is included.
>
>     On the group rekeying in general, please see earlier replies to
>     comments in this review.
>
>     About "Key Update Check Interval", that's related to a poll-based
>     action for group members to perform, but it does not trigger a
>     rekeying. By polling the KDC at most every  Key Update Check
>     Interval seconds, a group member can regularly check whether it
>     has the current group key material or it has rather missed an
>     earlier group rekeying.
>
>     Note that the actual check is not necessarily a GET to
>     /ace-group/GROUPNAME or /ace-group/GROUPNAME/nodes/NODENAME , or
>     at least not right away. Instead, it can be a GET to
>     /ace-group/num , followed by querying one of the resources above
>     only in case the response specifies a key material version
>     different than the version of the key material owned by the group
>     member.
>     <==
>     [CS: OK - I think this will be a lot more clear with the new
>     explanations on rekeying.]
>>
>>
>>     Palombini & Tiloca       Expires 13 January 2022              
>>     [Page 27]
>>     
>>     Internet-Draft  Key Provisioning for Group Communication      
>>     July 2021
>>
>>
>>     +--------------+-------+----------|---------------------|------------+
>>       |      Name    | CBOR  |   CBOR   |  Description      |
>>     Reference  |
>>       |              | label |   type   |             |            |
>>     |--------------+-------+----------|---------------------|------------|
>>       | Sequence     | TBD1  | tstr/int | Method for a re-    |
>>     [[this     |
>>       | Number       |       |          | cipient node to     |
>>     document]] |
>>       | Synchroniza- |       |          | synchronize with    |      
>>          |
>>       | tion Method  |       |          | sequence numbers    |      
>>          |
>>       |              |       |          | of a sender node.   |      
>>          |
>>       |              |       |          | Its value is taken  |      
>>          |
>>       |              |       |          | from the 'Value'    |      
>>          |
>>       |              |       |          | column of the       |      
>>          |
>>       |              |       |          | Sequence Number     |      
>>          |
>>       |              |       |          | Synchronization     |      
>>          |
>>       |              |       |          | Method registry     |      
>>          |
>>       |              |       |          |             |            |
>>       | Key Update   | TBD2  |   int    | Polling interval    |
>>     [[this     |
>>       | Check        |       |          | in seconds, to      |
>>     document]] |
>>       | Interval     |       |          | check for new       |      
>>          |
>>       |              |       |          | keying material at  |      
>>          |
>>       |              |       |          | the KDC             |      
>>          |
>>       |              |       |          |             |            |
>>       | Expiration   | TBD3  |   uint   | Number of seconds   |
>>     [[this     |
>>       | Delta        |       |          | from 'exp' until    |
>>     document]] |
>>       |              |       |          | the specified UTC   |      
>>          |
>>       |              |       |          | date/time after     |      
>>          |
>>       |              |       |          | which group members |      
>>          |
>>       |              |       |          | MUST stop using the |      
>>          |
>>       |              |       |          | keying material to  |      
>>          |
>>       |              |       |          | verify incoming     |      
>>          |
>>       |              |       |          | messages.           |      
>>          |
>>     +--------------+-------+----------|---------------------|------------+
>>
>>                          Figure 9: ACE Groupcomm Policies
>>
>>        *  'mgt_key_material', encoded as a CBOR byte string and
>>     containing
>>           the administrative keying material to participate in the group
>>           rekeying performed by the KDC.  The application profile MUST
>>           define if this field is used, and if used then MUST specify the
>>           exact format and content which depend on the specific rekeying
>>           scheme used in the group.  If the usage of
>>     'mgt_key_material' is
>>           indicated and its format defined for a specific key management
>>           scheme, that format must explicitly indicate the key management
>>           scheme itself.  If a new rekeying scheme is defined to be
>>     used for
>>           an existing 'mgt_key_material' in an existing profile, then
>>     that
>>           profile will have to be updated accordingly, especially with
>>           respect to the usage of 'mgt_key_material' related format and
>>           content (REQ22).
>>
>>     [CS: so, there is an implicit admin group, which can receive this
>>     information.
>>     I assume this is pre-assigned, or is it in the token scope?]
>
>     ==>MT
>     This kind of admin group would work according to the specifically
>     used group key management scheme. Below I reuse some responses to
>     two related points from Göran's review [1][1reply]:
>
>     * For example, if a hierarchy-based scheme is used, the parameter
>     specifies the administrative keys in the key tree from the leaf
>     node associated to the group member all the way up along the path
>     from that leaf node to the root (which is the administrative group
>     key).
>
>     * When joining the group, a node also needs to know the exactly
>     used group rekeying scheme. The easiest way I see to signal it is
>     defining one more integer-valued ACE Groupcomm Policy (see Figure
>     9 in Section 4.1.2.1) to be specified in the optional
>     'group_policies' parameter of the Joining Response.
>
>        Its value would indicate the exact rekeying scheme (and we
>     would need a new IANA registry). If the KDC does not say anything
>     about that, the joining node assumes that a group rekeying is
>     performed point-to-point, thus relying on the pairwise
>     communication channel it has with the KDC.
>
>
>     [1]
>     https://mailarchive.ietf.org/arch/msg/ace/pr2gBhvqy9j8AfUdQVTZLwamXac/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Face%2Fpr2gBhvqy9j8AfUdQVTZLwamXac%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524520321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6B23EfdqDXlQ9rm2hP7SuPuC8624jC8mAIw2BLh31Zo%3D&reserved=0>
>
>     [1reply]
>     https://mailarchive.ietf.org/arch/msg/ace/dEU04pB3u-iYNBwSlfjJaqkEvgo/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Face%2FdEU04pB3u-iYNBwSlfjJaqkEvgo%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524530272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xYmUL5Sw4Zkx3nUnDyahSX%2BT%2FZ8YMlTYMqwUAWUCpsE%3D&reserved=0>
>
>
>     Furthermore, the token scope does not need to cover this. The
>     "admin group" associated to the administrative key material is
>     exclusively tight to the main security group to be rekeyed by
>     using such key material. Also, the KDC as such is the entity
>     authorized and capable to rekey the main security group, while
>     there is no additional authorization needed to allow group members
>     to participate in a rekeying instance.
>     <==
>     [CS: This sounds all fine.]
>>
>>
>>     4.1.3.1.  FETCH Handler
>>
>>        The FETCH handler receives identifiers of group members for
>>     the group
>>        identified by GROUPNAME and returns the public keys of such group
>>        members.
>>
>>        The handler expects a request with payload formatted as a CBOR
>>     map,
>>        that MUST contain the following fields:
>>
>>        *  'get_pub_keys', whose value is encoded as in Section
>>     4.1.2.1 with
>>           the following modification:
>>
>>           -  The element 'inclusion_flag' encodes the CBOR simple
>>     value True
>>              if the third element 'id_filter' specifies an empty CBOR
>>     array,
>>              or if the Client wishes to receive the public keys of
>>     the nodes
>>              having their node identifier specified in 'id_filter'.
>>              Instead, this element encodes the CBOR simple value False if
>>              the Client wishes to receive the public keys of the
>>     nodes not
>>              having the node identifiers specified in the third element
>>              'id_filter'.
>>
>>     [CS: so, to clarify, id_filter becomes an exclusion list if
>>     inclusion_flag is false?
>>     if it is true, and id_filter is not empty, it returns the
>>     pub_keys in the list, i.e.,
>>     inclusion list? (Reading further, this seems correct. It may be
>>     explained earlier when
>>     inclusion_flag is first introduced]
>
>     ==>MT
>     Yes, that's a correct summary. We will fully define the meaning of
>     'inclusion_flag' when introducing it in Section 4.1.2.1.
>     <==
>
> [CS: +1]
>
>
>>
>>           -  The array 'role_filter' may be empty, if the Client does not
>>              wish to filter the requested public keys based on the
>>     roles of
>>              the group members.
>>
>>           -  The array 'id_filter' contains zero or more node
>>     identifiers of
>>              group members, for the group identified by GROUPNAME.  The
>>              Client indicates that it wishes to receive the public
>>     keys of
>>              the nodes having or not having these node identifiers,
>>     in case
>>              the 'inclusion_flag' parameter encodes the CBOR simple value
>>              True or False, respectively.  The array may be empty, if the
>>              Client does not wish to filter the requested public keys
>>     based
>>              on the node identifiers of the group members.
>>
>>        Note that, in case both the 'role_filter' array and the
>>     'id_filter'
>>        array are not empty:
>>
>>        *  If the 'inclusion_flag' encodes the CBOR simple value True, the
>>           handler returns the public keys of group members whose
>>     roles match
>>           with 'role_filter' and/or having their node identifier
>>     specified
>>           in 'id_filter'.
>>
>>        *  If the 'inclusion_flag' encodes the CBOR simple value
>>     False, the
>>           handler returns the public keys of group members whose
>>     roles match
>>           with 'role_filter' and, at the same time, not having their node
>>           identifier specified in 'id_filter'.
>>
>>     Palombini & Tiloca       Expires 13 January 2022              
>>     [Page 30]
>>     
>>     Internet-Draft  Key Provisioning for Group Communication      
>>     July 2021
>>
>>
>>        Finally, as mentioned in Section 4.1.2.1, both arrays
>>     'role_filter'
>>        and 'id_filter' MUST NOT be both empty.
>>
>>     [CS: Why? Can't I ask to get all the public keys of nodes in this
>>     group,
>>     which has a public key? (I see that this is a GET request, on
>>     reading further,
>>     a forward pointer here?)]
>
>     ==>MT
>     Yes, we'll include a forward pointer to the GET handler for
>     retrieving all public keys.
>     <==
>
> [CS: Thanks]
>
>
>>
>>       [SNIP]
>>
>>        The handler MAY enforce one of the following policies, in order to
>>        handle possible node identifiers that are included in the
>>     'id_filter'
>>        element of the 'get_pub_keys' parameter of the request but are not
>>        associated to any current group member. Such a policy MUST be
>>        specified by the application profile (REQ16).
>>
>>        *  The KDC silently ignores those node identifiers.
>>
>>        *  The KDC retains public keys of group members for a given
>>     amount of
>>           time after their leaving, before discarding them.  As long
>>     as such
>>           public keys are retained, the KDC provides them to a requesting
>>           Client.
>>
>>     [CS: I think this is a wider policy e.g., how long does the KDC
>>     retain
>>     any information about the historical group members?]
>
>     ==>MT
>     If I understand correctly, you'd like a policy of this kind to
>     explicitly define also how the retention time is determined,
>     possibly on a per-node basis. Correct?
>     <==
>
> [CS: Yes, I suggest that KDC says what that "given amount of time" is 
> - it could be uniform across group members, or per-node basis.]

==>MT2
The paragraph describing the second policy has been expanded with the 
following new sentence.

"If the KDC adopts this policy, the application profile MUST also 
specify the amount of time during which the KDC retains the public key 
of a former group member after its leaving, possibly according to a 
per-member basis."
<==

>
>>
>>     4.1.5.  ace-group/GROUPNAME/num
>>
>>        This resource implements a GET handler.
>>
>>     4.1.5.1.  GET Handler
>>
>>        The handler expects a GET request.
>>
>>      [SNIP]
>>     [CS: In general, in the SNIPPED text above, there is much repetition
>>     across different sections, in terms of format expected, group
>>     membership
>>     access control etc. Could that be said only once to apply to all
>>     resources, or
>>     all operations within a resource?]
>
>     ==>MT
>     Hopefully so :-)
>
>     I'll try to identify a clear "boilerplate" with actions common to
>     all handlers to include once and for all.
>     <==
>
> [CS: That would be great]
>
>
>>
>>     [SNIP]
>>
>>     4.1.6.  ace-group/GROUPNAME/nodes/NODENAME
>>
>>        This resource implements GET, PUT and DELETE handlers.
>>
>>     4.1.6.1.  PUT Handler
>>     The PUT handler is used to get the KDC to produce and return
>>        individual keying material to protect outgoing messages for
>>     the node
>>        (identified by NODENAME) for the group identified by GROUPNAME.
>>        Application profiles MAY also use this handler to rekey the whole
>>        group.  It is up to the application profiles to specify if this
>>        handler supports renewal of individual keying material, renewal of
>>        the group keying material or both (OPT8).
>>
>>     [CS: I am a bit puzzled that something that potentially is rekeying
>>     the whole group is done under NODENAME resource.
>>     On the other hand, POSTing the GROUPNAME adds a node to the group
>>     rather than rekeying
>>     the group. I would expect POSTing to ace-group/GROUPNAME/nodes
>>     would add
>>     a node instead.
>>     ]
>
>     ==>MT
>     This may require more explicit clarifications in the draft.
>
>     This particular PUT request is sent by the group member with name
>     NODENAME, say node X, to ask for new individual keying material,
>     as abstractly put in this draft. A concrete example is in
>     ace-key-groucomm-oscore , where the group member asks for a new
>     OSCORE Sender ID.
>
>     Following this PUT request, the KDC can decide to go for one of
>     the following options. What influences the KDC decision is really
>     application/context specific, and an application profile may give
>     more details as appropriate.
>
>     * Only assigning new individual keying material to the group
>     member X, including it in the response to the PUT request.
>
>     * Rekeying the whole group. For the sake of efficiency, the KDC
>     can provide the new group key material to the group member X in
>     the response to the PUT request.
>
>     * Doing both things above, i.e. first providing the group member X
>     with new individual keying material in the response to the PUT
>     request, and then also perform a full group rekeying.
>
>
>     So, yes, this PUT request can potentially trigger a whole group
>     rekeying as a side effect, depending on what the KDC decides
>     exactly to do. However, it is not what the group member X is
>     asking for, which is not its prerogative as mentioned in previous
>     comments.
>
>     On the final part of the comment:
>
>     * POSTing to ace-group/GROUPNAME does add a node to the group but
>     does not necessarily result in rekeying the group. That depends on
>     the key management policies adopted by the KDC for that group. A
>     group rekeying would especially happen if the application requires
>     to enforce backward security.
>
>     * Early design discussions resulted in ace-group/GROUPNAME/nodes
>     as just the "root" resource (with no handlers) for the node-based
>     sub-resources ace-group/GROUPNAME/nodes/NODENAME, each of which is
>     added only once when the corresponding node is added as group member.
>     <==
>
> [CS: OK, yes putting clarifications in the draft would be helpful on 
> these choices.]
>
>
>>
>>         [SNIP]
>>
>>        *  Can act as a publisher in a pub-sub scenario, and update the
>>           keying material by publishing on a specific topic on a broker,
>>           which all the members of the group are subscribed to.
>>
>>     [CS: This is not a good scenario for pub-sub, as the broker
>>     should not know the
>>     keys. The whole idea of the pub-sub profile is the protect the
>>     content
>>     of the messages from the broker. That means these keying
>>     materials should be
>>     encrypted, and hence, then, the distribution of that keying
>>     material ...
>>     becomes a recursive problem.]
>
>     ==>MT
>     Before dismissing this option, let's think a bit more about it ---
>     This can possibly become a separate thread.
>
>     This way of rekeying the main security group is not referring
>     exactly to the pub-sub profile of ACE to do that. It is referring
>     only to a pub-sub scenario where, for the sake of rekeying the
>     main security group, the KDC is a publisher and all the group
>     members are subscribers of a "rekeying topic".
>
>
> [CS: OK, it want's clear to me what you meant by "a broker" in that 
> paragraph. I understood it as the Broker for pub-sub communication, 
> which the Clients engage in the first place. If the KDC is going to be 
> a broker (or a published as you explain below) use pub-sub 
> communication to send out keys, I don't have a problem with this. ]
>
>
>     It is good that the broker does not see the exchanged messages.
>     These would be protected by the KDC at the application level,
>     using additional administrative key material shared between the
>     KDC and the members of the main security group. Such key material
>     can be provided in the 'mgt_key_material' parameter of a Joining
>     Response, and depends on the exact group key management scheme used.
>
>     Since the KDC is acting as publisher, you would need to involve
>     also the KDC's public key. The best option is probably to provide
>     it in the Joining Response, using the dedicated parameter
>     'kdc_cred' recently introduced in ace-key-groupcomm-oscore (see
>     its Section 6.4), as required for other reasons in the Group
>     OSCORE case.
>
>
>     Actually, I believe the pub-sub profile of ACE may assist for this
>     case too. The KDC has to obtain from the AS a token and upload it
>     to the broker as a proof of authorization for publishing in the
>     "rekeying topic" to rekey a particular security group. Again, the
>     administrative key material to protect the rekeying messages is
>     generated by the KDC itself, which provides it to the members of
>     the main security group in the respective Joining Responses, when
>     they join that security group.
>
>     This is a just simple example with one single "rekeying topic" to
>     deliver a rekeying message to all the group members of the main
>     security group. If a rekeying message has to target only a subset
>     of the group members, you would need a respective sub-topic. For
>     instance, the key hierarchy used by the group rekeying scheme can
>     be mapped to a hierarchy of rekeying topics, all used to rekey the
>     main security group.
>
>     Does it make sense?
>     <==
>
> [CS: Yes, this may work. But then the "administrative key" for 
> rekeying topic, isn't that rolled over? And then how is that "re-keyed"?]

==>MT2
Thinking of advanced rekeying schemes and regardless the method used to 
deliver the rekeying messages (i.e., pub-sub or multicast), the 
roll-over of the administrative keying material is something that the 
group rekeying scheme itself takes care of, through the sent rekeying 
messages. Actually, such a roll-over occurs every time a group rekeying 
is performed upon the leaving of group members to be excluded from 
future communication in the group.

At a high level, each group member owns only a subset of the overall 
administrative keying material, obtained upon joining the group. Then, 
when a group rekeying occurs:

* Each rekeying message is protected by using a (most convenient) key 
from the administrative keying material such that: i) the used key is 
not owned by any node leaving the group, i.e. the key is safe to use and 
doesn't have to be renewed; and i) the used key is owned by all the 
group members targeted by the rekeying message, that indeed have to be 
provided with new communication keying material.

* Each rekeying message includes not only the new communication keying 
material intended to all the rekeyed group members, but also any new 
administrative keys that: i) are pertaining to and supposed to be owned 
by the group members targeted by the rekeying message; and i) had to be 
updated since leaving group members own the previous version.

Details are really dependent of the specific rekeying scheme used in the 
group. At least at a high level, this should be clearer now from the 
explanations about group rekeying given in the new Section 6 "Group 
Rekeying Process".

THE END
<==

>>
>>
>>     5.  Removal of a Node from the Group
>>
>>        [SNIP]
>>
>>
>>        Furthermore, in case of forced eviction, the KDC removes the
>>     public
>>        key of the evicted node if the KDC keep tracks of that, and
>>     possibly
>>        removes the evicted node from the list of observers of the
>>     resource
>>        at ace-group/GROUPNAME (if observable).
>>
>>     [CS: Why only "possibly"?]
>
>     ==>MT
>     It was intended to mean "in case the evicted node was an observer
>     at all". We'll make it explicit; if the evicted node is an
>     observer, it has to be removed from the list of observers.
>     <==
>
> [CS: OK]
>
>
>>
>>      [SNIP]
>>
>>
>>     6.  Extended Scope Format
>>
>>        [SNIP]
>>
>>        The value of the 'scope' claim following the extended format is
>>        composed as follows.  Given the original scope using a
>>     semantics SEM
>>        and encoded as a CBOR byte string, the corresponding extended
>>     scope
>>        is encoded as a tagged CBOR byte string, wrapping a CBOR sequence
>>        [RFC8742] of two elements.  In particular:
>>
>>        *  The first element of the sequence is a CBOR integer, and
>>           identifies the semantics SEM used for this scope.  The value of
>>           this element has to be taken from the "Value" column of the
>>     "ACE
>>           Scope Semantics" registry defined in Section 10.12 of this
>>           specification.
>>
>>
>>
>>     Palombini & Tiloca       Expires 13 January 2022              
>>     [Page 52]
>>     
>>     Internet-Draft  Key Provisioning for Group Communication      
>>     July 2021
>>
>>
>>           When defining a new semantics for a binary scope, it is up
>>     to the
>>           applications and application profiles to define and
>>     register the
>>           corresponding integer identifier (REQ24).
>>
>>        *  The second element of the sequence is the original scope
>>     using the
>>           semantics SEM, encoded as a CBOR byte string.
>>
>>        Finally, the CBOR byte string wrapping the CBOR sequence is
>>     tagged,
>>        and identified by the CBOR tag TBD_TAG "ACE Extended Scope
>>     Format",
>>        defined in Section 10.11 of this specification.
>>
>>        The resulting tagged CBOR byte string is used as value of the
>>     'scope'
>>        claim of the access token.
>>
>>        The usage of the extended scope format is not limited to
>>     application
>>        profiles of this specification or to applications based on group
>>        communication.  Rather, it is generally applicable to any
>>     application
>>        and application profile where access control information in the
>>        access token is expressed as a binary encoded scope.
>>
>>     [CS: Then should it be defined here in this profile or somewhere
>>     else?]
>
>     ==>MT
>     This document is defining the general extensibility method, as
>     agreed to have it exactly in this document. Other specifications
>     that want to take advantage of the extended format have to define
>     some specific details.
>
>     For instance, Section 4.2 of ace-key-groupcomm-oscore defines a
>     particular integer value to prepend to the CBOR sequence if the AS
>     actually uses the extended scope format. This reflects the
>     specific scope semantics defined in that application profile.
>     <==
>
> [CS: OK]
>
>>     9.  Security Considerations
>>
>>       [SNIP]
>>
>>        That is, the KDC may not rekey the group at every membership
>>     change,
>>        for instance if members' joining and leaving occur frequently and
>>        performing a group rekeying takes too long.  The KDC may rekey the
>>        group after a minimum number of group members have joined or left
>>        within a given time interval, or after maximum amount of time
>>     since
>>        the last rekeying was completed, or yet during predictable network
>>        inactivity periods.
>>
>>        However, this would result in the KDC not constantly preserving
>>        backward and forward security.  Newly joining group members
>>     could be
>>        able to access the keying material used before their joining, and
>>        thus could access past group communications.  Also, until the KDC
>>        performs a group rekeying, the newly leaving nodes would still be
>>        able to access upcoming group communications that are
>>     protected with
>>        the keying material that has not yet been updated.
>>
>>     [CS: I think the minimum number of group members should be just 1
>>     if we
>>     are talking about secure group communication]
>
>     ==>MT
>     Yes, it's still about joining a group with group key material to
>     share with next nodes to come. It will be said explicit.
>
>     In particular, if the key material is revoked upon nodes' leaving,
>     it has to be also when the number of members goes from 1 to 0.
>     Then new group key material has to be provided to the next new
>     member joining the group.
>     <==
>     [CS: OK]
>>
>>       [SNIP]
>>     9.1.  Update of Keying Material
>>
>>        A group member can receive a message shortly after the group
>>     has been
>>        rekeyed, and new keying material has been distributed by the
>>     KDC.  In
>>        the following two cases, this may result in misaligned keying
>>        material between the group members.
>>
>>        In the first case, the sender protects a message using the old
>>     keying
>>        material.  However, the recipient receives the message after
>>     having
>>        received the new keying material, hence not being able to
>>     correctly
>>        process it.  A possible way to ameliorate this issue is to
>>     preserve
>>        the old, recent, keying material for a maximum amount of time
>>     defined
>>        by the application.  By doing so, the recipient can still try to
>>        process the received message using the old retained keying
>>     material.
>>        Note that a former (compromised) group member can take
>>     advantage of
>>
>>
>>
>>     Palombini & Tiloca       Expires 13 January 2022              
>>     [Page 57]
>>     
>>     Internet-Draft  Key Provisioning for Group Communication      
>>     July 2021
>>
>>
>>        this by sending messages protected with the old retained keying
>>        material.  Therefore, a conservative application policy should not
>>        admit the storage of old keying material.
>>
>>     [CS: Could it be an option to resend the message with the new
>>     keying material? if the
>>     rekeying happened within a window]
>
>     ==>MT
>     That's most likely what happens once the sender has also obtained
>     the latest group key material (either by actually receiving the
>     rekeying messages, of by asking for it to the KDC if it realizes
>     it has missed a rekeying). It can be added here.
>     <==
>
> [CS: OK]
>
>
>>
>>
>>     [SNIP]
>>
>>
>>     10.  IANA Considerations
>>
>>        This document has the following actions for IANA.
>>
>>     10.1.  Media Type Registrations
>>
>>        [SNIP]
>>
>>
>>
>>
>>     Appendix B.  Extensibility for Future COSE Algorithms
>>
>>     [CS: Why not just use this format instead of reformatting
>>     sign_info_entry
>>     In section 3.3.1]
>
>     ==>MT
>     Simply for the sake of readability. Considering that today's COSE
>     algorithms have only one capability (and always Key Type), for the
>     time being it is sufficient for an implementer to just refer to
>     the simpler format in Section 3.3.1.
>
>     In other words, it was good to define the more general format as
>     future-ready, but it's not strictly necessary to be aware of it
>     when implementing a KDC today. Hence the preference to have it in
>     Appendix B rather than burdening Section 3.3.1.
>     <==
>     [CS: OK]
>>     [THE END]
>
>
>>     On Tue, Aug 24, 2021 at 5:52 PM Göran Selander
>>     <goran.selander=[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Hi,
>>
>>         Here is a review of ace-key-groupcomm-13.
>>
>>
>>         General
>>         ===
>>
>>         This draft provides a link between the ACE-OAuth
>>         authorization framework (including its transport profiles)
>>         and specifications of communication security in groups of
>>         constrained devices, e.g. the coap-groupcomm work currently
>>         developed in CORE. The document is intended to support
>>         different group communication schemes, but the details of
>>         those are defined in separate “application profiles” such as
>>         draft-ietf-ace-key-groupcomm-oscore (for Group OSCORE) and
>>         draft-ietf-ace-pubsub-profile (for pub/sub). This draft
>>         instead defines a common interface to a KDC acting as RS in
>>         the ACE-OAuth architecture, how to use this interface to
>>         perform various key management operations, and requirements
>>         for such application profiles.
>>
>>         As such, this draft is thus an “intermediary” specification,
>>         and its usefulness will be determined by the application
>>         profiles which I've glanced at but are not part of this review.
>>
>>         While this approach seems reasonable from a structure point
>>         of view, I have a question about abstracting the underlying
>>         communication in comment 1 below.
>>
>>         The content of the draft is quite elaborate and with detailed
>>         examples which is good but also leads to my comment number 2.
>>
>>         Now for the main comments:
>>
>>         1. How does this scale to large groups?
>>
>>         Depending on application it may not be necessary to update
>>         keys during join of new members, and depending on the
>>         dynamics of the members rekeying may not be a major issue.
>>         But if it is a large group and all group members need to be
>>         updated at joining or leaving then this may require a lot of
>>         communication for which the underlying group communication
>>         may be helpful.
>>
>>         For example, in case of a new member joining then a new group
>>         key or the new node's public key may be distributed using
>>         broadcast/multicast and protected with some existing group key.
>>
>>         In case of rekeying a group key after a node has been
>>         evicted, a similar method could be used if it was possible to
>>         apply some key hierarchy scheme like e.g. LKH, i.e.
>>         distributing new keys corresponding to a path from the
>>         evicted node to the root in a key hierarchy.
>>
>>         Two sub-questions:
>>
>>         a. Is it possible to extend the interface to make use of the
>>         underlying group communication?
>>
>>         b. Is it possible to apply this interface with a key
>>         hierarchy scheme?
>>
>>         These features are not necessarily in scope of this draft,
>>         but it would be good to understand if a specification of
>>         these features would be able to use the interface defined
>>         here, or if some generalization is required in which case
>>         that change may be considered already now.
>>
>>
>>         2. How would a "minimal" profile look like?
>>
>>         The target setting for ACE in general and this draft in
>>         particular is constrained devices and networks. Some parts of
>>         the draft give example of thinking about lightweight aspects,
>>         but other parts are not at all minimalistic and includes a
>>         large number of features, however in many cases optional.
>>
>>         It would be interesting to have a “minimal” example, where
>>         care has been taken in trying to define a group setting such
>>         that the resulting messages are as few and as small as
>>         possible (for a certain security level). The same comment
>>         applies to code size and state machine: There are a number of
>>         options and “nice to have” features, which if all implemented
>>         could have a measurable impact on the footprint.
>>
>>         The use of the word "minimal" is not intended in an absolute
>>         sense but to target as little as possible and still provide
>>         authorized group key functionality. Perhaps such an exercise
>>         makes more sense in an application profile, such as
>>         draft-ace-key-groupcomm-oscore. But this draft may be provide
>>         a partial answer by indicating what handlers to include (sec.
>>         4), what groupcomm parameters (sec. 7), what error ids (sec
>>         8), etc.
>>
>>         (This comment actually applies also to the transport
>>         profiles, which this draft does not need to take
>>         responsibility for.)
>>
>>
>>
>>         More detailed comments
>>         ===
>>
>>
>>         I found the terminology “POST /token” vs. “Token Post”/“token
>>         POST”/“POST Token” for the different message exchanges,
>>         respectively, quite confusing. For a long time I thought the
>>         latter referred to the former. It is true that the access
>>         token is carried with the method POST in the second exchange,
>>         but I think that is irrelevant and would suggest to instead
>>         use some other consistent terminology. For example, use 
>>         “POST /token” and “POST /authz-info” to refer to the
>>         exchanges, respectively. Alternatively, call the latter
>>         “Token provisioning” or something similar without reference
>>         to the actual method by which the token is provisioned.
>>
>>         This applies in particular to:
>>
>>         Figure 2
>>         “Token Post”
>>
>>         Figure 3
>>         “POST Token”
>>
>>         “3.3. Token Post”
>>
>>         3.3.1.
>>         “an OPTIONAL parameter of the Token Post
>>            response message “
>>
>>         3.3.2
>>         “Token Post response”
>>
>>         etc.
>>
>>
>>         4.1
>>
>>         Section 4.1 specifies the handlers, 20 pages. This is
>>         followed by how the handlers are used 4.2 - 4.10, roughly one
>>         page per subsection. When reading I ended up having two
>>         copies of the draft side by side looking at the handler and
>>         its corresponding use. I'm not sure this is a problem, but
>>         reading the handlers is more motivating after having read
>>         about how they are used. There is a summary in the bullet
>>         list in 4.0 but this is merely a forward reference and didn't
>>         make me do the mapping from handler to action in my head.
>>         Maybe just move content such that 4.2-4.10 comes before 4.1
>>         (and then you can remove the bullet list in 4.0).
>>
>>
>>         "It is REQUIRED of the application profiles of this
>>         specification to
>>            define what operations (e.g., CoAP methods) are allowed on
>>         each
>>            resource"
>>
>>         It speaks of operations on each resource, but it does not say
>>         which resources are mandatory to implement. Where is that
>>         written?
>>
>>
>>
>>         9.
>>
>>         The security consideration speaks about different key update
>>         strategies. I was looking for considerations when to not
>>         rekey in case of new member joining a group. I would imagine
>>         in e.g. a building automation setting where a new actuator
>>         device is added into a group it may not always be necessary
>>         to renew the group key of existing actuators. This is in
>>         particular assuming by the nature of security for actuations
>>         there are already means in place to determine freshness etc.
>>         preventing misuse of an old group key.
>>
>>
>>
>>
>>         Nits
>>         ===
>>
>>
>>         3.1
>>
>>         s/Toid/“Toid”
>>         s/Tperm/“Tperm”
>>
>>
>>         3.2
>>
>>         If this parameter is not present, the granted scope is equal
>>         to the one requested in Section 3.1}.
>>
>>         - remove the “}”
>>
>>
>>
>>         3.3.  Token Post
>>
>>         - - -
>>
>>            “The CBOR map MAY additionally include the following
>>            parameter, which, if included, MUST have the corresponding
>>         values:
>>
>>            *  'sign_info' defined in Section 3.3.1, encoding the CBOR
>>         simple
>>               value Null to require information about the signature
>>         algorithm,
>>               signature algorithm parameters, signature key
>>         parameters and on
>>               the exact encoding of public keys used in the group.”
>>
>>
>>         This seems to unnecessary duplicate information coming just
>>         after:
>>
>>
>>         “3.3.1.  'sign_info' Parameter
>>
>>            The 'sign_info' parameter is an OPTIONAL parameter of the
>>         Token Post
>>            response message defined in Section 5.10.1. of
>>            [I-D.ietf-ace-oauth-authz].  This parameter contains
>>         information and
>>            parameters about the signature algorithm and the public
>>         keys to be
>>            used between the Client and the RS.  Its exact content is
>>         application
>>            specific.
>>
>>         - - -
>>
>>            When used in the request, the 'sign_info' encodes the CBOR
>>         simple
>>            value Null, to require information and parameters on the
>>         signature
>>            algorithm and on the public keys used.
>>
>>            The CDDL notation [RFC8610] of the 'sign_info' parameter
>>         formatted as
>>            in the request is given below.
>>
>>               sign_info_req = nil”
>>
>>
>>         3.3.1
>>
>>         I got the impression from the text above that ‘sign_info’ is
>>         the name of the parameter, but it turns out that the actual
>>         parameter is either called “sign_info_req” or
>>         “sign_info_res”. So, when it is stated that ‘sign_info’
>>         encoding the CBOR simple value Null, which seems like a
>>         straightforward assignment, there is actually no ‘sign_info’
>>         parameter. This is a minor, still slightly confusing.
>>
>>
>>         3.3.1
>>
>>         "This format is consistent with every signature algorithm
>>         currently
>>            considered in [I-D.ietf-cose-rfc8152bis-algs], "
>>
>>
>>         s/considered/defined
>>
>>
>>
>>         3.3.2
>>
>>         "(see the 'client_cred_verify' parameter in
>>            Section 4)"
>>
>>         Refer instead to 4.1.2.1
>>
>>
>>
>>
>>         4.1.3.1
>>
>>         “in case both the 'role_filter' array and the 'id_filter'
>>            array are not empty”
>>
>>
>>         s/not empty/non-empty
>>
>>
>>         4.1.3.1
>>
>>          "Finally, as mentioned in Section 4.1.2.1, both arrays
>>         'role_filter'
>>            and 'id_filter' MUST NOT be both empty."
>>
>>         replace with
>>
>>            "Finally, as mentioned in Section 4.1.2.1, the arrays
>>         'role_filter'
>>            and 'id_filter' MUST NOT both be empty."
>>
>>
>>
>>
>>
>>         4.4
>>         A  missing comma at the end of the following line:
>>
>>         "get_pub_keys": [true, ["sender"], []], "client_cred": PUB_KEY
>>
>>
>>
>>         Göran
>>
>>
>>
>>
>>         On 2021-07-12, 18:16, "Ace on behalf of
>>         [e-mail] <mailto:[e-mail]>"
>>         <[e-mail] <mailto:[e-mail]> on behalf
>>         of [e-mail]
>>         <mailto:[e-mail]>> wrote:
>>
>>
>>             A New Internet-Draft is available from the on-line
>>         Internet-Drafts directories.
>>             This draft is a work item of the Authentication and
>>         Authorization for Constrained Environments WG of the IETF.
>>
>>                     Title           : Key Provisioning for Group
>>         Communication using ACE
>>                     Authors         : Francesca Palombini
>>                                       Marco Tiloca
>>                 Filename        : draft-ietf-ace-key-groupcomm-13.txt
>>                 Pages           : 78
>>                 Date            : 2021-07-12
>>
>>             Abstract:
>>                This document defines message formats and procedures
>>         for requesting
>>                and distributing group keying material using the ACE
>>         framework, to
>>                protect communications between group members.
>>
>>             Discussion Venues
>>
>>                This note is to be removed before publishing as an RFC.
>>
>>                Source for this draft and an issue tracker can be found at
>>         https://protect2.fireeye.com/v1/url?k=08daa3fb-57419b19-08dae360-86073b36ea28-572fafc3ef6c5ed5&q=1&e=fd87b927-3fdc-4d5a-ab71-6248ac68bf5d&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-key-groupcomm
>>         <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D08daa3fb-57419b19-08dae360-86073b36ea28-572fafc3ef6c5ed5%26q%3D1%26e%3Dfd87b927-3fdc-4d5a-ab71-6248ac68bf5d%26u%3Dhttps%253A%252F%252Fgithub.com%252Face-wg%252Face-key-groupcomm&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524530272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Y33GOePFP%2FOBANVr6yh1mFy5wqcuoaGI6IX1DB5ZYd4%3D&reserved=0>.
>>
>>
>>             The IETF datatracker status page for this draft is:
>>         https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
>>         <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524540226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5v2E9dFrqpqzEO85INXeu18JftULOHMYkn2VDS%2FXPQs%3D&reserved=0>
>>
>>             There is also an htmlized version available at:
>>         https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-13
>>         <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-key-groupcomm-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524540226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2PxALjTtXrp4IaAecxKGO22HLa%2FdT773uigl%2F2vYR7s%3D&reserved=0>
>>
>>             A diff from the previous version is available at:
>>         https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-13
>>         <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-key-groupcomm-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524550176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6g5kMubLln4PrEzkicJjyTsYPaS3YDjtXBi6xGtlSNc%3D&reserved=0>
>>
>>
>>             Internet-Drafts are also available by anonymous FTP at:
>>         ftp://ftp.ietf.org/internet-drafts/
>>         <https://eur02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524550176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BZ1yEjMrTBkHJuBDd3Bs%2FDiYxzA6sYBUiNqM9da2FWk%3D&reserved=0>
>>
>>
>>             _______________________________________________
>>             Ace mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/ace
>>         <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524560136%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4TeWA4eikq7LOEergFQdxtD8x0b4fBokuwKK2tamCEo%3D&reserved=0>
>>
>>
>>         _______________________________________________
>>         Ace mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/ace
>>         <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524560136%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4TeWA4eikq7LOEergFQdxtD8x0b4fBokuwKK2tamCEo%3D&reserved=0>
>>
>>
>>     _______________________________________________
>>     Ace mailing list
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/ace  <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524570098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ITTUNipdngkdQFXm9a4aoxmTAMjy5YiMyuULwVjQhIc%3D&reserved=0>
>
>     -- 
>     Marco Tiloca
>     Ph.D., Senior Researcher
>
>     Division: Digital System
>     Department: Computer Science
>     Unit: Cybersecurity
>
>     RISE Research Institutes of Sweden
>     https://www.ri.se  <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524570098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wEPZPfihg07JeU1pROw7lm%2BHEFAE%2BDop4tpECp3G5SI%3D&reserved=0>
>
>     Phone: [phone]
>     Isafjordsgatan 22 / Kistagången 16
>     SE-164 40 Kista (Sweden)
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: [phone]
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)