[Ace] Review Comments on -03

[Jim Schaad <[e-mail]>]

Note - the OSCORE profile people should scan these comments for relevancy as
well.

Meta Question - Is there a check list that I can run through which says that
these are the things that a profile needs to cover.  Part of this question
about how the document is structured.  I was of the opinion that a profile
was going to need to cover one or both of the following issues:  How does
this profile deal with communications between the C and the RS?  How does
this profile deal with communications between the C and the AS?  How does
this profile deal with communications between the RS and the AS?

*  If the document discusses how to do communications between the client and
the AS, I do not believe that you can rule how mutual authentication between
those two entities as being out of scope.  You don't need to specific how
the initial configuration is done, but the fact that you are using DTLS with
pre-configured credentials needs to be in scope.

* It is too bad that we don't have the generic coap schemas defined yet so
that we can use that as part of the URL returned with an access denied
response.

* Point to Authz document for the details of getting the AS URL back in
section 2 p 3

* Update section 2 to talk about the use of the rs_cnf parameter.  For RPK
no cnf parameter would be expected to be returned.

*  Deal with RPK and PSK in separate paragraphs.  Yes you may have some
duplication of text but the details are sufficiently different that it would
read better.  Section 2

* Section 2.1 - PSK is not a session key.  The session key is inside of TLS.
This means that the session  key is not the identity.

* Section 2.2 - Is there an intent in this paragraph that if the kid does
not match the current DTLS session that the CWT would be rejected?  That
appears to me to be what the text says but I am not sure.  Next paragraph
appears to say any active DTLS session rather than just the current one.

* Section 2.3 p 3 - How is a check done for the PSK being the same if one
has deleted all of the CWTs and then get an update over the secure channel.
Just having the kid be the same should not be sufficient.

* Section 2.3 - Is the kid parameter still needing to be defined given the
CWT POP key id option?  (Assuming that it does not disappear.)

* Section 3 - YEAH you are doing POP on the RPK as part of the request.  I
like this!!!!!!!

*  Section 3 - The last 2 sentences in this section are giving me problems.
I don't understand when  and where you are putting kids and why.

* Section 4 - if the token is already secure then no secure channel would be
needed.  Hard to have a secure channel if you have not setup anything yet.

* Section  4 - Are we really using MAX-AGE and not expires in for duration.

* Section 4 - Update the pointer to a PoP token description

* Section 4.1 - I think that this is not what the COSE_Encrypt structure is
defined in the POP structure for.  Revisit this.

* Section 4.2 - Remove everything to do with renegotiation of TLS - It is no
longer present in 1.3

s/Is also adds/It also adds/

jim