Hello Marco, Jiye, Francesca,I have read draft-ietf-ace-key-groupcomm-02 and I have a few comments for you:
== 1.1 "The URI of a join resource is fixed."How can that be a requirement? The Group Manager might also be a mobile unit that changes address as it moves through different networks.
Perhaps rephrase to "The URI-Path of a join resource is fixed"? == 1.1"Monitor: ... This corresponds to the term "silent server" used in [I-D.ietf-core-oscore-groupcomm]."
Any special reason for defining an separate equivalent term? Otherwise this only makes the set of documents harder to read.
== 2."To this end, the AS must signal the specific transport profile to use, consistently with requirements and assumptions defined in the ACE framework [I-D.ietf-ace-oauth-authz]."
Note that in the ACE framework the AS does not have the obligation to signal the profile, since the assumed base-case is that the profiles are pre-configured and well-known in most constrained applications (this is an update from previous versions of the ACE framework).
== All document: Update references to OSCORE to point to RFC 8613 == 2."2. The joining node transfers authentication and authorization information to the Group Manager by posting the obtained Access Token (see Section 4)."
Although it is explained in section 4 you might want to mention already here _where_ the information is POSTed (or replace "posting" with "sending")
== 2."5. The joining node and the Group Manager maintain the secure channel, to support possible future communications."
Maintaining such a channel is costly in terms of memory, is that really a requirement?
Also in the case of object security, speaking of a 'channel' is misleading. == 3.2 "Also, the 'profile' parameter ..." See previous comment on profile being optional in the ACE framework == 4. "the Access Token post"I don't think this term is well-understood in general. I'd suggest removing it with something less REST-centric for the uninitiated reader, like e.g. "the sending of the Access Token to ..."
== 4.1 " Note that the CBOR map specified as payload of the 2.01 (Created) response may include further parameters,"Note that the ACE framework does not specify this response payload to be a CBOR map. Please explicitly state here that you are deviating from the default payload format in the ACE framework.
== 4.2"In case the joining node knows the encoding of public keys in the OSCORE group, as well as the countersignature algorithm and possible associated parameters used in the OSCORE group, the included public key MUST be in a consistent format. "
What is a "consistent format"? Please rephrase to be more specific. Or did you mean "compatible format"? == 4.3"That is, the public key has to be encoded as expected in the OSCORE group, and has to be consistent with the counter signature algorithm and possible associated parameters used in the OSCORE group."
What is "consistent with the ... algorithms and ... parameters"? Did you mean "compatible"? == 4.3"The 'profile' parameter MUST be present and has value coap_group_oscore_app (TBD), which is defined in Section 9.3 of this specification."
See comments on 'profile' before. == 6."In this case, the joining node MAY not provide again its own public key to the Group Manager,"
This could be misunderstood to mean "MAY NOT ...", how about rephrasing this to: "MAY choose not to provide ..." ?
== 7."When doing so, the Group Manager MAY take a best effort to preserve the same unchanged Sender IDs for all group members"
This is incorrect use of requirements language. This 'MAY' can not be tested and the arguments for claiming conformance to this requirement would be quite diffuse. I suggest to require maintaining the Sender IDs. Why should the GM change them in the first place?
Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
