All, I have taken a look at ace-key-groupcomm-oscore-13. The intent was to make a complete review but I think it would be easier to do that if the draft was somewhat restructured first - a concrete proposal is the main content of this mail. A lot of good thinking has been put into this draft and there are traces from re-writes due to changes in the documents it depends on, which may be the reason for the current structure. In any case I would like to come back with more detailed comments once we discussed the structure.
Dependencies: The main "parent" of this draft is ace-key-groupcomm, of which it is a profile. Another parent is core-oscore-groupcomm, for which it provides key management. Both are pre-requisite reading and therefore this draft uses content from these drafts directly without much introduction. While this is a reasonable assumption, I think the reading would be simplified by a slight rearrangement of the content. Restructure proposal summary: * Follow more closely the order of content in ace-key-groupcomm. More below. * Start with the main cases and what happens first, wait with exceptions and what comes later. Some sections start with listing error codes and come to normal operations later. Of course, this is a matter of style, but I was surprised, for example, to find group *re-keying* in section 2.2 - essentially the first content of the draft - basically before any keying procedures have been described. * Group some of the later sections into subsections, to allow a reader of the table-of-contents an overview. The draft has 26 sections excluding appendices. For example, sections 8-17 are all about sharing information about groups and nodes, which could be made into subsections of one or more sections. * There are a large number of parameters discussed in the document. It would be good if they could be grouped into tables for easier overview and to see which belong together and for what purpose. Section 21 provides a list which is a good starting point. I made a sketch as PR #50 to illustrate the comments above (except tables). It may be difficult to read the diff since I rearranged sections, made some into subsections, and also rearranged some content within sections to make the point about my preferred order of things. Again, this is just a proposal and it may be that we happen to have quite opposite preferences here. More details: ace-key-groupcomm has the following content: Sec. 3. authorization req/resp & token transfer req/resp Sec. 4. RS REST interface / KDC functionality Then sections about changes in the group. Sec. 5. removing member Sec. 6. rekeying Then formats, parameters, error identifiers in Secs. 7-9. This is something like a top-down structure, starting with the main cases and what happens first, waiting with exceptions and what comes later. Now looking at ace-key-groupcomm-oscore, Section 2.1 is essentially a pointer to sections 4 and 6 corresponding to section 3 in ace-key-groupcomm). I propose to delete section 2.1 and let sections 4 and 6 follow suite, rather than point to them. The next section in would then be 5 corresponding to section 4 in ace-key-groupcomm. Section 2.2 is about re-keying and stale IDs corresponding to sections 5-6 in ace-key-groupcomm. I think that makes more sense to speak about after the normal procedure has been described. Section 3 is about format but is quite independent. This could come before or after the main procedures, I put it before. Section 7 is about the public keys is also quite independent and actually provides high level understanding of the trust model, so I put that before too, but is not critical. So the order of the first sections would become something like this: 1 3 7 2.0 4 6 5 2.2 ... There are individual paragraphs moved around the PR to make the text flow better. Have a look and let's discuss. A few nits already now: Nit 1. > Group OSCORE is used to protect CoAP group communication over IP multicast [I-D.ietf-core-groupcomm-bis] Not necessarily IP multicast. This is mentioned in multiple occasions. Use the general formulation “to protect CoAP group communication.” and mention IP multicast as occasional example where needed Nit 2. The identification of the HKDF algorithm by using an algorithm value for a direct method in COSE (COSE algorithms -11, -10) is somehow violating the intent, as there is in this case no COSE object for which the direct method is used. The OSCORE profile of ACE (RFC-to-be 9203 https://www.rfc-editor.org/authors/rfc9203.html) identifies HKDF by the HMAC algorithms (see COSE algorithms 5,6,7). Nit 3. Consider shorten terminology from "Joining Request/Response" to "Join Request/Response" (would also impact ace-key-groupcomm) Göran
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
