CBOR working group conference call, 2022-01-12


Notes: Marco Tiloca, CA

BL starting the meeting

WG documents status and issues

BL: Any WG document to check?
MCR: Yes, file-magic. We should be done, we’re waiting for something (the DT says the write-up)
CA: I’m the shepherd, there was some back and forth at the latest interim. I sent you some sentences to consider for a document to be considered for a 2nd WGLC.
MCR: I need to have a look at the interim notes.
CA: Will also double-check; might be I just have to start the write-up.
MCR: I think you’re right it’s on us.
CB: Last version out was on Dec 15.
MCR: Will look at that.

(discussion continuing later)

CB: asked COSE chairs and ADs about RFC-to-be-9052…54, hoping to get progress there.
BL: I also followed-up as former shepherd; haven’t seen activity for a while though in AUTH48.
CB: Something happened with reminders sent out in December.
(Link: https://www.rfc-editor.org/cluster_info.php?cid=C416 probably)


CB: Good to be able to write a single piece of CDDL describing JSON and CBOR at once. But there can be subtle differences between the two that makes this tricky.
CB: An example is in Appendix A of * https://www.ietf.org/archive/id/draft-ietf-rats-uccs-02.html#name-cddl on how it can be done with .feature. Requires tool support currently being added.
CB: (showing the example over a claims set). Works well for “iss” and other labels; for cti value it doesn’t work that well because it can be a tstr or bstr in CBOR, but only a tstr in JSON.
CB: Think it’s reasonably easy to read and write; structure in JC macro is an idiom that needs getting used to. Three lines (JSON-ONLY / CBOR-ONLY / JC) is what I expect other documents to use. SenML might have used that. Would like to poll CBOR community on whether we want to do it this way (or do it differently, eg. in CDDL 2.0 which could have bespoke feature)
MCR: Is this because we want an integer with CBOR and a string in JSON?
CB: Yes in this particular example.
MCR: And we don’t want to mix them up.
CB: In CWT you can have also text labels, but you’re not supposed to in some relevant cases here.
(side remarks on irrelevance of sequence of CDDL rules; CB’s preferred style is to have boilerplate at end)
IMD (on chat): Seems like a good idea - waiting for CDDL 2.0 sounds too long, probably
MCR (on chat): works for me.
CB: This may be useful in a number of specs hereafter.
CA (on chat): +1 from me (no chair hat); sounds reasonably straightforward
CB: Please all try using this with your concrete use cases.

CA: Would the envisioned annotation features of CDDL 2 allow matching values in JC to each other? (Not a concrete requirement, just “if it works it’d give me confidence in this approach”)
CB: Something like .base64 would be useful. Might risk to go beyond what done in CBOR.

BM: Have been working in SUIT on a draft for which I’d need a generic set of CBOR parse errors, and a more specific set for content validation errors. Is there need for that in general? Is there desire to have that in CBOR WG, and anyone who’d work with me?
MCR: Can you give an example?
BM: Overrun (running out of expected data), type mismatches, integer overflows, integer encoding errors, feature missing (like floating type support or other simple types). Would like to work on a document.
MCR: I’m interested in helping you. Two error categories: “This is invalid CBOR” vs “This doesn’t map to something we have”.
Maybe irrelevant from application, but maybe important to person receiving the error.
CB: Maybe worth remembering we have wellformedness and valididty. Validity is complex. Would also add observation that the kind of error generated depends on imlementation. You may know there is an error but not necessarily what kind of error.
BM: Another axis – type of parser you’re using dicates some of this. A pull parser won’t know about wellformedness until done. Something like COSE validation may want completely different set of errors. For CBOR or for COSE?
BM: Will write that with Michael and send to CBOR, then we’ll see how it goes.
IMD: I think of several applications.
BM: Might be a hierarchical structure.
CB: Interesting to see what HTTP did about it (error classes with specific issues through error codes, both application(eg. 409-Conflict)- and protocol-related). Maybe we’d need to think of a similar structuring. In general, we standardize error numbers when we expect state machines to react differently to different errors (eg. to a 409 there is someething to do with it). Wonder: Which of these could a peer react on? Non-wellformed is probably hard; would be good to have idea of what impls will do with the codes.
BM: SUIT is an interesting case, it’s not typical 2-party communication, there’s at least a relay involved producing some different results. A relay detecting malformed CBOR can react accordingly.
CB: Good to write some of that into document.
CA (on chat): +1 on having described how information will be used
MCR: Also a case for being able to process well formed CBOR, also to cover in the document.

WG documents status and issues (continued)

MCR back to CBOR-tagging-of-things-that-are-not-CBOR

CB: reason for not being happy for changing both tag and content is that then some will check tag and some content, resulting in interop problem. Maybe can be remedied with strong words about semantics being in the tag (but knowing implementers…)
CA: confused … but yeah, there’s outer tag and innermost value, which may conflict (saying something about the tag inbetween).
MCR: Text would clue in humans. Is there an extra clue worth communicating to the human? I think it falls into beauty contest, and I don’t have strong feeling one way or the other.
CB: Human is good example. In security context, attacker will rejoice when humans may misinterpret what’s actually processed. Can live with CBOX too, just pointing out the little effects.

MCR will write an email.

(alternative version from minute takers working at opposite sides of the notes:)

MCR: Looking at the thread, CB had an input (me and IMD not convinced). Opinions?
CB: If you do differently, you can have conflicts in checking tag and content. I believe implementors would focus on the content and not the tag.
MCR: The bstr is relevant since we have to put something there for a human. After the processing of initial bytes, what’s next? Any extra clue for a human? No strong feeling.
CB: Good to involve a human. An attacker would have an easy life in crafting a tag. But I can live with CBOX (and similar), there are just effects resulting from that.
CA (on chat): no preference.
MCR: I’ll send a mail to the list.

[BM]: Brendan Moran
[CB]: Carsten Bormann
[BL]: Barry Leiba
[FP]: Francesca Palombini
[IMD]: Ira McDonald
[MCR]: Michael Richardson
[CA]: Christian Amsüss
[MT]: Marco Tiloca
[PP]: Philip Prindeville
[ST]: Sean Turner