Checking in on prohibition against indefinite length encoding

[laurencelundblade]

I could see a rule where the encoder is allowed to user indefinite length maps and arrays and the decoder must support both definite and indefinite. I think this could save a little object code on some devices with some encoders.

I see no use for indefinite length strings so always prohibiting them seems fine.

See also laurencelundblade/EAT-test-vectors#9 which asks whether invalid tests cases with indefinite lengths should be added to the test vectors for PSA.

[thomas-fossati]

Laurence, thanks for the input!

[...] this could save a little object code on some devices with some encoders.

Could you quantify the code savings?

[laurencelundblade]

For the QCBOR/t_cose/ctoken stack I estimate you could save around 5%, maybe a little more. I don't actually have that stack running. It's just an estimate. That's 100-200 bytes saved out of 3,300 on Intel x86. Presumably, the proportion on 32-bit arm will be about the same. I am assuming there crypto algorithms are already present and not counting them in the 3,300.

[thomas-fossati]

Cool, thanks. It look like something that would be worth having in the ultra constrained space. The cost increase on the receiver is small so on balance I think this is a good suggestion.

[thomas-fossati]

Re: indefinite/definite length rules, we are now aligning with the recommendations in https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-6.3, specifically:

Issue	Profile Definition
CBOR Encoding	Only definite length maps and arrays are allowed
CBOR Encoding	Only definite length strings are allowed