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

[Laurence Lundblade <[e-mail]>]

I’ve put the text that EAT has profiles CBOR encoding in below.

> On Feb 22, 2022, at 11:09 AM, Carsten Bormann <[e-mail]> wrote:
> 
> 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.

True, but decoders aren’t actually required to so by RFC 8949, right? Second paragraph here <https://www.rfc-editor.org/rfc/rfc8949.html#name-preferred-serialization>.


> 
>> 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),

It’s not just 8 line of code because it requires a floating library and/or floating-point hardware.  That isn’t available in some places. For example some implementations of Arm TrustZone don’t support it.

> but ensures that a standard CBOR encoder cannot be used without supplying encoding options.  Not a smart move.

Seems like it would be dumb for a CBOR encoder to use floating point for the cti claim. Would some really do that?


> 
>> 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.

The serialization that is of the most concern is indefinite lengths for strings and maps. CBOR, COSE and CWT all allow them and there is advantage to use them on the encoding side so they shouldn’t be ruled out.

The decode for them is definitely more work and makes the decoder larger.  For example, indefinite length strings need to be coalesced in to one and that requires a memory allocator or at least more memory management and copying than definite length strings. 

QCBOR’s decode API is the same for indefinite length maps and arrays as it for definite length maps and arrays, but that wasn’t easy to implement. I think some decoders require the protocol implementor to be conscious of the distinction.

I think the indefinite length interoperability problem is not large, because indefinite lengths are rarely used, but it is still something.

I’m open to suggestions on how to better handle this in EAT.

LL




Text from EAT’s profile discussion

7.2.2.  <file:///Users/lgl/Documents/EAT/eat-drafts/master-ref/draft-ietf-rats-eat.html#section-7.2.2>CBOR Map and Array Encoding <file:///Users/lgl/Documents/EAT/eat-drafts/master-ref/draft-ietf-rats-eat.html#name-cbor-map-and-array-encoding>
The profile should indicate whether definite-length arrays/maps, indefinite-length arrays/maps or both are allowed. A good default is to allow only definite-length arrays/maps. <file:///Users/lgl/Documents/EAT/eat-drafts/master-ref/draft-ietf-rats-eat.html#section-7.2.2-1>
An alternate is to allow both definite and indefinite-length arrays/maps. The decoder should accept either. Encoders that need to fit on very small hardware or be actually implement in hardware can use indefinite-length encoding. <file:///Users/lgl/Documents/EAT/eat-drafts/master-ref/draft-ietf-rats-eat.html#section-7.2.2-2>
This applies to individual EAT claims, CWT and COSE parts of the implementation. <file:///Users/lgl/Documents/EAT/eat-drafts/master-ref/draft-ietf-rats-eat.html#section-7.2.2-3>
7.2.3.  <file:///Users/lgl/Documents/EAT/eat-drafts/master-ref/draft-ietf-rats-eat.html#section-7.2.3>CBOR String Encoding <file:///Users/lgl/Documents/EAT/eat-drafts/master-ref/draft-ietf-rats-eat.html#name-cbor-string-encoding>
The profile should indicate whether definite-length strings, indefinite-length strings or both are allowed. A good default is to allow only definite-length strings. As with map and array encoding, allowing indefinite-length strings can be beneficial for some smaller implementations. <file:///Users/lgl/Documents/EAT/eat-drafts/master-ref/draft-ietf-rats-eat.html#section-7.2.3-1>
7.2.4.  <file:///Users/lgl/Documents/EAT/eat-drafts/master-ref/draft-ietf-rats-eat.html#section-7.2.4>CBOR Preferred Serialization <file:///Users/lgl/Documents/EAT/eat-drafts/master-ref/draft-ietf-rats-eat.html#name-cbor-preferred-serializatio>
The profile should indicate whether encoders must use preferred serialization. The profile should indicate whether decoders must accept non-preferred serialization.