Change:
Clarification of the optimization of ID_CRED for 'kid',
Merging to include in -18
In , there is I would have expected this to be as per or have I missed something? There is a degree of ambiguity in ` is this refers to the byte string, not necessarily the subset integer equivalent, but the lake-traces would still appear to be wrong.
NAME That looks like a bug. As you can see further down in the same section: ( ? PAD2, IDCREDR / bstr / -24..23, SignatureorMAC2, ? EAD2 ) 32 48 d0 d1 a5 94 79 7d 0a af which is IDCREDR followed by 9 bytes CBOR encoding of SignatureorMAC2. We should also clarify to avoid the ambiguity. Thanks!
I removed the label so we don't forget to also clarify in the spec.
I was too quick making a change in -traces which I had to revert. The implementation is right (of course). So I made a clarification in -edhoc instead, see . Please review.
NAME PR is now merged. Let us know if you have any further comments.
Thanks for the update. When I have some spare time, I am doing a libcoap port. I have now got as far as doing Message_2 as per the traces.
Cool, keep us updated on the progress and if you are interested in interop-testing. Closing this issue then.

Discussion:
ID_CRED_x = { 4 : kid_x }, where kid_x : kid, for x = I or R. <del> The value of a COSE 'kid' parameter is a CBOR byte string.  For a more compact encoding, the CBOR map is replaced by a byte string, see the definitions of plaintext in asym-msg2-proc and asym-msg3-proc. To allow one-byte encodings of ID_CRED_x with key identifiers 'kid', the same representation used for EDHOC connection identifiers defined in bstr-repr MUST be applied. Examples: The CBOR map { 4 : h'FF' } is not encoded as 0xA10441FF but as the CBOR byte string h'FF', i.e., 0x41FF. The CBOR map { 4 : h'21' } is neither encoded as 0xA1044121, nor as the CBOR byte string h'21', i.e., 0x4121, but as the CBOR integer 0x21. </del> As stated in Section 3.1 of RFC9052, applications MUST NOT assume that 'kid' values are unique and several keys associated with a 'kid' may need to be checked before the correct one is found.  Applications

See COSE for more examples. <ins> 3.5.3.1. To comply with the LAKE message size requirements, see I-D.ietf-lake- reqs, two optimizations are made for the case when ID_CRED_x contains a single 'kid' parameter. The CBOR map { 4 : kid_x } is replaced by the byte string kid_x. The representation of identifiers specified in bstr-repr is applied to kid_x. These optimizations MUST be applied if and only if ID_CRED_x = { 4 : kid_x } and ID_CRED_x in PLAINTEXT_y of message_y, y = 2 or 3, see asym-msg2-proc and asym-msg3-proc.  Note that these optimizations are not applied to instances of ID_CRED_x which have no impact on message size, e.g., context_y, or the COSE protected header. For ID_CRED_x = { 4 : h'FF' }, the encoding in PLAINTEXT_y is not the CBOR map 0xA10441FF but the CBOR byte string h'FF', i.e., 0x41FF. For ID_CRED_x = { 4 : h'21' }, the encoding in PLAINTEXT_y is neither the CBOR map 0xA1044121, nor the CBOR byte string h'21', i.e., 0x4121, but the CBOR integer 0x21. </ins> 3.6. An EDHOC cipher suite consists of an ordered set of algorithms from

? EAD_2 ) If ID_CRED_R contains a single 'kid' parameter, i.e., <del> ID_CRED_R = { 4 : kid_R }, then only the byte string is included in the plaintext, represented as described in bstr- repr, see examples in id_cred. </del> <ins> ID_CRED_R = { 4 : kid_R }, then the compact encoding is applied, see compact-kid. </ins> Compute KEYSTREAM_2 as in expand, where plaintext_length is the length of PLAINTEXT_2.  For the case of plaintext_length

? EAD_3 ) If ID_CRED_I contains a single 'kid' parameter, i.e., <del> ID_CRED_I = { 4 : kid_I }, then only the byte string is included in the plaintext, represented as described in bstr- repr, see examples in id_cred. </del> <ins> ID_CRED_I = { 4 : kid_I }, then the compact encoding is applied, see compact-kid. </ins> CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.