So I did a quick run through on this document with the intention of starting an implementation. During this process I came across the following issues:
* There should be a note someplace in the document to the effect that if a new group id is generated, then there must be no reliance on the kid for an entity being the same. This can only be done by looking at the signing public key. Also if an entity gets to the point of nearing a roll-over, then the Group Manager could just assign a new kid rather than re-keying the entire group. * Section 4.1 - Given that the signature is no longer part of the option value, something that is both good and bad, I am unsure that there is any requirement for the 'CounterSignature0' bit to be part of the bit array. According to the requirements, one can always assume that for a group message the counter signature will always be appended to the encrypted text. * Section 3. I am not clear if the group ID should be part of the aad_array or not. If it does not need to be present then I think that some text as to why it does not need to be covered would be appreciated. I should note that I don't think that it needs to be there but have not proven it to my satisfaction yet. * Section 5 - The text says that Observe is not defined for group setting. I am not sure that this is a true statement. RFC 7641 does not say anything one way or another about doing observer for multicast. The only issue that I can see is the fact that the path may not always be setup correctly if going through a proxy, but for local network without a proxy I don't see any reason why it should not work. * Section 5.1 - I am unclear of why you are looking at talking about re-transmission in this context. This needs to be clarified. * Section 6. - The fact that they are non-confirmable does not preclude acknowledgement even in a group situation. It may not be advised in general but it is allowed. * Section 6. - Note that responses can be confirmable even if the request is not. * Section 6.1 - You are missing the signature step here. * Section 6.2 - I believe that there should be the ability to decouple the processing of a response from the query back to the GM. Specifically, if you get a new kid for the group id, one should be able to ignore the current message and start an async request for the new keying information on that new sender. Forbidding this should be an application decision not general purpose. Perhaps this should also include a note about the fact that a server might observer the GM in order to get these new kids in a timely manner. * _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
