Re: [Cbor] Reminder and call for agenda: CBOR WG Virtual Meeting on 2023-03-08

[Christopher Allen <[e-mail]>]

On Mon, Mar 6, 2023 at 3:02 AM Carsten Bormann <[e-mail]> wrote:
> I can’t speak for the whole community, but I am sure interested in any implications your implementation might have on standardization.
> I think the CBOR meeting at IETF 116 will be a bit cramped for the discussion content we should be having, so doing this at an interim probably works better.

We'd be glad to do so when you are ready (and somewhat relieved not to
have to be in best form at 11pm PDT).

> I don’t know what you are trying to achieve at DISPATCH; this group is for finding the right place for starting new work, not contributions to existing work (unless they are substantial enough to actually amount for new work).

We approached them more about Gordian Envelope, which is not clear if
this group is interested in supporting, but other groups might be, or
it could be a new stand-alone group. Though it only has one
cryptographic operation, a hash function, its purpose is privacy
through elision & proofs of inclusion, thus crossing IETF group
boundaries. In our design, the other cryptographic features are in
different layers and thus could use COSE, mDOC, or other emerging
CBOR-based signature methods.

> > Similarly, is there interest in this community about to discuss about our Gordian Envelope draft https://datatracker.ietf.org/doc/draft-mcnally-envelope/ ? We plan to attend in person the San Francisco IETF meeting and hope there will be sufficient interest in Gordian Envelope for a BOF.
>
> A BOF is a very formal thing in the IETF which takes months of preparation.
> I think you mean what we call a “side meeting” (because the term BOF is taken for that formal thing).
> Side meetings have a heavy multi-track problem, but can draw in people who would not otherwise invest time.
> Such a side meeting probably needs to be announced in groups such as secdispatch and saag — this is a security protocol that just happens to use CBOR (kudos for that, of course).

Thanks — this is what we hoped to learn from Dispatch how to do best.
I was not aware of a separate SecDispatch. I had presumed bringing it
up in SAAG was too broad for us until we could demonstrate more IETF
membership support.

Yes, a side meeting would be great if a BOF is too challenging. Any
advice on how to proceed is appreciated.

> Leafing through the draft, there are a lot of things that might require rethinking in the IETF (say, BLAKE3???).

Thank you for taking a look!

We will have an updated draft -01 this week, based on feedback from
many parties, including one of the co-authors of BLAKE, and have
decided we can't fully take advantage of its capabilities, and thus
will be using SHA-256.

> (At some point we should be talking about assigning the tags that are squatted on by this draft, but maybe talking about the content is first.)

As we understand it, the range of numbers that we've suggested
("squatted on" ;-] ) in our draft only has a "specification required"
requirement, which our I-D offers. There are certainly examples of
others in this range that are not even I-D.

We decided not to apply quite yet in case there were questions. Should
we go ahead and apply now? If there is something missing from the
official docs about the requirements for the assignment of CBOR
numbers in this range by IANA, please let us know.

Of course, what I'd really like is for the CBOR community to fall in
love with Gordian Envelope and let us have one of the precious
remaining 1-byte tags (6–15 and 20 are currently unassigned) as
Gordian Envelope is being used in constrained environments (even
possibly as silicon logic), every byte counts, and this specific tag
(currently requesting 200) is used a lot as the structure is very
recursive.

> Have you looked at SCITT?

I have been monitoring that list, and have pointed to Gordian Envelope
in at least one case. We have people in non-IETF communities
interested in using it for various forms of supply chain and
software/ai data validation.

If there are any others that we should reach out to, please let us know.

Thanks again for your time!

-- Christopher Allen