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

Michael Richardson <> Wed, 12 January 2022 16:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40AB43A13F7 for <>; Wed, 12 Jan 2022 08:35:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.812
X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wt2UTGiaP9RL for <>; Wed, 12 Jan 2022 08:35:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 515A63A13F1 for <>; Wed, 12 Jan 2022 08:35:27 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C664F38C7E for <>; Wed, 12 Jan 2022 11:41:21 -0500 (EST)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id vjKU_o3nvcZb for <>; Wed, 12 Jan 2022 11:41:20 -0500 (EST)
Received: from ( []) by (Postfix) with ESMTP id 5AE7238C7C for <>; Wed, 12 Jan 2022 11:41:20 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1642005680; bh=6q3W+ARCzXWJLkoLrX63uXT02Z22HfsymNfGUfVYRZc=; h=Date:Subject:To:References:From:In-Reply-To:From; b=KiAxsa5+SfN7EcOX4nfw/tfpU8QYptbqjB1q/D1eo7xGSjwFNdRsXYX3GwJKDYemU jUwx66HeJQPeo8A7ngZotXrHg14ziuAVg4cm08e+zfGTIsIhAzH1z2rlI0KVizjIDK OKFqOB8QIwsgwMCOG9RJ0fJsOG6jIJYOwX+kzp6xR45Owux8uC2H+kXmUhmlh6kFx7 0hjYwBlnBZ98VaLRyD3c0Z1XnXDCUnntleKABBXxOiTjCeWgPpFRk8X3ubJlzIJw6Y 9Ae6zuI+1eTbJrpRQ8XChPp/l4Nmf9Ayz1k0rlv85+85Kt3HXBcDIBrbz2TqqOwEtt 4fFGWVoFPWyaw==
Received: from [] (localhost []) by (Postfix) with ESMTP id 181FFA45 for <>; Wed, 12 Jan 2022 11:35:24 -0500 (EST)
Message-ID: <>
Date: Wed, 12 Jan 2022 11:35:24 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
Content-Language: en-US
References: <> <4768.1639592647@localhost> <>
From: Michael Richardson <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Cbor] tags for non-CBOR Content-Formats (was Re: I-D Action: draft-ietf-cbor-file-magic-07.txt)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Jan 2022 16:35:31 -0000

On 2021-12-15 13:38, Carsten Bormann wrote:
>> On 2021-12-15, at 19:24, Michael Richardson <> wrote:
>> Signed PGP part
>>> 3.  The encoded three byte CBOR byte string containing 0x42_4F_52.
>> This is in:
>> 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 

Please word-smith at:

>> 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.