Subject: [Ace] Review - draft-seitz-ace-oscoap-profile-03

From: Jim Schaad <[email-masked]>
Date: Sat, 15 Jul 2017 09:54:58 +0200

Here are some comments on the draft.

1.  Please change the title.  It would be more appropriate to say that you
are "OSCOAP profile of the Authentication and Authorization for Constrained
Environments Framework".  ( I will also be asking for a rename of that
document to add framework to highlight it is a structure not the final
document).

2. Expand ACE in the abstract.  Lookup on the RFC Editor page if you need to
expand OAuth as well.

3.  I think that you need to distinguish between a returned key used for
oscoap vs oscoap+edhoc so that the server can deal with the new key in a
correct manner.  (This links to a request for the profile to be in the CWT
for the framework.)

4.  In section 2.2.1 - this is not really a POP key, it is a shared secret
and not even a symmetric key.

5.  In section 2.2.1 - Is there a reason not to re-use kid for sid?

6. In Section 2.2.1 - I would change the text relating to how ids are
defined.  What is here is not really what we are looking for in this case as
smaller ids are much nicer esp if the AS can ensure uniqueness based on some
knowledge.

7. In Section 2.2.1 - Need to have some text some place to declare what to
do for collisions of the rid value.

8.  In Section 2.2.1 - Does it make more sense to say "client" and "server"
id instead.

9.  In Section 2.2.2 - This is incorrectly section numbered

10. In section 2.2.2 - Again the symmetric key is not a POP key.

11.  In section 2.2.2 - for asymmetric case need to the rs_cnf parameter.
<<< I need to double check this >>>

12. In section 2.2.2 - In the CWT, the specific asymmetric key used by the
server in the event it has multiple

13. In section 2.2.2 - Need to make a statement about the expires_in field.
Is this the expires for the original secret or for the EDHOC derived key.

14. In section 2.2.2 - I am not sure that I am thrilled by the idea of
running the EDHOC protocol on the authz-info resource point. 

15. In section 2.2.2 - Is there a reason for not supporting multiple edhoc
negotiations w/ the same secret - it seemed to be an original mode that was
supported.

Jim