Original text:
respectively, and the public authentication keys are denoted G_I and G_R, respectively. <del> For X.509 certificates the authentication key is represented with a </del>  SubjectPublicKeyInfo field.  For CWT and CCS (see auth-cred)) the <del> authentication key is represented with a 'cnf' claim RFC8747 containing a COSE_Key RFC9052. </del>  3.5.2. The authentication credentials, CRED_I and CRED_R, contain the public authentication key of the Initiator and the Responder, respectively.  EDHOC relies on COSE for identification of credentials (see id_cred), for example X.509 certificates RFC5280, C509 certificates I-D.ietf- cose-cbor-encoded-cert, CWTs RFC8392 and CWT Claims Sets (CCS) RFC8392.  When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 <del> certificate / CWT. </del>  Since CRED_R is used in the integrity verification, see asym- msg2-proc, it needs to be specified such that it is identical when

Reviewer comments:
URL I have been reading v17 and sent some comments to the authors, that I summarize here: 1) - Regarding RPK, previous versions of the document had a more detailed explanation about RPK. For example, in version v06 you had "The Initiator and the Responder MAY use different types of credentials, e.g. one uses an RPK and the other uses a public key certificate.” So RPK is included as part of the definition of authentication credential. However, v17 may have a different meaning since it seems “credentials" is defined as follows: "EDHOC relies on COSE for identification of credentials (see Section 3.5.3), for example X.509 certificates [RFC5280], C509 certificates [I-D.ietf-cose-cbor-encoded-cert], CWTs [RFC8392] and CWT Claims Sets (CCS) [RFC8392]. When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 certificate / CWT. I assume RPK is also an authentication credential and this should be included in this text. A clarification would be worthy. 2) I assume it is possible that any two IoT devices can act as initiator but also as a responder, even between same two peers. It is the application which decides when to start EDHOC (initiator) in a particular case, correct? 3) It seems the EDHOC does not define any exchange for the key update (some sort of rekey). It seems an application at some point exchange some messages as "some event that triggered the key update.” Then the application call to EDHOC-KeyUpdate function to get a new PRK. Am I right? I am asking because looking at IKEv2, for example, and for the rekey, an exchange is required. Although it would add a little bit more complexity, wouldn’t it be sensical that EDHOC defines a 1 RTT to exchange a couple of nonces for the rekeying. Moreover, this function is defined in an Appendix. Is it mandatory to implement?
Yes. The document should talk about RPK a bit more as that is term that people might search for. Should be explained that CWT is the format EDHOC uses for raw public keys (RPK). Hi all: I have been reading v17 and sent some comments to the authors, that I summarize here: 1) - Regarding RPK, previous versions of the document had a more detailed explanation about RPK. For example, in version v06 you had "The Initiator and the Responder MAY use different types of credentials, e.g. one uses an RPK and the other uses a public key certificate.” So RPK is included as part of the definition of authentication credential. However, v17 may have a different meaning since it seems “credentials" is defined as follows: "EDHOC relies on COSE for identification of credentials (see Section 3.5.3), for example X.509 certificates [RFC5280], C509 certificates [I-D.ietf-cose-cbor-encoded-cert], CWTs [RFC8392] and CWT Claims Sets (CCS) [RFC8392]. When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 certificate / CWT. I assume RPK is also an authentication credential and this should be included in this text. A clarification would be worthy. 2) I assume it is possible that any two IoT devices can act as initiator but also as a responder, even between same two peers. It is the application which decides when to start EDHOC (initiator) in a particular case, correct? 3) It seems the EDHOC does not define any exchange for the key update (some sort of rekey). It seems an application at some point exchange some messages as "some event that triggered the key update.” Then the application call to EDHOC-KeyUpdate function to get a new PRK. Am I right? I am asking because looking at IKEv2, for example, and for the rekey, an exchange is required. Although it would add a little bit more complexity, wouldn’t it be sensical that EDHOC defines a 1 RTT to exchange a couple of nonces for the rekeying. Moreover, this function is defined in an Appendix. Is it mandatory to implement? Beyond these clarifications, I think the document is ready. Best Regards. Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: EMAIL

Revised text:
respectively, and the public authentication keys are denoted G_I and G_R, respectively.  <ins> For X.509 certificates the authentication key is represented by a </ins> SubjectPublicKeyInfo field.  For CWT and CCS (see auth-cred)) the  <ins> authentication key is represented by a 'cnf' claim RFC8747 containing a COSE_Key RFC9052.  In EDHOC, a raw public key (RPK) is an authentication key encoded as a COSE_Key wrapped in a CCS. </ins> 3.5.2. The authentication credentials, CRED_I and CRED_R, contain the public authentication key of the Initiator and the Responder, respectively. <ins> The authentication credential typically also contains other parameters that needs to be verified by the application, see auth- validation, and in particular information about the identity ("subject") of the endpoint to prevent misbinding attacks, see identities. </ins> EDHOC relies on COSE for identification of credentials (see id_cred), for example X.509 certificates RFC5280, C509 certificates I-D.ietf- cose-cbor-encoded-cert, CWTs RFC8392 and CWT Claims Sets (CCS) RFC8392.  When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509  <ins> certificate / CWT.  The Initiator and the Responder MAY use different types of authentication credentials, e.g., one uses an RPK and the other uses a public key certificate. </ins> Since CRED_R is used in the integrity verification, see asym- msg2-proc, it needs to be specified such that it is identical when