Hi Jim,
Thanks a lot for this review!
We have been working on an updated version accessible at [1], which is
already taking into account your comments on CoRAL.
Please, find below inline some more replies and open points.
Best,
/Marco
[1]
https://gitlab.com/crimson84/draft-tiloca-ace-oscore-gm-admin/blob/v-01/draft-tiloca-ace-oscore-gm-admin.md
On 2019-11-20 00:13, Jim Schaad wrote:
> This is just going to be a high level review on how things are done rather
> than a detailed review on each line of text.
>
> 1. - Go and read that CoRE Pub-Sub update document - you know the one that
> Klaus and friends have not managed to get written since the model proposal
> was done way back when.
Yes, we are now relying on an akin interface, along the lines of the now
published draft
https://datatracker.ietf.org/doc/draft-hartke-t2trg-coral-pubsub/
>
> 2. Re-write this to use CoRAL - Yes I know that this makes another
> dependency on getting it published from the CoRE group, but I don't want to
> do things multiple times.
We have now also added examples in CoRAL, for all the interactions
between Administrator and Group Manager, now also extended with FETCH
for filtered retrieval.
>
> 3. I think that this document really needs to be able to be used with
> HTTP/JSON as well as CoAP. If you can get the JSON version of CoRAL from
> Klaus then this falls out without any work.
We are now saying the CoRAL examples are in text format, but they are in
CBOR or JSON on the wire, with no particular additional effort. Is this
enough?
>
> 4. Are you making it a requirement that the group name be the same as the
> group identifier assigned by the "group_name" parameter? If so then having
> some type of title and description would seem to be almost mandatory.
They are in fact the very same thing. The "group_name" parameter
specifies the group name, as intended to identify the OSCORE group both
by the administrator and the joining nodes in the other related
documents. We can use only "invariant name" rather than "invariant
identifier". Are we missing something? If so, what do you suggest we
should give a title and description to?
>
> 5. There needs to be some parameters around pointing to the correct AS and
> so forth. The management API may reject because it does not trust the AS.
> Don't assume that this is a single value for the AS either.
This is good and also aligned with other related drafts.
If we interpret your suggestion correctly:
1) The POST request to /manage may specify also an optional 'as_uri'
parameter, with the link to a suggested AS. The GM may accept the
suggestion or not. If not, it has to think of an alternative AS, as
valid issuer of tokens for joining that group.
2) The GM must have one more parameter in the group configuration with
the effective AS URI, i.e. either one provided by the administrator and
accepted, or one otherwise decided.
Do you think of any additional related parameters to be included in the
POST request, other than 'as_uri'? Perhaps the public key of the
suggested AS if applicable?
Do you think the suggestion in the request should actually be a list of
AS, out of which the GM may pick up at most one?
>
> 6. You are missing a lot of management detail on the POST to the group
> node. Some of the things that are missing would be:
> a) Is the group active or inactive
We can have one more parameter on the group-configuration resource for this.
We are interpreting active/inactive as follows. Ideally, upon creating
the group, the request can specify the initial status as active or
inactive. Upon later updating the group by sending a request to the
group-configuration resource, the administrator can change the status
(or read it through a GET).
Then the active/inactive status has two parallel scopes:
1) one scope is for the GM alone, i.e the GM would allow the joining of
new group members only if the group is set as active.
2) when the group is set as inactive, the current group members should
refrain from sending and should not expect receiving any message
protected with that group key material. However, there is no way to
actually force them to.
In support to scope (2), when the status changes to inactive, the GM
should inform group members about that. To this end, the
group-membership resource intended for group members would also include
a parameter reflecting the group status and aligned in value with the
one in the group-configuration resource. Then, there are two ways to
inform the group members of a status change.
a) A way is to have the group members observing the group-membership
resource (that they may have been doing already anyway for
notification-based rekeying).
b) A second way is for the group members to have a dedicated local
resources for this (and other) kind of control communication (e.g.
rekeying). This is something we are also considering in
ace-key-groupcomm(-oscore) for receiving individual rekeying messages.
In either case this
