CBOR WG Meeting - Interim 10 Wednesday, July 03, 2019, 15:00 - 16:00 UTC Chairs: Francesca Palombini, Jim Schaad Present: 1) Michael Richardson 2) Francesca Palombini 3) Jim Schaad 4) Laurence Lundblade 5) Paul Hoffman * Charter discussion: https://github.com/cbor-wg/charter - Ballot: https://datatracker.ietf.org/doc/charter-ietf-cbor/ballot/ Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 8259) data interchange format to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format. The CBOR working group will update RFC 7049 to deal with existing errata. Security issues and clarifications may be addressed, but changes to the document will ensure backward compatibility for popular deployed codebases. The resulting document will be targeted at becoming a Internet Standard. After that, the CBOR working group will monitor issues found with the CBOR specification and, if needed, will produce an updated document. Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it is useful for protocol specifications to use a description format for the data in CBOR-encoded messages. The Concise Data Definition Language (CDDL) is such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. CDDL has been published as RFC 8610. While this specification has been completed, several new features were raised during the update process that were not included, in order not to delay publication, and to allow publication in the Standards Track. One example of such a feature is the ability to combine multiple CDDL files together using a mechanism other than manually concatenating them together for processing. The working group will collect these features as well as other features that are raised by users of CDDL, evaluate their utility and add to a second edition of the specification as warranted. The working group will define the approach to further evolving CDDL as a sequence of editions, which might also add further extension points, probably as part of the introduction of the next edition of the CDDL base specification. The body of existing specifications that make use of CDDL is considered precious, and the WG will set out not to damage their value. The working group will evaluate the necessity of providing advice and guidance for developers using CBOR and CDDL. It is currently expected that this would be done using a Wiki of some type. This work would not be expected to be published by the IETF. There are a number of additional CBOR tagged types and CBOR related media type specifications that are currently adopted by the working group, are work items in other working groups, or exist as individual submissions. Additionally, there are expected to be other such documents that will come to the attention of the working group. In some cases, the working group expects to adopt and publish these proposals. The working group will evaluate such proposal individually and decide about addition of a respective milestone. Proposals that are deemed to be out of scope for the working group, e.g. because they are too narrow purpose specifications, may still be published as individual submission or in another groups if there is a specific need. The CBOR group will review these proposals on request. MCR: YANG work that is now on CoRE? Does the charter excludes it? JS: Does not exclude it, don't know if we want to work on this, but we can discuss it. AP Chairs: Update the text with both final edits and Alexeys edits and send back * CBOR specification: https://tools.ietf.org/html/draft-ietf-cbor-7049bisCBORBis Cleared out the PR and produced v-06. Newest part is the merged security considerations. Should include Laurence's input. Unfinished: issue #86. Merged PR18 that had input on tag validity, but some text should be decided on. PH: I don't mind that we check some and not others. CB: why the difference between checking on MIME and CBOR embedded ? MCR: MIME: we are checking that the encoding is valid, not the content CB: we could say "CBOR embedded needs to be "well-formed for it to be valid" LL: should we say "MUST be conformant with the MIME standard" (RFC 2049) CBOR is different since this is the CBOR spec CB: we would get ourselves downref because MIME is draft standard CB: CBOR validity based on tag being well-formed? LL: yes. At least well-formed, maybe even valid. PH: well-form is good. JS: well-formed is sufficient. AP Authors to implement this issue #77 JS: wasn't this discussed last meeting? 77 -> would be good with webauthn people feedback. Editorial clarification that this is one way of doing it and we are not necessarily recommending this particular way. Write a proposal and bring to the list. Authors need to do the changes from issues left, will bring to the list if anything comes up that needs more discussion. LL: looked over security considerations, initial comments: not very happy with strict mode, seems like it's claiming security properties it shouldn't be claiming. "security context" is not good wording. confused about scrict mode valid, invalid, well formed. Will comment on those in more detail. CB: validity checking decoding different from enforcing preferred deterministic encoding. JS: does this relate to issue #45 CB: no, strict mode is about validity checking at the CBOR level. JS: anything else that needs to be discussed? CB: no. PH: open new issue on re-reading strict mode. * CBOR Array Tag: https://tools.ietf.org/html/draft-ietf-cbor-array-tags - Status update (v-05) - No WGLC repeat is needed - Start shepard writeup following submission deadline - AP Jeffrey and Laurence to check the their reviews are addressed * AOB LL: new draft for RATS, would like to get feedback FP: post to the ml - next 2 interims cancelled (Jul 17, 31). Next interim after IETF105 Aug 14. - Agenda call to come soon