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

[Carsten Bormann <[e-mail]>]

Hi Christian,

I didn’t originally follow this thread, so I’m going to go through this sequentially.

> On 2022-02-22, at 14:19, Christian Amsüss <[e-mail]> wrote:
> 
> Hello file-magic authors,
> 
> as part of my shepherd write-up I'm reviewing the altest file-magic
> document as it is passing working group last call. All these comments
> are (presumably) editorial in nature and do not alter that outcome.
> 
> * "for each major type of object that they might store on disk": It is
>  not used as a proper name, but "major type" might ring the bell of
>  "first 3 bits" of CBOR, which AIU is not intended here.
> 
>  (Suggestion: "for each kind of object that they might store on disk").

(Already in MCR’s PR.)

> * 5.3: At latest here,

IANA Considerations text is not really meant to have technical content, so I wouldn’t want to add text 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 think I understand now that the 5.3 tags can be used with either
>  2.2, 2.3 or C (55899, 55800 and 55801),

The 5.3 tags can be used for a lot of other purposes.  For instance, we forgot to define CBOR tags for SenML.  This is now remedied by virtue of having defined Content-Format numbers.

> but
> 
>  * 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)

Right.
Actually, the CBOR data item in the content format is used as the tag content of the ct tag.  (5.3 does not mention this case, sigh.)

>  * 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)

The tag content is ‘BOR’.

>  * 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)

Again, the tag is on byte string ‘BOR’.

>  If all these should be allowed, I think this should be spelled out
>  somewhere -- otherwise the examples appear to be conflicting.

Yes.
I made a significant editorial round to get this captured.

Please see: https://github.com/cbor-wg/cbor-magic-number/pull/17

> * (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).

Yes.

So it is better to take off the cbor-magic label before concatenating.
More text in the above PR.

>  Have BOMs caused issues in the past?

(Does it hurt when you hit your head with a hammer?)

> If so, would you care for grave
>  words we can haul against those who repeat inner-BOMs with CBOR?

This is not a BOM, please don’t say that word in polite company.
I think that the wording in the PR is describing the need and when it occurs.

> * A.1: This appears to be in direct conflict with the 2.2.1 example
>  (where the same tag is used with a non-bstr content). By the above the
>  limitation to bstr may still make sense, but only in the context of a
>  55800 or 55801 tag (but there, the tagged value is always not only
>  bstr but even precisely 'BOR'). Maybe the example would be clearer if
>  it would reference one of 2.2, 2.3 and appendix C.

I put some more explanation in the draft, but maybe looking at the examples again is next.
> 
> Best regards
> Christian
> 
> -- 
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>  -- Bene Gesserit axiom