Subject: [Ace] Comments on ace key groupcomm -01

From: Jim Schaad <[email-masked]>
Date: Fri, 13 Jul 2018 14:38:28 -0400

* Section 2 - client  - write rights and/or read rights.  Unless you think
that write implies read in which case you should state that

* Section 2 - KDC - should also say what it does in the later parts - 

* 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.

* Section 3-  A brief description of all of the operations would be
appreciated.

* Section 3.1 - Can I get authorization for multiple items at a single time?

* Section 3.1 - Does it make sense to allow for multiple audiences to be on
a single KDC?  

* Section 4.x  - cnf - text does not allow for key identifier

* 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.

* Section 3.X - I am not sure if write or POST is a better answer for what
the role being requested is.

* Section 4 - Should one talk about the ability to use OBSERVE as part of
key distribution?

* 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.

* Seciton 4.1 - POP on client key  esp if bound to an identity (Note using
it to access the KDC is one POP)

* Section 4.2 - why not use the exp field from OAUTH in the response

* Question - does somebody talk about doing key derivation for a new kid
showing up and by the way where is the gid

* Seciton 4.2 - if you are using profile, then you should return it

* Introduction - introduce the concept of a key management protocol and
point to some.  Give some basic properties expected from one.

* Section 5.2 - What is the message to leave - can I leave one scope but not
another?  Can I just give up a role?

* Seciton 6.1 - assumes scopes are unique across all audiences.  Or assumes
that I look up the correct token - should have an argument about why this is
possible so that people can implement it right

* Comment somewhere about getting strike zones setup correctly for a newly
seen sender of messages. Ptr to OSCORE?

Jim