The point that came up in the discussion is how deterministic encoding would work with the extension points.
I said that it is easy to isolate extension points via encapsulation of an encoded CBOR data item in a byte string — that causes a generic decoder to hand up that byte string (which can then be decoded separately, and which can go into a signature input unchanged). Tuomas noted that the extension points are not very clearly delineated in the document. My personal recommendation would be to make those very explicit (*). I maybe didn’t understand part of the discussion; it seemed that you currently require something of your JSON libraries that is much less widely implemented than canonical/deterministic encoding in CBOR libraries. I do understand that this change requires work in implementations. I cannot comment on whether getting this right or getting this done quickly is more important. Grüße, Carsten (*) My personal recommendation would also be to define the data structures and their extension points using some formal technique. Independent of whether they are JSON or CBOR, CDDL (RFC 8610) fits the bill. > On 2020-07-31, at 09:51, Carsten Bormann <c...@tzi.org> wrote: > > On 2020-07-31, at 09:25, Aura Tuomas <tuomas.a...@aalto.fi> wrote: >> >> That is, my biggest concern with both JSON and CBOR is (4) the lack of >> canonical binary serialization. IN EAP-NOOB, we need to receive a serialized >> data message, extract some fields and subtrees, compose an HMAC input out of >> these parts of the data, and reliably compute always the same HMAC on it. >> The easy but flawed implementation would be to decode the received message, >> extract the selected parts, and then re-encode them, but the lack of >> canonical encoding means that the resulting byte string could be different >> in different encoder/decoder implementations. > > rfc7049bis (in IETF last call, ends 2020-08-14) provides rules for > deterministic encoding (called canonical in RFC 7049). > I am not a big fan of protocols that require its use, but if that is your > design, CBOR has the support. > > Grüße, Carsten > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
