I read this document on the flight back with the idea of thinking about doing an implementation. In the process I found that it does not seem to be ready to start on an implementation.
1. This document is written explicitly in terms of using CBOR as the encoding format. Should it be written such that either JSON or CBOR can be used for the underlying encoding? While I personally don't care, it may be that either Hannes or the MQTT authors might find this to be something that would be useful. 2. Is there a content type that is planned for the messages used in this document? If the plan was to use application/ace+cbor then this both needs to be stated and should be cleared with the group in general. If there is no plan to create one then it would be useful to state this. 3. The document does not have a table which deals with abbreviations, does this mean that the full text string is what is going to be the key? Depending on the content type being considered, these values could be assigned (new registry) or marked as TBD, but if this is supposed to happen then it needs to be placed in the document. 4. Should the references to RFC 7390 be replaced with the new document being considered for the CoRE working group? 5. Section 2 - In the last paragraph - should the word "further" be omitted as there did not seem to be any previous communications discussed. 6. Section 3.1 - Is there a reason why one cannot request access from the AS for multiple groups/topics in the same request to the AS? 'scope' 7. Section 3.1 - Is there a definition of the values for "role" that can be requested. What is the type of this field for a single value, or for elements of the array? Is there a default if role is omitted on the request? 8. Section 3.2 - IN the last paragraph did you mean to say that a new token would be returned or that the existing token can be returned. 9. Section 4.1 - If the 'client_cred' field in a request is filled in, and it is not the same as the public key used to establish the TLS session between the client and the KDC, what is the procedure to do a POP on this key? 10. Section 4.1 - What is the data structure for client_cred? 11. Section 4.1 - For 'pub_keys_repos' what is the format of this field? 12. Section 4.2 - I am not completely sure that I understand what verification checking means in the first paragraph. 13. Section 4.2 - What is the profile that I am checking for the 'kty' field? Was I supposed to have a chance to request a profile someplace? 14. Section 4.2 - Put the fact that the 'key' field is profile dependent on the 'kty' in the 'key' paragraph. Is it legal to define a 'kty' which does not have a 'key' field? If so then should this field be defined by the profile? Ok, I just read the full next paragraph and now I am just confused. 15. Section 4.2 - What is the type of profile? 16. Section 4.2 - Is exp supposed to be a UNIX time - if so then it should say so. Might be easier to reference this as CBOR Tag 1 w/o the tag. 17. Section 4.2 - 'pub_keys "In case public keys are represented as COSE_KEYS" Does this mean that other items are legal - if so then how am I supposed to know this. 18. Section 4.2 - What is the type of 'group_policies'? 19. Section 4.2 - What is the type of 'mgt_key_material'? 20. Section 4.2 - The last paragraph seems to be something of a non-sequitur. Perhaps this is better omitted and just put someplace else, like the next section. 21. Section 5 - Is there some type of requirement for positive delivery of new keys in the event of a KDC changing the key. I put this here wrt a node leaving, but it applies equally to a node getting itself added. 22. Section 5.1 - There currently is no way for an AS to communicate to the KDC that an authorization has been revoked. There is only a way for a KDC to ask the AS by introspection. The first sentence is problematic. Do we need some type of extension to support this? 23. Section 5.2 - If a topic is provided and the user is authorized for two topics which use the same group, what happens if the user asks to leave one of those two topics but wants to say on the other? 24. Section 5.2 - What is the purpose of providing the 'client_cred' in a leave request. It makes more sense to provide the id in the group than this field. 25. Section 5.2 - It is not clear to me that the correct answer to a badly formatted leave request is to send a bad request error back. I would think that as long as the KDC can figure out what is being referred to then the sender should be removed from the group. 26. Section 5.2 - It is not clear to me if the last paragraph means that the KDC can remove the AS access token from it's database when a leave occurs, or if it can only be removed when it expires. 27. Section 6 - If the 'exp' parameter is not specified, when does keying material expire? This is not covered in the first paragraph. 28. Section 6 - in the second paragraph it says that the problem is not being able to decrypt a message, the correct condition is not being able to find key material. A corruption in the message should not require the entity to looking for a rekey event to be checked. This is a bad DOS vector otherwise. 29. Section 6 - Should a KDC employ a best effort to keep the same kid value when a group is rekeyed so that one could check the signature even if the key material has moved on as this would provide a potential DOS attack to be attenuated. 30. Section 6 - should a client keep a the decryption failures so that they can be decrypted after getting new key material or is this to be treated as a loss of message? 31. Section 6 - How does the event of sending the re-key material as a multicast message in general lock out the entity that just left the group? This should be discussed. 32. Section 6 - There needs to be a method for a client to say that it needs a new key id someplace in the protocol which may or may not cause a new re-key operation in the event that it sends too many messages on the current content. 33. Section 6.1 - What happens if I ask for a key re-distribution, but supply a different scope than for the original message < assumes a multi-topic scope>. I am not sure what the purpose of the scope is at this time given that you are not checking roles as well. 34. OUT OF ORDER - Should a KDC have a single resource which allows for it to return a group based on what the topic/scope is that is passed in without the client first knowing what the group id is going to be? 35. OUT OF ORDER - are all of the resource names required to be at the root? If I have a KDC which is shared with something else (say a Pub Sub server) then it would make sense to have post to /KDC/group-id. 36. Section 7.1 - what is the format of get_pub_keys when group member ids are included? 37. Section 7.2 - There is a race condition caused by the last paragraph in this section. Entity A sends a message, leaves the group, Entity B receives the message and askes for the public key. Is this an issue? 38. Section 91. - can the profile column have multiple values? 39. It would be useful to have a section which describes all of the items that a profile must cover in order to be used. Jim _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
