Re: [Cbor] Updated Drafts for dCBOR I-D and Gordian Envelope Structured Data Format I-D & IANA Tag Registration

[Wolf McNally <[e-mail]>]

Errata:

#202(1) in our current implementations represents the predicate `id`; a unique identifier of some kind for an object. The predicate in this case doesn’t specify the form of the object; it simply declares that when it appears as the predicate of an assertion that the assertions' object is a unique identifier of the subject, for example:

> On May 31, 2023, at 4:33 PM, Wolf McNally <[e-mail]> wrote:
> 
> Carsten,
> 
> First just to reiterate our tag requests in this thread:
> 
> | code point | data item | semantics |
> |:----|:-----|:-----|
> | #6.200 | multiple | envelope; see section 3.1 |
> | #6.201 | array | assertion; see section 3.3.3 |
> | #6.202 | uint | known-value; see section 3.2.2 |
> | #6.203 | multiple | wrapped-envelope; see section 3.3.2 |
> | #6.204 | bytes | elided; see section 3.2.5 |
> | #6.205 | array | encrypted; see section 3.2.3 |
> | #6.206 | array | compressed; see section 3.2.4 |
> 
> (1) These tags represent the top-level envelope #200 and six of envelope’s eight case arms, the ones not requiring new tags being `leaf`, which is tagged #6.24 as it’s just wrapped CBOR, and `node`, which is encoded directly as a CBOR array. The main function of the top-level tag is being able to direct parsing from from a single, universally-recognized tag for “envelope”. Inner tags are used to distinguish the other seven case arms of envelopes, which are not sufficiently disambiguated by their CBOR data item: for instance three of the case arms: `assertion`, `encrypted`, and `compressed`, are also conveyed as CBOR arrays, and `leaf` could be *any* dCBOR encoding including arrays, int, or whatever. So relying purely on internal structure for disambiguation would be a semantic layer violation.
> 
> Once #200 has been parsed an envelope parser would know that its contents are *some* kind of envelope content, For the other six case arms I considered using existing very short tags for this, like #6.1 through #6.6, which would save a byte, but would interfere with other envelope-naive CBOR parsers that expect tags like #6.1 to represent a date or have other tag-specific semantics. I considered using much larger values that are purely first-come-first-served, but we want envelopes to introduce minimal overhead, and so requesting #200-#206 seems to us to strike a balance.
> 
> Several of these tags are valuable in their stand-alone form, including `known-value` (see discussion below), `elided` (which is just a SHA-256 digest, and for which I found no existing tag), `encrypted` and `compressed`, which are informatively defined in the I-D and implemented in our reference implementations. Our implementations include `EncryptedMessage` and `Compressed` types that directly encode to tagged CBOR as specified without any dependence on the envelope environment; the main additional requirement being that they afford the encoding and verification of a hash, which envelope uses. Hence they and their tags are more generally useful than purely with envelope.
> 
> So we believe these six tags to be a minimal set we’re requesting in the IANA registry, where we have considered the space utility of the tags themselves, respected the limited real-estate of the tag namespace, and considered their usefulness both within the context of envelope as well as their possible utility to others outside the envelope context.
> 
> (2) These are typographical errors: they are holdovers from our previous numbering scheme before they were renumbered in sequence starting with #200, in preparation for our IANA request. Thank you for calling this to my attention, and they will be fixed in the next draft version.
> 
> #221 -> #201 `assertion`
> #224 -> #203 `wrapped-envelope`.
> 
> (3) A “known value” is a namespace of uints we have declared primarily for use with envelope, but which could have uses outside it. They would be administered with a separate registry of known values. A known value tagged #202 can be used by itself, or can be wrapped with #200 and then exist as the subject of an envelope, or as the predicate or object of an assertion. We therefore originally called this namespace `known-predicate`, because when defining semantic structures, a common set of predicates are used frequently, and we realized that having a concise encoding for predicates would be desirable. We realized that this namespace also has other potential use-cases as a space of generalized concepts, so we now call it known-value. We believe this to be a non-overlapping use-case with CBOR tags. We hope popular ontologies may eventually choose to map their defined predicates and other concepts to known values, rather than bloat envelopes with repeated text strings for the concepts they use; of course nothing in the envelope spec stops them from using strings as predicates, or any other envelope for that matter, including envelopes containing their own assertions.
> 
> This also brings us to a simple example of why the double-tagging you asked about in (1) above:
> 
> #203(1) in our current implementations represents the predicate `id`; a unique identifier of some kind for an object. The predicate in this case doesn’t specify the form of the object; it simply declares that when it appears as the predicate of an assertion that the assertions' object is a unique identifier of the subject, for example:
> 
> "Alice" [
>     id: 1234
> ]
> 
> Known values by themselves are not envelopes and may have other uses outside of envelopes, or when passed to other subsystems such as ontology catalogs. On the other hand #200(#203(1)) is a stand-alone envelope with only the subject `id` and no other information, and can be processed by any software that handles envelopes. One can imagine taking such an envelope and then adding a number of assertions to it describing the semantics of the specific predicate, such as the URL at which to access its full schema:
> 
> id [
>     isA: "predicate"
>     dereferenceVia: "https://example.com/ontology/id"
> ]
> 
> In this example, `id`, `isA` and `dereferenceVia` are all known values (note the lack of quotes used for strings in envelope notation), and especially in cases like `dereferenceVia` are going to take far fewer bytes to encode than the full string name, much less a URI.
> 
> (4) I think there may be a misunderstanding here. Crypto-agility is a non-goal of Gordian Envelope; in fact, we feel that crypto-agility is often a huge barrier to understanding and adoption; I think Christopher will have more to say about this. Our main promise, as described in the section on Futureproofing, is that as the crypto landscape changes we are sure that we can update the spec to incorporate additional cryptographic constructs as they become necessary. For now, the only actual normative construct is the hash algorithm: SHA-256. This is due to the intractability of handling envelopes (and hence hash trees) with hashes created by a multiplicity of algorithms. Nothing in the spec requires that a particular construct for encryption (or compression) must be used; it only informatively states what we’re using now. As was indicated in the Futureproofing section, we don’t believe that we need algorithm specifiers in envelope as the only normative algorithm is defined by the spec, and other normative documents will define standards for other constructs as well as ways to disambiguate their envelope encodings. To be clear: the `encrypted` arm of the envelope is *not* a specification for IETF-ChaCha20Poly1305, it is a specification that the envelope is *encrypted* by some means and the only requirement is that it publishes the hash of the plaintext in a verifiable way: nothing more. Likewise the `compressed` arm of the enveloped is *not* a specification for DEFLATE, it is a specification that the envelope is *compressed* and that it publishes the hash of the uncompressed contents.
> 
> Incidentally, I did a comparison between your packed CBOR scheme and the DEFLATE scheme used in the `compressed` arm of Envelope:
> 
>         // This CBOR is encoded based on:
>         // https://datatracker.ietf.org/doc/html/draft-ietf-cbor-packed#appendix-A
>         // Figures 2-3.
>         
>         // Before packing: 400 bytes
>         // After packing:  310 bytes 76%
>         // After DEFLATE:  259 bytes 64%
> 
>         // This CBOR is encoded based on:
>         // https://datatracker.ietf.org/doc/html/draft-ietf-cbor-packed#appendix-A
>         // Figures 4-5.
>         
>         // Before packing: 1210 bytes
>         // After packing:   504 bytes 41%
>         // After DEFLATE:   321 bytes 26%
> 
> (a) The backslashes I added as line continuation characters in order to keep to the I-D linter’s line length requirements for pre-formatted text. Perhaps they aren’t necessary for understanding and I can remove them.
> 
> (b) For many people in the communities we deal with, Gordian Envelope will be their first exposure to CBOR. CBOR’s conciseness is one of its strengths, and I primarily included the CBOR hex examples out of a desire to be abundantly clear about the binary form of the encoding; particularly for people who may be new to CBOR and thinking of adopting envelope. As we approach RFC status, this may be deemed unnecessary and removed.
> 
> ~ Wolf
> 
>> On May 31, 2023, at 10:00 AM, Carsten Bormann <[e-mail]> wrote:
>> 
>> On 2023-05-08, at 19:40, Christopher Allen <[e-mail]> wrote:
>>> 
>>> Gordian Envelope Internet-Drafts, which have been recently submitted to the Internet Engineering Task Force (IETF).
>> 
>> I did a quick skim after today’s meeting.
>> 
>> First a few comprehension questions:
>> 
>> (1) Why do things that already identify themselves as Gordian Elements (tag 201 to 206) need to be tagged again with 200?  Is there any function of this I’m missing?
>> 
>> (2) What is 221? 224?
>> 
>> (3) I don’t understand the way “known values” (Section 6) mix with the things they are predicates over.
>> 
>> Editorial comments:
>> 
>> (a) Some forward slashes probably want to be backslashes.
>> (You don’t need backslashes inside hex values in CBOR diagnostic notation.)
>> Did you check those examples?
>> 
>> (b) I don’t know that you need “CBOR hex” for all the examples, but if you do, can I recommend "CBOR pretty” format?  (Generate with diag2pretty.rb, which is part of the cbor-diag gem.)
>> 
>> Technical comments:
>> 
>> (4) I don’t find the crypto agility that was promised.
>> You probably want to use algorithm identifiers from the COSE algorithms registry (RFC 9053).
>> 
>> Grüße, Carsten
>> 
>