Change:
cipher suite selected by the Initiator is not supported by the Responder, or if the Responder supports a cipher suite more preferred by the Initiator than the selected cipher suite, see resp-proc-msg1. <del> ERR_INFO is of type SUITES_R: If the Responder does not support the selected cipher suite, then SUITES_R MUST include one or more supported cipher suites.  If the Responder does not support the selected cipher suite, but supports another cipher suite in SUITES_I, then SUITES_R MUST include the first supported cipher suite in SUITES_I. </del> <ins> ERR_INFO is in this case denoted SUITES_R and is of type suites, see asym-msg1-form).  If the Responder does not support the selected cipher suite, then SUITES_R MUST include one or more supported cipher suites.  If the Responder supports a cipher suite in SUITES_I other than the selected cipher suite (independently of if the selected cipher suite is supported or not) then SUITES_R MUST include the supported cipher suite in SUITES_I which is most preferred by the Initiator.  SUITES_R MAY include a single cipher suite, i.e. be encoded as an int.  If the Responder does not support any cipher suite in SUITES_I, then it SHOULD include all its supported cipher suites in SUITES_R in any order. </ins> 6.3.1. After receiving SUITES_R, the Initiator can determine which cipher <del> suite to select for the next EDHOC session with the Responder. </del> <ins> suite to select (if any) for the next EDHOC run with the Responder. </ins> If the Initiator intends to contact the Responder in the future, the Initiator SHOULD remember which selected cipher suite to use until the next message_1 has been sent, otherwise the Initiator and <del> Responder will likely run into an infinite loop.  After a successful run of EDHOC, the Initiator MAY remember the selected cipher suite to use in future EDHOC sessions.  Note that if the Initiator or Responder is updated with new cipher suite policies, any cached information may be outdated. </del> <ins> Responder will likely run into an infinite loop where the Initiator selects its most preferred and the Responder sends an error with supported cipher suites.  After a successful run of EDHOC, the Initiator MAY remember the selected cipher suite to use in future EDHOC sessions.  Note that if the Initiator or Responder is updated with new cipher suite policies, any cached information may be outdated. </ins> 6.3.2. Assume that the Initiator supports the five cipher suites 5, 6, 7, 8, and 9 in decreasing order of preference.  Figures fig-error1 and fig- <del> error2 show examples of how the Initiator can truncate SUITES_I and how SUITES_R is used by Responders to give the Initiator information </del> <ins> error2 show examples of how the Initiator can format SUITES_I and how SUITES_R is used by Responders to give the Initiator information </ins> about the cipher suites that the Responder supports. In the first example (fig-error1), the Responder supports cipher

Discussion:
Addressing
NAME Please check if your comments are addressed.
Yes, especially in [1]. Thanks! [1] URL
-08 contained a definition of CREDx including an example when kid is used. -09 removed that example and replaces it with a RPK by value example. Now it seems like the most important use case is not well specified. This is the use case that leads to message2 being 45 bytes.
In addition the TOFU use case should likely also have a kid. Otherwise the UCCS has to be sent by value every time.
This is solved by just adding a 'kid' in the COSE_Key map
The document should say someting more about COSEKey. If IDCREDx = { 4 : keyidx } identifies a raw COSEKey, is that an error or is CREDx then the COSEKey wrapped in a UCCS without any parameters like sub?
SUITES_R is a name. The type needs to be defined and the table changed. This can be done in PR
The current definition of SUITESI is that the Initiator can chose any truncation of the list of supported cipher suites as long as the selected cipher suite is included. This works and allows the Initiator to give the Responder information about the full list. This is however a bit complex and has led to misunderstandings of the test vectors where several people thought the test vectors were wrong. i.e. the following are all valid I think we should simplify SUITESI by mandating that the last suite in the list is the selected. This makes SUITESI much easier to understand and lowers message size when an array is used. Giving the Responder info is not so important. CDDL
Maybe a recommendation that SUITES_R SHOULD contain all cipher suites that R supports.
Currently SUITESR : [ supported : 2 suite ] / suite We may keep that, or remove "supported" SUITESR : [ 2 suite ] / suite Alternatively, we may define SUITES_I : [ supported : 2* suite ] / suite Any preference?
They should be the same: or And then
This needs to be defined as a CDDL type. suites = [ 2* suite ] / suite See