Hi Jim,
Thanks a lot for your detailed review, as you might have seen we have included
most comments in the latest version:
https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02
Please note that this version includes also review comments from Peter, which
in some cases overlapped, so some text might be reformulated to include both
inputs.
Inline, detailed comments and some questions.
Thanks,
Francesca
On 13/07/2018, 20:38, "Ace on behalf of Jim Schaad" wrote:
* Section 2 - client - write rights and/or read rights. Unless you think
that write implies read in which case you should state that
FP: Right, we now specify: " It can request write and/or read rights."
* Section 2 - KDC - should also say what it does in the later parts -
FP: Ok, we added the following text: " During the second part (Section 4),
which is not based
on the ACE Framework, it distributes the keying material." We also added
details about the role of the KDC for redistribution of keying material.
* Section 2 - Dispatcher - If this is a bus, then you are not really
communicating with it securely. Anybody can write on it, but people will
just ignore what comes out the other end.
FP: Right, reformulated in " entity through which the Clients communicate with
the
group and which distributes messages to the group members."
* Section 3- A brief description of all of the operations would be
appreciated.
FP: we have now added several sections to describe the operations. In section 2
(starting with " This document specifies the message flows and formats for:")
we describe the high level operations. At the beginning of each section (3. and
4.) we also give an overview of the exchange described in the subsections.
* Section 3.1 - Can I get authorization for multiple items at a single time?
FP: In theory, it would be possible, and that would require to change the
format of scope, going from [ group-id, [role1, role2] ] to [ [group-id1,
group-id2], [[role1, role2], [role1]] ]. We haven't implemented this change,
because it seems to cause a lot of overhead and complexity, for what seems to
be a corner case. But if people think this is a valid use case, we can
reconsider. We have added a placeholder comment in the md for this.
* Section 3.1 - Does it make sense to allow for multiple audiences to be on
a single KDC?
FP: I am not sure I understand the scenario, could you expand on this? (We have
added a comment in the md for this as well)
* Section 4.x - cnf - text does not allow for key identifier
FP: Did you get the section wrong? In 4.x we do not use cnf. In which section
exactly would you send the kid in the cnf? That should be defined in the Ace
framework (and params)...
* Section X.X - Define a new cnf method to hold the OSCORE context
parameters - should it be a normal COSE_Key or something new just to makes
sure that it is different.
FP: This is the same comment as in the OSCORE Profile. Again, I am not sure why
we really need a new structure since COSE_Key is general enough to transfer all
the keying material, with the addition of the couple of new parameters defined.
But if you think this is necessary, we can definitely change.
* Section 3.X - I am not sure if write or POST is a better answer for what
the role being requested is.
FP: Again, I don't understand this comment. We don't really define what one
should use as role, write or POST are both possible.
* Section 4 - Should one talk about the ability to use OBSERVE as part of
key distribution?
FP: We added a comment as a placeholder for this in the md. Observe was just
briefly mentioned before and not really elaborated. Although it would work, it
seems not useful to have it together with a proper rekeying scheme where the
KDC takes the initiative anyway.
* Section 4.x - I am having a hard time trying to figure out the difference
between a group and a topic. The text does not always seem to distinguish
these well.
FP: It was our purpose to keep the text high level enough so that it would
apply to both. Does that create any problem/confusion?
* Seciton 4.1 - POP on client key esp if bound to an identity (Note using
it to access the KDC is one POP)
FP: Now added the following text at the end of section 4.: " Note that
proof-of-possession to bind the access token to the Client
is performed by using the proof-of-possession key bound to the
access
token for establishing secure communication between the Client and
the KDC."
* Section 4.2 - why not use the exp field from OAUTH in the response
FP: the exp field from the AS in the response relates to the token. This exp
relates to the keying material. Yes, when the token expires the keying material
should expire (and that is specified e.g. in the OSCORE profile), but
