Change:
SUITES_I - array of cipher suites which the Initiator supports in order of preference, starting with the most preferred and ending with the cipher suite selected for this session.  If the most <del> preferred cipher suite is selected then SUITES_I is encoded as that cipher suite, i.e., as an int.  The processing steps are detailed below and in wrong-selected. </del> <ins> preferred cipher suite is selected then SUITES_I contains only that cipher suite and is encoded as an int.  The processing steps are detailed below and in wrong-selected. </ins> G_X - the ephemeral public key of the Initiator

Discussion:
Added references to revocation according to final comment.
Separate issue from Stefan's review : "Constrained endpoints SHOULD implement cipher suite 0 or cipher suite 2." The difference between 0 and 1 and between 2 and 3 is only the size of the tag, i.e. the used algorithms are the same. -> I will suggest changing to "URL 0/1 or cipher suite 2/3" or similar.
Relates to . I think this is a good idea.
A proposal in PR
This makes sense to me
I propose we merge this once we converge on
and are very independant. I think 1 and 3 should probably be recommended for transports that can handle 53 byte payloads without significant performance degradation.
There was discussion during the meeting regarding endpoint / device. The current draft use both as a well as implementation. I think device is useful when we talk about "constrained devices" but not otherwise. The endpoint does in general not need to be a "device". It might be software in the cloud or some chip where EDHOC is used on the internal bus.
URL Outline "IDCREDI and IDCREDR are credential identifiers enabling the recipient party to retrieve the credential of I and R, respectively." I will replace this definition with something like: IDCREDI and IDCREDR are used to identify and optionally transport the authentication keys of the Initiator and the Responder, respectively. EAD Is EAD data generated by the application or data that is pre-provisioned or obtained from somewhere. If the former is true I would like to suggest that the specification allows for implementations where all inputs and output that are generated at run time by the application are provided in non-encoded form to the EDHOC implementation. In this way, the interface to the application will be simpler and CBOR encoding and decoding can be completely hidden from the application developer. This applies especially for EAD, see issue . The general question is who is supposed to encode/decode EAD? The application or the EDHOC implementation? As far I understand the specification now only the application knows how to encode and decode EAD. "If the most preferred cipher suite is selected then SUITESI is encoded as that cipher suite, i.e., as an int."

Am I understanding that correctly: If other suites are supported in addition they are not sent, e.g., if the initiator supports suites 1,2,3, where 1 is preferred and selected, 1 is sent as int and 2,3 are not sent? If so I will suggest making this sentence more clear. 6 Error Handling What is the use case for a success error code? Probably it is good to give some example or reference why it is useful to log successes using a predefined error code and encoding. Is logging the only use case for the success error code? For example, my implementation logs many things for debugging purposes. However, I never needed a success error code. The spec says that success error code must not be sent, therefore the sentence "Error code 0 MAY be used internally.." needs to be "Error code 0 MAY be used only internally.."? "ERRINFO can contain any type of CBOR item", see figure 7. Who decides what is the type of the CBOR item? Is this the EDHOC implementation developer? 7 Mandatory-to-Implement Compliance Requirements "Constrained endpoints SHOULD implement cipher suite 0 or cipher suite 2." The difference between 0 and 1 and between 2 and 3 is only the size of the tag, i.e. the used algorithms are the same. -> I will suggest changing to "URL 0/1 or cipher suite 2/3" or similar. Error messages with which error codes are mandatory to implement? Is only an error message with ERRCODE 2 mandatory to implement? Implementation consideration "The selection of trusted CAs should be done very carefully and certificate revocation should be supported." Is OCSP (RFC6960) what should be used for certificate revocation checking? How revocation can be accomplished with C509? How OCSP and EDHOC interact? Can OCSP stapling be used with EDHOC? Can we combine OCSP stapling with EAD? Additionally, to verify a certificate the device should be aware of the time, which is often problematic on constrained devices, i.e. when certificates are used the device must have a Real-Time Clock (RTC).
opened to address this review.
Looks good to me. I have just read the PR, not checked how the PR corresponds to the review.

Hi all, please find below my review of draft-ietf-lake-edhoc-12. Best regards, Stefan Outline "IDCREDI and IDCREDR are credential identifiers enabling the recipient party to retrieve the credential of I and R, respectively." I will replace this definition with something like: IDCREDI and IDCREDR are used to identify and optionally transport the authentication keys of the Initiator and the Responder, respectively. EAD Is EAD data generated by the application or data that is pre-provisioned or obtained from somewhere. If the former is true I would like to suggest that the specification allows for implementations where all inputs and output that are generated at run time by the application are provided in non-encoded form to the EDHOC implementation. In this way, the interface to the application will be simpler and CBOR encoding and decoding can be completely hidden from the application developer. This applies especially for EAD, see issue . The general question is who is supposed to encode/decode EAD? The application or the EDHOC implementation? As far I understand the specification now only the application knows how to encode and decode EAD. "If the most preferred cipher suite is selected then SUITESI is encoded as that cipher suite, i.e., as an int." Am I understanding that correctly: If other suites are supported in addition they are not sent, e.g., if the initiator supports suites 1,2,3, where 1 is preferred and selected, 1 is sent as int and 2,3 are not sent? If so I will suggest making this sentence more clear. 6 Error Handling What is the use case for a success error code? Probably it is good to give some example or reference why it is useful to log successes using a predefined error code and encoding. Is logging the only use case for the success error code? For example, my implementation logs many things for debugging purposes. However, I never needed a success error code. The spec says that success error code must not be sent, therefore the sentence "Error code 0 MAY be used internally.." needs to be "Error code 0 MAY be used only internally.."? "ERRINFO can contain any type of CBOR item", see figure 7. Who decides what is the type of the CBOR item? Is this the EDHOC implementation developer?

7 Mandatory-to-Implement Compliance Requirements "Constrained endpoints SHOULD implement cipher suite 0 or cipher suite 2." The difference between 0 and 1 and between 2 and 3 is only the size of the tag, i.e. the used algorithms are the same. -> I will suggest changing to "URL 0/1 or cipher suite 2/3" or similar. Error messages with which error codes are mandatory to implement? Is only an error message with ERR_CODE 2 mandatory to implement? Implementation consideration "The selection of trusted CAs should be done very carefully and certificate revocation should be supported." Is OCSP (RFC6960) what should be used for certificate revocation checking? How revocation can be accomplished with C509? How OCSP and EDHOC interact? Can OCSP stapling be used with EDHOC? Can we combine OCSP stapling with EAD? Additionally, to verify a certificate the device should be aware of the time, which is often problematic on constrained devices, i.e. when certificates are used the device must have a Real-Time Clock (RTC). Stefan Hristozov Department Hardware Security Fraunhofer Institute for Applied and Integrated Security AISEC Lichtenbergstraße 11, 85748 Garching near Munich, Germany Tel. +49 89 32299 86 157 EMAIL URL URL