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 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
