Re: [Cbor] Why 0x42_4F_52 (was Re: đź”” WG adoption call on draft-richardson-cbor-file-magic)

Laurence Lundblade <> Thu, 18 February 2021 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C00EF3A14EA for <>; Thu, 18 Feb 2021 09:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cYC0d2ru5cKO for <>; Thu, 18 Feb 2021 09:54:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F08043A14EB for <>; Thu, 18 Feb 2021 09:54:20 -0800 (PST)
Received: from ([]) by :SMTPAUTH: with ESMTPSA id CnVKlS9J283D5CnVLlFsU4; Thu, 18 Feb 2021 10:54:19 -0700
X-CMAE-Analysis: v=2.4 cv=Zvwol/3G c=1 sm=1 tr=0 ts=602ea9cb a=4DuQCvq92BI7+Z+mmVs66w==:117 a=4DuQCvq92BI7+Z+mmVs66w==:17 a=5KLPUuaC_9wA:10 a=l70xHGcnAAAA:8 a=K6EGIJCdAAAA:8 a=pgNmDYIjd2zDil1ph7EA:9 a=qHcT1re5ZPoUIIuL:21 a=YR5Rf2U2mYsNXcnI:21 a=QEXdDO2ut3YA:10 a=OtUnAxWI_jP0onrw:21 a=8doZxKOd6i1UGKQG:21 a=fTgGnNw0R84INVNt:21 a=_W_S_7VecoQA:10 a=JtN_ecm89k2WOvw5-HMO:22 a=L6pVIi0Kn1GYQfi8-iRI:22
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3E14CC92-42AE-4631-A04B-B6EF0158B406"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 18 Feb 2021 10:54:18 -0700
In-Reply-To: <10561.1613668493@localhost>
To: Michael Richardson <>
References: <YCwajOdK//> <> <10561.1613668493@localhost>
X-Mailer: Apple Mail (2.3608.
X-CMAE-Envelope: MS4xfEG7KE84o7NRCpLlgDhKbWr/kpTaZlo1Ryr3kW0NuQH0bryoFxFCrctgotzi60W7/lf/0b6cED/8JioBU4WgdI2ZW6nzjPlLI+XAozIfqV10QuocRCY5 dS9pa4VmKC51b6w4FqqONa9asLCI1P07Asana/7+KPRjijm7JZJkvTwqDUWZACkacaNANyHCDXaq4C7SpaOPgeGjxVEMPnQmREbuEzr4BwIUdTsK4ToLfSW7 CdR+Td12RP19f7wqgqfRFQ==
Archived-At: <>
Subject: Re: [Cbor] =?utf-8?b?V2h5IDB4NDJfNEZfNTIgKHdhcyBSZTogIPCflJQgV0cg?= =?utf-8?q?adoption_call_on_draft-richardson-cbor-file-magic=29?=
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: Thu, 18 Feb 2021 17:54:23 -0000

OK. Understand 0x42_4F_52 now. Thx.

Here’s the tagging of some common EAT usage on the wire:

{…claims…}  An untagged UCCS (an unsigned CWT/EAT)
601({…claims…})A tagged UCCS (an unsigned CWT/EAT)
61(18([…COSE-signed with claims payload…])) A CWT that is an EAT that uses COSE signing and is fully tagged
[…COSE-signed with claims payload…] A CWT that is an EAT that uses COSE signing and is fully untagged

601 is the UCCS tag, 61 is the CWT tag, 18 is the COSE_Sign1 tag. There is (so far) no tag indicating something is an EAT rather than a CWT. How do these tags related to the tag in the magic number?  I’m not sure yet.

The tag in the magic number seems more about dispatch to a file handler the way file extensions are used. 61, 601 and 18 are more about protocol characteristics, so maybe there is no relation at all. Maybe we define a new tag that indicates the file is an EAT and that is never sent over the wire? 

Or should the magic number tag be 601 or 61?


> On Feb 18, 2021, at 10:14 AM, Michael Richardson <> wrote:
> Laurence Lundblade <> wrote:
>> Can you say why part 3, 0x42_4F_52, is added? The only reason I can
>> think of is that 55799 is not unique enough.
> Because the two tags have to actually tag something.
> 0x42_4F_52 is "BOR", and encoded as a byte string, puts "CBOR" into the file.
> This is the CBOR Sequence version.
>> If we need it, can it be at the start so that the part 2 tag can be
>> part 3 so you can just hand the end part to protocol decoders for COSE,
>> CWT, CoSWID and so on? With the 0x42_4F_52 in there, you can’t do that.
> In the discussion running up to this document, the question as to whether it
> should be a tag preceeding, or a CBOR Sequence occurred.  I concluded on a
> CBOR Sequence, but last week during the discussion, it seems that both have
> been asked for, and so I guess the document will do that once adopted.
> 55799 will need to be replaced in the CBOR Sequence version with a different
> code which is equally unique and not valid unicode.
> --
> Michael Richardson <>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide