Re: [Cbor] [COSE] CBOR magic number, file format and tags

Carsten Bormann <> Thu, 21 January 2021 14:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86BBD3A0EF0 for <>; Thu, 21 Jan 2021 06:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oSEmA6_E0NSU for <>; Thu, 21 Jan 2021 06:39:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD9053A0EEF for <>; Thu, 21 Jan 2021 06:39:02 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4DM4lT1LvJzybr; Thu, 21 Jan 2021 15:39:01 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_54F80D7F-2967-48D5-AEB4-0F5ED6F10532"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <1641.1611237619@localhost>
Date: Thu, 21 Jan 2021 15:39:00 +0100
X-Mao-Original-Outgoing-Id: 632932739.67961-13e5da070e86db1065d3275b6f854c63
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <10306.1611186961@localhost> <> <14857.1611195109@localhost> <> <> <1641.1611237619@localhost>
To: Michael Richardson <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] [COSE] CBOR magic number, file format and tags
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, 21 Jan 2021 14:39:07 -0000

On 2021-01-21, at 15:00, Michael Richardson <> wrote:
> My take right now is that you:
> 1) prefer a CBOR Sequence

I actually was proposing two different approaches, one for magic-numbering CBOR data items (like the 55799 does today) and one for CBOR sequences.
But, of course, data items are just CBOR sequences of length 1, so they can easily be used in a CBOR sequence-only proposal.

> 2) prefer a per-protocol CBOR Tag around something.
>   * c"bor" or C"BOR" would seem to be the right strings here!

Well, “cool” (a byte string of length three, as well :-), but maybe not adding much.

> 3) probably prefix it all with Tag number 55799.

Not sure that is needed, but we could use it.

> Tag<55799>Tag<Protocol>C"BOR"
> 3-bytes   5-bytes      4-bytes   = 12 bytes, with the relevant magic number
>                                   being the first 8-bytes


This has the advantage that:

— we are still using the tag registry to register protocol tags
— the prefix is recognizable as a magic number prefix (the first four bytes and byte 8 to 11 are the signature)
— we are using up 1+4-byte tag numbers, which there are plenty.

So an implementation cat remove that magic number from a file with a single CBOR data item or CBOR sequence that is following, keeping an efficient on-the wire format.  And it would be possible to more or less indiscriminately slap the magic number on any CBOR on-disk format.

Nice.  A single proposal that covers everything, at the cost of 12 bytes of magic number.

> So in section 6, in the case where the CBOR Tag registry is used, then there are two options I
> thought of:
> 1. allow requesters to select their own four (32-bit) or eight (64-bit) tags, from the First Come First Served Registry, using the existing instructions.

Adding the eight-byte version complicates things slightly, but could be done, too (there are two magic number signatures, then).

> 2. amend the IANA instructions for {{RFC8949}} and carve out a 30-bit chunk of the four byte registry,
> or a 32-bit chunk of the eight byte registry.

In which case the 55799 antics and the <<‘OR’>> would be a bit redundant.
(We would need to update the registry to do this carve-out, I think; registering a billion tags would also do a carve-out but then we can’t use the normal registry process to do the allocation.)

> While in many cases CBOR encodings strive to be as compact as possible, for the purposes of a magic number registry for objects stored on disk, the use of between eight and twelve bytes is acceptable.

In particular if it is easy to remove…

Grüße, Carsten