Re: [Lake] PRs on encoding clarification and invalid test vectors

[John Mattsson <[e-mail]>]

Hi,

One reason that a receiver may abort non-deterministic CBOR is that it does not support the 6 different ways that you can encode an empty array [] in CBOR

80
98 00
99 00 00
9A 00 00 00 00
9B 00 00 00 00 00 00 00 00
9F FF

The deterministic encoding is 80. While 9B 00 00 00 00 00 00 00 00 is valid CBOR and comply to the CDDL, I don’t think a constrained IoT device should be forced to support that encoding of []. Not sure is makes sense to specify which of the non-deterministic encodings a receiver has to support as the deterministic 80 is the only one that should be produced by a sender.

My experience is that hard requirements on the sender, but loose requirements on the receiver to increased interop is typically how IETF is specified.

Cheers,
John

From: Lake <[e-mail]> on behalf of Carsten Bormann <[e-mail]>
Date: Friday, 8 September 2023 at 13:20
To: John Mattsson <john.mattsson=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Lake] PRs on encoding clarification and invalid test vectors
Doesn’t that essentially split edhoc into those that do and those that don’t?   If it is needed, it should be required, if it isn’t, peers should not fail when not encoded deterministically.  If the two split half’s exist for some other reason, that should be identified.
Sent from mobile, sorry for terse


On 8. Sep 2023, at 10:52, John Mattsson <john.mattsson=[e-mail]> wrote:
- “Implementations MAY abort the EDHOC session if the received EDHOC message is not encoded using deterministic CBOR.” instead of the unnecessary hard SHOULD abort.