I’ve put the text that EAT has profiles CBOR encoding in below.
> On Feb 22, 2022, at 11:09 AM, Carsten Bormann <c...@tzi.org> wrote:
>
> On 2022-02-22, at 18:08, Laurence Lundblade <l...@island-resort.com> 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.
_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
