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

Laurence Lundblade <lgl@island-resort.com> Thu, 18 February 2021 17:54 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00EF3A14EA for <cbor@ietfa.amsl.com>; Thu, 18 Feb 2021 09:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYC0d2ru5cKO for <cbor@ietfa.amsl.com>; Thu, 18 Feb 2021 09:54:21 -0800 (PST)
Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08043A14EB for <cbor@ietf.org>; Thu, 18 Feb 2021 09:54:20 -0800 (PST)
Received: from laurences-mbp.gateway.2wire.net ([187.223.244.101]) 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
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <5A6AB2CA-5C4E-476E-A0A1-6B6CCBDA4663@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3E14CC92-42AE-4631-A04B-B6EF0158B406"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Thu, 18 Feb 2021 10:54:18 -0700
In-Reply-To: <10561.1613668493@localhost>
Cc: cbor@ietf.org
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <YCwajOdK//yoqe20@hephaistos.amsuess.com> <5E5A8BB1-CED3-495F-9B71-2EBB34923F5B@island-resort.com> <10561.1613668493@localhost>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-CMAE-Envelope: MS4xfEG7KE84o7NRCpLlgDhKbWr/kpTaZlo1Ryr3kW0NuQH0bryoFxFCrctgotzi60W7/lf/0b6cED/8JioBU4WgdI2ZW6nzjPlLI+XAozIfqV10QuocRCY5 dS9pa4VmKC51b6w4FqqONa9asLCI1P07Asana/7+KPRjijm7JZJkvTwqDUWZACkacaNANyHCDXaq4C7SpaOPgeGjxVEMPnQmREbuEzr4BwIUdTsK4ToLfSW7 CdR+Td12RP19f7wqgqfRFQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/yqm1yYkXEgh3he_e9S045ap_0n0>
Subject: Re: [Cbor] =?utf-8?b?V2h5IDB4NDJfNEZfNTIgKHdhcyBSZTogIPCflJQgV0cg?= =?utf-8?q?adoption_call_on_draft-richardson-cbor-file-magic=29?=
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=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?

LL


> On Feb 18, 2021, at 10:14 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Laurence Lundblade <lgl@island-resort.com> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
>