Subject: [core] Comments on draft-ietf-core-object-security-06

From: Jim Schaad <[email-masked]>
Date: Tue, 29 Nov 2016 22:08:52 -0800

Since I never seem to get that far in the document I decided to jump
straight to appendix C and look at what you have for OSCON.  As I have
stated many times the past, I believe that this should be part of the core
document and not an appendix, but I don't ever remember reading it.

Appendix C - I am having a hard time with the first paragraph here.  I do
not believe that you have correctly characterized the problem.  The reason
that you cannot use OSCOAP for this has more to do with how you decided
which records in the header to authenticate rather than the fact that this
is going to be distributed to multiple recipients.  

Appendix C - Talking about the "unprotected" and the "protected" CoAP
message is very confusing especially since COSE has protected and
unprotected objects as well.  It would be better to use a different
terminology such as "the original message" and "the resulting message".

Appendix C - I do not understand what this sentence means. " OSCON shall not
be used in cases which require a secure binding between request and
response."  Is it intended to say that the use of a transaction identifier
in the COSE wrappers for the request and response is not permitted?  There
are a lot of ways to do this that do not rely on CoAP.

Appendix C - It is not clear if the Content-Format should be set if there
was no Content-Format in the original message.

Appendix C.1 - I do not understand what this section is trying to
accomplish.  It appears to be doing three different things, some of which
should be in Appendix C, some of which should be standalone and some of
which looks like it should be 

Appendix C.5 - There should be a discussion related this this about the
different security properties that are to be found for Encrypt+Sign(M) vs
Sign(Encrypt(M)).

Appendix B - These are really example message flows rather than examples of
OSCOP messages.  This should be made clearer in the section title

Appendix B.1 - How does one securely bind the request and the response?  I
am not seeing anything from this example that will do so.