Re: [Cbor] tags for non-CBOR Content-Formats (was Re: I-D Action: draft-ietf-cbor-file-magic-07.txt)

[Michael Richardson <[e-mail]>]

On 2021-12-15 13:38, Carsten Bormann wrote:
> 
> 
>> On 2021-12-15, at 19:24, Michael Richardson <[e-mail]> wrote:
>>
>> Signed PGP part
>>
>>> 3.  The encoded three byte CBOR byte string containing 0x42_4F_52.
>>
>> This is in: https://datatracker.ietf.org/doc/html/draft-ietf-cbor-file-magic-07.txt#appendix-C
>> I see the argument to make this an appendix since it does not tag CBOR
>> content.  I fear that the reviewers and IESG will be confused though.
> 
> We could add more text why this is in an appendix.

I have rewritten the introduction slightly, explaining that the entire 
document is a BCP, but that the appendix is even more "informative"
(Maybe I should say, "speculative", but that feels wrong.  It not that 
we don't think it will work.  It's that we don't know if it's exactly 
valuable)

Please word-smith at:
    https://github.com/cbor-wg/cbor-magic-number/pull/14/files

>> Should it really use CBOR as bytes 8-11, since the content is not, in fact, CBOR?
> 
> The header is.
> 
>> Maybe we should say something else.  I don't feel strongly about this.
> 
> I thought about that, but the tag should be the determining factor; keeping the information in two places invites mismatches.

Carsten makes the case that having two different places to determine the 
content (the 55801 tag, and the tagged content of CBOX vs CBOR) is 
potentially more of a security issue.
CBOX would tell the Human that it was non-CBOR, while the tag could 
disagree.  I think that it also works the other way, where "CBOR" would 
tell the human that it's not a macro-malware infested word file, but the 
tag second tag value (the content-format) says it is.
The argument is therefore that by using a consistent "CBOR", that the 
human gets no information from it, and has to look at the second tag.

I am willing to buy this argument, but I still feel squeamish about it.
I would certainly like to hear from others on this topic.