On 2022-02-22, at 20:45, Laurence Lundblade <l...@island-resort.com> wrote: >> >>> 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.
Generic CBOR decoders are. You might cook up an application specific decoder for an application that doesn’t need non-preferred encoding, but that would not be a full CBOR decoder. >> >> 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. So what do you do with the lat/lon information then? (The half.c code doesn’t actually need floating-point hardware, BTW, if you manage to do an ldexp in software. But you don’t need to do that if you can’t process the data at all — just keep the undecoded representation then.) >> 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? This discussion was more about lat/lon. cti (label 7) is a byte string, so there is no such problem there. > 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. Right, for data objects that need “streaming” (write to network while still being generated). Not so sure about objects that need to be signed. But your point is that the decision to not allow indefinite length strings may be a significant win for the decoder, so that is a valid case for having an encoding option. But the decoder doesn’t have to know that this option was enabled on the encoder side, so there is no interoperability problem. > 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. (Or you can just use the partial strings in sequence.) > 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. Right, a constrained decoder would usually offer the string segments in an indefinite length string separately. I don’t know what part of the API needed to be different for maps and arrays, but you can sure define one where that is the case. > I think the indefinite length interoperability problem is not large, because > indefinite lengths are rarely used, but it is still something. Well, rarely used is little consolation if your car door doesn’t open :-) > I’m open to suggestions on how to better handle this in EAT. I think you should try not to open the whole smörgåsbord, but only discuss the cases where a significant win can be made. But for something as small as an EAT, maybe restricting strings to definite length might be a valid choice. Grüße, Carsten > > LL > > > > > Text from EAT’s profile discussion > > 7.2.2. 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. > 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. > This applies to individual EAT claims, CWT and COSE parts of the > implementation. > 7.2.3. 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. > 7.2.4. CBOR Preferred Serialization > 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 _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
