Forgot to cc the group -----Original Message----- From: Jim Schaad <i...@augustcellars.com> Sent: Sunday, March 15, 2020 1:48 PM To: 'draft-ietf-ace-key-groupcomm-osc...@ietf.org' <draft-ietf-ace-key-groupcomm-osc...@ietf.org> Subject: Review of draft-ietf-ace-key-groupcomm-oscore-05
* Introduction: In para 2, the second sentence needs to be re-written. If you remove the subclause, then you get "This relies on a Group Manager where members exchange CoAP messages secured with Group OSCORE." Which is wrong. * Section 2 - The following is a problematic statement " All communications between the involved entities rely on the CoAP protocol and MUST be secured." For something like MQTT you want to be able to do it in JSON/HTTP * Section 2.2 - I think it might be worthwhile in para 3 to give the reason for needing a new group identifier - This is because of the conflict in name between group identifier of OSCORE and group identifier of ace-key-groupcomm. You have not yet stated that they are different things. * Section 3.1 - I think I said this before but ["requester", "monitor"] seems to be a bit of an oxymoron. Anybody who is either a requester or a responder can be a monitor without advertising the fact. * Section 3.1 - The table in figure 1 is currently not usable due to the definition of scope in ace-key-groupcomm. * Section 3.1 - The framework allows for the scope and the audience to be implicit for an endpoint that is only doing one thing. Are you sure you want to eliminate that option? * Section 4 - I think you probably want to justify the reason for changing the base name of the resource. Also the same comments that I made in ace-key-groupcomm about registering as a well-known are going to exist if you really want it to be fixed. * Section 5.2 - scope should not be a mandatory element in the request - it is implicit in the path name and the scope in the token. * Section 5.2.1 - Is this a place where we need to look at replay? I don't think so because of the cryptographic wrapper, but we need to have that discussion in the document. Which indicates a pointer from this section to where that discussion is. * Section 5.4 - cs_alg should refer to the IANA registries not the COSE document - what if there is a new signature algorithm, like say RSA. * Section 6 - is it an error for a monitor to provide a public key? After all an invalid signature would not need to be checked. To make life even more fun, does the rsnonce need to be provided on a token post? * Section 8 - For bullet 2.a - Is there a reason why this does not do the rekey and return the new key material rather than returning an error? _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
