Hi, Please, see below a couple of comments and thoughts on this profile.
1. In Section 7, the second paragraph says "critical that only authorized Publishers can publish", i.e. it points at an authorization aspect. However, the sentence continues with opening for a purely symmetric key-based solution, in case source-authentication is not strictly needed and anonymity is desired. I suppose that this paragraph is actually intended to discuss the latter aspect, so it may be better to rephrase it to clarify its focus on source- vs. group- authentication, rather than on authorization to publish. That is, authorization to publish to that topic is still enforced in either case, by AS2 providing the topic-related symmetric key to the publisher. 2. The document needs to define how to construct the AEAD nonce used to protect/verify a published message. Unless only one publisher per topic is admitted, this seems to require to have also a Publisher ID to use for constructing the nonce. Publisher IDs would have to be unique under the same topic, which AS2 is in a position to ensure. A possible way to manage and distribute Publisher IDs can be: a) In the joining request payload (see Figure 5), the publisher provides its own public key in 'client_cred' but without a 'kid'. b) The joining response (see Figure 6) includes a new parameter, specifying a Publisher ID "PID" determined by AS2 and unique within that topic. This is similar to what is done in ace-key-groupcomm-oscore by the Group Manager upon a new member's joining. c) AS2 stores the publisher's public key, adding as its 'kid' field the "PID" from step (b). d) A subscriber learns the Publisher ID "PID", whenever retrieving the public key of that publisher from AS2. e) When publishing a message, the publisher includes its own Publisher ID "PID" received at step (b) above, in the 'kid' of the unprotected field of 'countersign' (see Figure 12). This should still be aligned to what described now in the draft, but entrusting AS2 to manage the 'kid' of public keys as Publisher IDs, so ensuring their uniquess within a topic. Then the actual nonce construction can possibly be along the lines of the one for (Group) OSCORE, see https://tools.ietf.org/html/rfc8613#section-5.2 Best, /Marco -- 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
