Re: [COSE] [Rats] RAM requirements for COSE/CWT

[Carsten Bormann <[e-mail]>]

On 2022-02-22, at 18:08, Laurence Lundblade <[e-mail]> wrote:
> 
> EAT allows for use of the different CBOR serializations just like COSE and CWT so particular deployments can choose what is best for them. It is important to continue to allow all serializations in EAT for the reasons that they exist in the first place.

This is confusing terminology.
You wouldn’t call putting space after a comma in JSON “different serializations”.
That is just the lenience that the format provides.
The fixed length argument example you give is one of the reasons we put in that lenience in the first place:

> The main example I can think of is EAT in pure HW (e.g., a TPM-like chip that outputs EAT). Outputting fixed length integers will make that HW simpler.

Any CBOR decoder will be happy with decoding this.

> EAT goes one step further than COSE and CWT by pointing out that different serializations can cause interoperability issues

There is only one place I have found so far where EAT actively causes an interoperability issue:  By ruling out preferred serialization for floating point values.  Creating a separate CBOR dialect by ruling out half-precision encoding might save 8 lines of C code in a decoder (which you can simply copy from https://www.rfc-editor.org/rfc/rfc8949.html#name-half-precision), but ensures that a standard CBOR encoder cannot be used without supplying encoding options.  Not a smart move.

> and advises that a profile that specifies the serialization used be created for each use case. (Note that serialization variation is minor compared to algorithm selection and key identification and distribution)

That is highly misleading.

> It seems true to me that there are CBOR serialization variants that would not interoperate. Sounds a little bad and messy...

If you create multiple incompatible variants by restricting the format, you can create non-interoperating dialects.  Don’t do that then.

> In reality, I don’t think it very bad because is very easy to support preferred serialization and because it is possible to create a decoder that supports all the serializations.

Absolutely.  So why do the options game here at all?

> Supporting these serializations doesn’t increase RAM and CPU usage much. We don’t hear any complaining from the real world about this and CBOR is getting close to ten years old.

Grüße, Carsten