Encoding of ID_CRED_R in lake-traces

[mrdeep1]

In draft-ietf-lake-traces-03, there is

   ID_CRED_R =
   {
    4 : h'32'
   }

   ID_CRED_R (CBOR Data Item) (4 bytes)
   a1 04 41 32

I would have expected this to be

   ID_CRED_R =
   {
    4 : h'32'
   }

   ID_CRED_R (CBOR Data Item) (1 byte)
   32

as per draft-ietf-lake-edhoc-17 Section 3.5.3 or have I missed something?

There is a degree of ambiguity in draft-ietf-lake-edhoc-17 Section 3.5.2

o  If ID_CRED_R contains a single 'kid' parameter, i.e.,
            ID_CRED_R = { 4 : kid_R }, then only the byte string is
            included in the plaintext, represented as described in
            [Section 3.3.2](https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-17#section-3.3.2), see examples in [Section 3.5.3](https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-17#section-3.5.3).

is this refers to the byte string, not necessarily the subset integer equivalent, but the lake-traces would still appear to be wrong.

[gselander]

@mrdeep1 That looks like a bug. As you can see further down in the same section:

PLAINTEXT_2 =
(
? PAD_2,
ID_CRED_R / bstr / -24..23,
Signature_or_MAC_2,
? EAD_2
)

Since ID_CRED_R contains a single 'kid' parameter, only the byte string value is included in the plaintext, represented as described in Section 3.3.2 of [I-D.ietf-lake-edhoc]. The CBOR map { 4 : h'32' } is thus replaced, not by the CBOR byte string 0x4132, but by the CBOR int 0x32, since that is a one byte encoding of a CBOR integer (-19).

PLAINTEXT_2 (CBOR Sequence) (10 bytes)
32 48 d0 d1 a5 94 79 7d 0a af

which is ID_CRED_R followed by 9 bytes CBOR encoding of Signature_or_MAC_2.

We should also clarify to avoid the ambiguity. Thanks!

[gselander]

I removed the label so we don't forget to also clarify in the spec.

[gselander]

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 #371. Please review.

[gselander]

@mrdeep1 PR #371 is now merged. Let us know if you have any further comments.

[mrdeep1]

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.

[gselander]

Cool, keep us updated on the progress and if you are interested in interop-testing. Closing this issue then.