Change:
The new definition of info in th ecurrent specification is. I noticed two problems with this while implementing. To create the array you need to parse context to see how many items it contains. Unless context is validated, length is not strictly defined (an attacker could create collisions) I suggest that info is changed to:
In the exporter, the application using EDHOC could input a context (a encoded CBOR sequence) that is not valid CBOR. That is not a big problem, but might lead to security issues in the future, if is assumed that info is valid CBOR. URL prefered sequence to array. I don't think bstr wrapping the sequence has the same problems as array wrapping the sequence. Array wrapping the info sequence seems like an unesasary step. I suggest.
We have also gotten comments disliking the use of any
Current specification could give the impression that there is a single maclength. But the mac length in message2 and message_3 may be different.
One fix is to update to

Discussion:
Expand, and instantiated with the EDHOC AEAD algorithm in the selected cipher suite. <del> where info is the CBOR encoding of </del> <ins> where info is encoded as the CBOR sequence </ins> where

label is a tstr set to the name of the derived key, IV or MAC; i.e., "KEYSTREAM_2", "MAC_2", "K_3ae", "IV_3ae", or "MAC_3". <del> context is a CBOR sequence, i.e., zero or more encoded CBOR data items </del> <ins> context is a bstr </ins> length is the length of output keying material (OKM) in bytes

using the EDHOC-Exporter interface defined as: where label is a registered tstr from the EDHOC Exporter Label <del> registry (exporter-label), context is a CBOR sequence defined by the </del> <ins> registry (exporter-label), context is a bstr defined by the </ins> application, and length is a uint defined by the application.  The (label, context) pair must be unique, i.e., a (label, context) MUST NOT be used for two different purposes.  However an application can

hash function is a CBOR Sequence.  Note that H(message_1) can be computed and cached already in the processing of message_1. <del> Compute MAC_2 = EDHOC-KDF( PRK_3e2m, TH_2, "MAC_2", ( ID_CRED_R, CRED_R, ? EAD_2 ), mac_length ).  If the Responder authenticates with a static Diffie-Hellman key (method equals 1 or 3), then mac_length is the EDHOC MAC length given by the selected cipher suite.  If the Responder authenticates with a signature key (method equals 0 or 2), then mac_length is equal to the output size of the EDHOC hash algorithm given by the selected cipher suite. </del> <ins> Compute MAC_2 = EDHOC-KDF( PRK_3e2m, TH_2, "MAC_2", << ID_CRED_R, CRED_R, ? EAD_2 >>, mac_length_2 ).  If the Responder authenticates with a static Diffie-Hellman key (method equals 1 or 3), then mac_length_2 is the EDHOC MAC length given by the selected cipher suite.  If the Responder authenticates with a signature key (method equals 0 or 2), then mac_length_2 is equal to the output size of the EDHOC hash algorithm given by the selected cipher suite. </ins> ID_CRED_R - identifier to facilitate retrieval of CRED_R, see

function is a CBOR Sequence.  Note that H(TH_2, CIPHERTEXT_2) can be computed and cached already in the processing of message_2. <del> Compute MAC_3 = EDHOC-KDF( PRK_4x3m, TH_3, "MAC_3", ( ID_CRED_I, CRED_I, ? EAD_3 ), mac_length ).  If the Initiator authenticates with a static Diffie-Hellman key (method equals 2 or 3), then mac_length is the EDHOC MAC length given by the selected cipher suite.  If the Initiator authenticates with a signature key (method equals 0 or 1), then mac_length is equal to the output size of the EDHOC hash algorithm given by the selected cipher suite. </del> <ins> Compute MAC_3 = EDHOC-KDF( PRK_4x3m, TH_3, "MAC_3", << ID_CRED_I, CRED_I, ? EAD_3 >>, mac_length_3 ).  If the Initiator authenticates with a static Diffie-Hellman key (method equals 2 or 3), then mac_length_3 is the EDHOC MAC length given by the selected cipher suite.  If the Initiator authenticates with a signature key (method equals 0 or 1), then mac_length_3 is equal to the output size of the EDHOC hash algorithm given by the selected cipher suite. </ins> ID_CRED_I - identifier to facilitate retrieval of CRED_I, see

COSE constructs the input to the AEAD RFC5116 as follows: <del> Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length ) </del> <ins> Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", h'', length ) </ins> <del> Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length ) </del> <ins> Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", h'', length ) </ins> Plaintext P = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? EAD_3 )

where EAD_4 is protected external authorization data, see AD. COSE constructs the input to the AEAD RFC5116 as follows: <del> Key K = EDHOC-Exporter( "EDHOC_message_4_Key", , length ) </del> <ins> Key K = EDHOC-Exporter( "EDHOC_message_4_Key", h'', length ) </ins> <del> Nonce N = EDHOC-Exporter( "EDHOC_message_4_Nonce", , length ) </del> <ins> Nonce N = EDHOC-Exporter( "EDHOC_message_4_Nonce", h'', length ) </ins> Plaintext P = ( ? EAD_4 )