Re: [Cbor] Chair review of cbor-file-magic 08

[Christian Amsüss <[e-mail]>]

On Wed, Feb 23, 2022 at 02:08:07PM -0500, Michael Richardson wrote:
>     > * 5.3: At latest here, I'd have expected to read something about the
>     > information that is lost when using this tag with 2.2. Maybe there
>     > should be a line (not for IANA but for users, so maybe in a different
>     > section) that outlines when this works with (non)CBOR content formats
>     > and with which encodings.
> 
> I've tried how to understand this comment, but I'm failing.
> Which information is lost?

I've phrased this badly: The ct encoded in the tag gives information
about the (structured) media type and the content coding. In the 2.2 and
2.3 use cases, the information in the content coding is ... discarded
(should be the word to use rather than lost), if it is acceptable that a
ct for application/mine+cbor@gzip is also used in this tag. Or the
content coding is required to be identity, in which case any
non-identity content coding would be ruled out (just like any non-CBOR
media types are ruled out).


>     >   I think I understand now that the 5.3 tags can be used with either
>     > 2.2, 2.3 or C (55899, 55800 and 55801), but
> 
> good...
> 
>     >   * with 55899 the ct tags can only be used if the content format is a
>     > CBOR content format and coding is identity (and then tags a value)
> 
> 55899 marks CBOR, so the content had better be CBOR.

any tag tags CBOR, so the content needs to be CBOR.

>     > with 55900 the ct tags can only be used if the content format is a
>     > CBOR-sequence content format and coding is identity (and then tags a
>     > byte string)
> 
>     > * with 55901 the ct tags can always be used, and tag a
>     > byte string (which is also encoded according to the coding that is part
>     > of the ct)
> 
> 55901 could be used with any content, because it makes no promise about the content.
> For CBOR encoded things, any of these tags could be used.
> Are you suggesting that we tell people not to use 55901 with CBOR content?

I'm not saying that (and am pretty meh about whether it should be).

I'm just saying that the formalities of defining the tags are complex
(because 55799(ct1234(X)) can take anything for X, whereas
55801(ct1234(X)) takes precisely a bytestring ('BOR'). The text in the
IANA section 5.3 reflect that correctly, and I haven't found text that
sets the rules (rather than implying them).

>     > * (Maybe security) considerations: 3.2 talks of trivially concatenated
>     > data items. If CBOR Tag Sequence is used and the data gets literally
>     > "concatenated", (say, `cat *.cborseq > outfile`), one might wind up
>     > with self-described tags in the middle of the sequence. (As we do with
>     > BOMs).
> 
> I have added:
> https://github.com/cbor-wg/cbor-magic-number/commit/23c4176796d83e4d69ba56ab8a9b7f45cd691272

That sounds like accepting such chains; is that really desirable? It
sounds really messy to me.

> I think that you are having a problem with A.1 wrapping a CBOR thing in
> 55801?

I don't care about what is in a 55801, but the CDDL is confusing because
it is unspecific about which use case it is.

Either this tag is for use with 55800/55801, then it can be `senml-cbor
= #6.1668546672('BOR')` right away.

Or it is for use with 55799, then it needs to be `senml-cbor =
#6.1668546672([*record])` or whatever we use for SenML.

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom