Hi, Please, find below some comments on this profile. I hope it helps!
Best, /Marco ------------------------ [Abstract] "This profile relies on transport layer or application layer security to authorize the publisher to the broker" is due to the current profiles of ACE, right? Otherwise, this can be (even) more general without mentioning particular layers. [Section 1] Here the claimed scope is authorizing nodes, but it is actually also about key provisioning (Section 3.1) and actual communication (Section 6.1). [Section 2] Here the claimed scope is protecting communication (in a broad sense), while it can again mention also authorizing nodes (as per ACE) and key provisioning (Section 3.1). I believe that the paragraph "There are four phases, ..." and the numbered list would read better if placed right before the final paragraph "Note that AS1 and AS2 ..." [Section 3.1] I think this will also need a way for clients to agree with the AS2 on the correct format of their own public key (if they don't know already), similarly to what suggested in ace-key-groupcomm-oscore. The only type of approach that would not work is the one embedded with a Token POST, since that does not happen with AS2. The text says: "... the AS2 is both the AS and the KDC, ... so the Authorization Response and the Post Token message are not necessary" . Shouldn't we then have the Token POST to the KDC defined as optional already in ace-key-groupcomm ? See for instance its Figure 2. In the Key Distribution Request, only one role can be indicated in scope. What if a client wants to be both publisher and subscriber? This seems allowed in Section 3.3 of core-coap-pubsub . Should a client separately contact the AS2 multiple times? In the Authorization Response, the 'profile' field can point at Section 8.1 where the profile value is defined. In the Authorization Response, see above for the 'scope' field in case of a client that wants two roles. [Section 4] Page 8, second bullet point, it can say "... protect the publication end-to-end with the subscribers (see Section 6.1)". [Section 5] Page 9, it can say "... keying material to verify the publication protected end-to-end with the publishers". [Section 6] It would be good to refer to core-coap-pubsub , and its usage of Observe for subscriptions. The text says: "The (F) message is ... , which is unprotected." , although Section 3 admitted the possibility of communication secured also between Broker and Subscribers. [Section 6.1] In the unprotected headers of the COSE object, what is used as Partial IV? [Section 8.2] The value of 'Profile' should be "coap_pubsub' , consistently with the name of the profile registered in Section 8.1. -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
