Focusing in here on CBOR encoding:
I can. The decoding of indefinite length strings requires a memory allocator or some strategy to coalesce string chunks. The COSE payload, which must be hashed, could be many independent string chunks. COSE header parameter values could be lots of string chunks. However you do the coalescing or processing, it is going to be more code and it is something people may not always implement. My t_cose implementation of COSE doesn’t support indefinite length strings yet.
It’s true that many CBOR implementations are able to decode both definite and indefinite length encodings. That may or may not translate to all receivers of EAT, CWT and COSE being able to decode both because the decoder APIs for indefinite are sometimes different from definite and for the need of things like string chunk coalescing. However, this is about hard specification in the EAT document, not about what’s commonly implemented. If we want the EAT standard to give 100% guaranteed interoperability, the EAT document would have to be 100% specific about requirements for use of definite and indefinite lengths. Do we want to do that in EAT?
None of the CBOR-based protocols I know of (CWT, COSE, CoSWID, SenML) specify this. It is not the practice today. The specification of these protocols thus does not 100% guarantee interoperability. As Toeless says, "As you say, This is not specific to this draft, but IMHO applies to all similar cases of profiles, and yes, the IETF has not been particularily good about it…" Should EAT be the first? I don’t think so for the reasons that these two encoding options were created in the first place. If we require decoders to support both, then we handicap decoders on small devices. If we require encoders to support only definite length, we handicap encoders on small devices. Attestation is definitely something we want to support on constrained devices. That said, on the CBOR definite/indefinite length issue I might be happy to go along with a consensus for “MUST…”, but not on crypto algorithms. For example, I do not think this EAT draft should say “a receiver MUST implement all of ES256, ES384 and ES512 and the sender MUST restrict themselves to only these algorithms.” I think this would cripple the security of the EAT standard long term because it can’t adapt as algorithms evolve. We shouldn't make this with a MUST in the EAT draft for the same reason COSE and CWT didn’t. We could address much of this with a MUSTs in an IETF standardized EAT profile. I’ve thought about starting work on one. MUST is OK in an EAT profile because there can be more than one over time as crypto changes and such. LL |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
