Original text:
Verification of a common preferred cipher suite: The Initiator lists supported cipher suites in order of <del> preference </del>  The Responder verifies that the selected cipher suite is the first supported cipher suite (or else rejects and states The Initiator needs to have a list of cipher suites it supports in order of preference.  The Responder needs to have a list of cipher <del> suites it supports.  SUITES_I is a CBOR array containing cipher suites that the Initiator supports.  SUITES_I is formatted and processed as detailed in asym-msg1-form to secure the cipher suite negotiation.  Examples of cipher suite negotiation are given in ex- neg. </del>  3.7. The applicability statement may also contain information about supported cipher suites.  The procedure for selecting and verifying <del> cipher suite is still performed as specified by the protocol, but it may become simplified by this knowledge. </del>  An example of an applicability statement is shown in appl-temp. METHOD = 0, 1, 2, or 3 (see fig-method-types). <del> SUITES_I - cipher suites which the Initiator supports in order of (decreasing) preference.  The list of supported cipher suites can be truncated at the end, as is detailed in the processing steps below and wrong-selected.  One of the supported cipher suites is selected.  The selected suite is the first suite in the SUITES_I CBOR array.  If a single supported cipher suite is conveyed, then that cipher suite is selected and SUITES_I is encoded as an int instead of an array. </del>  G_X - the ephemeral public key of the Initiator The Initiator SHALL compose message_1 as follows: The supported cipher suites and the order of preference MUST NOT <del> be changed based on previous error messages.  However, the list SUITES_I sent to the Responder MAY be truncated such that cipher suites which are the least preferred are omitted.  The amount of truncation MAY be changed between sessions, e.g., based on previous error messages (see next bullet), but all cipher suites which are more preferred than the least preferred cipher suite in the list MUST be included in the list. </del>  The Initiator MUST select its most preferred cipher suite, conditioned on what it can assume to be supported by the Responder.  If the Initiator previously received from the Responder an error message with error code 2 (see wrong-selected) <del> indicating cipher suites supported by the Responder which also are supported by the Initiator, then the Initiator SHOULD select the most preferred cipher suite of those (note that error messages are not authenticated and may be forged). </del>  Generate an ephemeral ECDH key pair using the curve in the selected cipher suite and format it as a COSE_Key.  Let G_X be the 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>  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>  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>  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>  about the cipher suites that the Responder supports. In the first example (fig-error1), the Responder supports cipher suites 5, 6 or 7.  To illustrate the negotiation mechanics we let the Initiator first make a guess that the Responder supports suite 6 but not suite 5.  Since the Responder supports neither 5 nor 6, it <del> responds with an error and SUITES_R, after which the Initiator selects its most preferred supported suite.  The order of cipher suites in SUITES_R does not matter.  (If the Responder had supported suite 5, it would include it in SUITES_R of the response, and it would in that case have become the selected suite in the second message_1.) </del>  Note that the Initiator's list of supported cipher suites and order of preference is fixed (see asym-msg1-form and init-proc-msg1).

Reviewer comments:
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

Revised text:
Verification of a common preferred cipher suite: The Initiator lists supported cipher suites in order of  <ins> preference, ending with the selected cipher suite for the session. </ins> The Responder verifies that the selected cipher suite is the first supported cipher suite (or else rejects and states The Initiator needs to have a list of cipher suites it supports in order of preference.  The Responder needs to have a list of cipher  <ins> suites it supports.  SUITES_I contains cipher suites supported by the Initiator, formatted and processed as detailed in asym-msg1-form to secure the cipher suite negotiation.  Examples of cipher suite negotiation are given in ex-neg. </ins> 3.7. The applicability statement may also contain information about supported cipher suites.  The procedure for selecting and verifying  <ins> cipher suite is still performed as described in asym-msg1-form and wrong-selected, but it may become simplified by this knowledge. </ins> An example of an applicability statement is shown in appl-temp. METHOD = 0, 1, 2, or 3 (see fig-method-types).  <ins> 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 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. </ins> G_X - the ephemeral public key of the Initiator The Initiator SHALL compose message_1 as follows: The supported cipher suites and the order of preference MUST NOT  <ins> be changed based on previous error messages.  SUITES_I contains the ordered list of supported cipher suites, truncated after the cipher suite selected for this session.  The selected cipher suite MAY be changed between sessions, e.g., based on previous error messages (see next bullet), but all cipher suites which are more preferred than the selected cipher suite in the list MUST be included in SUITES_I. </ins> The Initiator MUST select its most preferred cipher suite, conditioned on what it can assume to be supported by the Responder.  If the Initiator previously received from the Responder an error message with error code 2 (see wrong-selected)  <ins> indicating cipher suites supported by the Responder, then the Initiator SHOULD select the most preferred supported cipher suite among those (note that error messages are not authenticated and may be forged). </ins> Generate an ephemeral ECDH key pair using the curve in the selected cipher suite and format it as a COSE_Key.  Let G_X be the 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.  <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  <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  <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-  <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 suites 5, 6 or 7.  To illustrate the negotiation mechanics we let the Initiator first make a guess that the Responder supports suite 6 but not suite 5.  Since the Responder supports neither 5 nor 6, it  <ins> responds with SUITES_R containing the supported suites, after which the Initiator selects its most preferred supported suite.  The order of cipher suites in SUITES_R does not matter.  (If the Responder had supported suite 5, it would have included it in SUITES_R of the response, and it would in that case have become the selected suite in the second message_1.) </ins> Note that the Initiator's list of supported cipher suites and order of preference is fixed (see asym-msg1-form and init-proc-msg1).