After the interim meeting, I read this document through in order to produce a review. Instead you are going to get a meta-review.
I am having a hard to seeing why this document exists in its current form and it is not some type of simple profile of the pub-sub security draft. While I am not sure that this document is a sub-set of that document, it appears to be about 90-99% a sub set of that document. Consider the following: You have both the publisher and subscriber roles as in the pub-sub draft. You have an entity which is doing key distribution in the system. For the pub-sub draft this is AS2 for you it is the RS, but they are performing the exact same set of tasks. The pub-sub draft as and endpoint which holds the encrypted messages, in its place you are using the multi-cast UDP channel. In both cases they are basically unprotected-untrusted entities to distribute the content message. The only difference is that in the pub-sub model the RS will also provide restricted access to publishing which is not enforceable here. Both of these documents are missing what I would consider to be core pieces. The pub-sub document does initial key distribution, while this document does not. Neither document does any discussion of how subsequent key distribution is done to deal with forward and backward security of messages. This document probably needs to define a new relationship, which might be more generally used, to say - this URL is where you get the security information for this URL which is published in the directory - esp in the case of multi-cast address URLs in the resource directory. You might also find that the correct answer is not to use a separate resource for each channel, but to allow for the use of URI path elements to define the security for a resource. Jim _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
