Subject: [COSE] FW: draft-gerdes-ace-actors

From: "Jim Schaad" <[email-masked]>
Date: Mon, 10 Aug 2015 00:14:28 -0700

I forgot to cc the working group on this mail

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]]
> Sent: Sunday, August 09, 2015 11:19 PM
> To: [email-masked]'
> Subject: draft-gerdes-ace-actors
> 
> Trying to continue my review from before.
> 
> *  I find following the actor abbreviations to be difficult to follow.  It
would be
> easier if the names were reflective of each other.  I am not sure if you
are
> grabbing the names from a different world in which case this probably
cannot be
> done.
> So it would be easier with   C <--> R,  CAS <--> RAS,   CO <--> RO.
Trying to
> figure out that RqP belongs on the C side of the world is somewhat
confusing for
> a first time reader.  Similarly the fact that AS has a prefix for the C
side but not
> the R side is difficult.  As things stand one cannot discuss an AS as a
standalone
> entity which is a generic CAS and RAS item and contrast it with the
differences
> from being on one side or the other.
> 
> *  Section 5, para 2-  Suggest 'an actor is an entity which performs a set
of tasks,
> has a security domain (client domain or resource domain), and a level
> (constrained, less-constrained or principal).'  The second sentence in
this
> paragraph adds no additional detail.
> 
> * Section 5, para 3 - s/for constrained devices/for the architecture/.
The
> second sentence in this paragraph probably wants to say something along
the
> lines of 'An extant architecture can combine multiple actors into a single
physical
> entity.    In this case the combined entity needs to deal with all of the
security
> requirements of the logical actors.
> 
> *  Section 5.1 - As I understand things, the task 'Validate that an entity
is an
> authorized server for R' should be assigned the CAS and not to C.  I could
be
> wrong - it might be assigned to AS.  But it is still not a task for C
> 
> *  Section 5.1 - The last sentence is not making sense to me.  Based on
the
> definition of security domains in section 5, C and RS are always going to
belong
> to different security domains even if the resource owners are the same.
One of
> these needs to be clarified.
> 
> *  Section 5.1 - Kill figure 8 and point to figure 1
> 
> *  Section 5.2 - Why is this your objective?  It might be your model or
> architecture, but it is hardly an objective.
> 
> *  Section 5.2 - para 1 - the last sentence is unclear - do the principals
belong to
> the same security domain or do the principals and their resources belong
to the
> same security domain.  The latter is what seems to be said.
> 
> * Section 5.3 - bullet 3 - who is it doing the negotiation with?  Itself
and C?  that
> is what the text seems to imply
> 
> *  Section 5.3 - Should this section also discuss discovery.  How is C
supposed to
> discover the existence of R and the identity of RS?
> 
> * Section 6.1 - What are the requirements that DTLS considers?  If you
don't tell
> me what the requirements are in this section then there is no reason for
me to
> believe that you have good examples in this section.   Additionally, what
you
> have listed here are just transport protocols.  What about the data that
is going
> to be transported using this protocol?  How do these protocols need to be
> designed?  What levels do the constraints needs to be examined?  Transport
> level?  Security Level?  Data Level?  Discovery
> 
> *  Section 6 is not delivering any useful information.  Either it needs to
have
> information that is needed or it should just be eliminated.
> 
> * Section  7.1 - are you moving authorization information, or
authorization
> decisions from AS to RS?
> 
> * Section  7.1 - What about dealing with authorization information going
> between CAS and AS?
> 
> * Section 7.1 - The second sentence in bullet 3 seems to be misplaced.
> 
> * Section 7.1 - Why is C not enforcing authorization decisions as well?
> 
> * Section 7.2 - bullet 1 - Is there a need for mutual authentication?
> 
> * Section 7.2 - bullet 3 - the second sentence is positing a solution not
a
> requirement.
> 
> * Section 7.2 - bullet 4 - I don't know why this is not written in the
same way as
> bullet 3 - you are just authenticating properties not the entire thing.
> 
> *  Section 8 - I am not sure what the purpose of this section is for.  It
would
> seem to be better to fold this into section 7.
> 
> 
>