Subject: [Ace] FW: Review of draft-ietf-ace-key-groupcomm-oscore-05

From: Jim Schaad <[email-masked]>
Date: Sun, 15 Mar 2020 14:43:22 -0700

Forgot to cc the group

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Sunday, March 15, 2020 1:48 PM
To: [email-masked]'
<[email-masked]>
Subject: Review of draft-ietf-ace-key-groupcomm-oscore-05

* Introduction:  In para 2, the second sentence needs to be re-written.  If
you remove the subclause, then you get "This relies on a Group Manager where
members exchange   CoAP messages secured with Group OSCORE." Which is wrong.

* Section 2 -  The following is a problematic statement " All communications
between the involved entities rely on the CoAP protocol and MUST be
secured."  For something like MQTT you want to be able to do it in JSON/HTTP

* Section 2.2 - I think it might be worthwhile in para 3 to give the reason
for needing a new group identifier - This is because of the conflict in name
between group identifier of OSCORE and group identifier of
ace-key-groupcomm.  You have not yet stated that they are different things.

* Section 3.1 - I think I said this before but ["requester", "monitor"]
seems to be a bit of an oxymoron.  Anybody who is either a requester or a
responder can be a monitor without advertising the fact.

* Section 3.1 -  The table in figure 1 is currently not usable due to the
definition of scope in ace-key-groupcomm.

* Section 3.1 - The framework allows for the scope and the audience to be
implicit for an endpoint that is only doing one thing.  Are you sure you
want to eliminate that option?

* Section  4 - I think you probably want to justify the reason for changing
the base name of the resource.  Also the same comments that I made in
ace-key-groupcomm about registering as a well-known are going to exist if
you really want it to be fixed.

* Section 5.2 - scope should not be a mandatory element in the request - it
is implicit in the path name and the scope in the token.

* Section 5.2.1 -  Is this a place where we need to look at replay?  I don't
think so because of the cryptographic wrapper, but we need to have that
discussion in the document.  Which indicates a pointer from this section to
where that discussion is.

* Section 5.4 - cs_alg should refer to the IANA registries not the COSE
document - what if there is a new signature algorithm, like say RSA.

* Section 6 - is it an error for a monitor to provide a public key?  After
all an invalid signature would not need to be checked.   To make life even
more fun, does the rsnonce need to be provided on a token post?

* Section 8 - For bullet 2.a - Is there a reason why this does not do the
rekey and return the new key material rather than returning an error?