Subject: [Cbor] 🔔 WG adoption call on draft-richardson-cbor-file-magic

From: Christian Amsüss <[email-masked]>
Date: Tue, 16 Feb 2021 20:18:36 +0100

Hello CBOR group,

This starts a WG adoption call on
<https://tools.ietf.org/html/draft-richardson-cbor-file-magic-01>,
ending on 2021-03-02 (Tuesday before the IETF). Please reply to this
thread by stating support or opposition of the adoption.

Even if you have voiced your opinion in the interim meeting where this
was presented[1], please send something (be it only a "+1") anyway, for
this helps us document the WG's support.

CBOR Chairs
Francesca & Christian

[1]: https://datatracker.ietf.org/meeting/interim-2021-cbor-03/session/cbor

-- 
A beginning is the time for taking the most delicate care that the
balances are correct.
  -- Princess Irulan, Manual of Muad'Dib

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 16 Feb 2021 13:13:22 -0700

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. 

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.

LL

> On Feb 16, 2021, at 12:18 PM, Christian Amsüss <[email-masked]> wrote:
> 
> Hello CBOR group,
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 16 Feb 2021 13:09:35 -0700

+1

---

From: Ira McDonald <[email-masked]>
Date: Tue, 16 Feb 2021 17:27:31 -0500

+1

On Tue, Feb 16, 2021 at 3:17 PM Laurence Lundblade <[email-masked]>
wrote:

> > [1]:
> https://datatracker.ietf.org/meeting/interim-2021-cbor-03/session/cbor
> >
> > --

---

From: Alexander Pelov <[email-masked]>
Date: Wed, 17 Feb 2021 10:02:18 +0100

Dear all,

This indeed seems like a very useful draft !

+1 from me.

On a second note, the document is mentioning "protocol" and "file encoding"
somewhat interchangeably. Maybe I'm missing something here.
Also, I suppose that is obvious, but just to make it clear, it would be
good to put a clarification that this is not a mandatory way of storing
CBOR.

Cheers,
Alexander

---

From: Marco Tiloca <[email-masked]>
Date: Wed, 17 Feb 2021 11:34:29 +0100

+1 for adoption.

Best,
/Marco

On 2021-02-17 10:02, Alexander Pelov wrote:
> On a second note, the document is mentioning "protocol" and "file
> encoding" somewhat interchangeably. Maybe I'm missing something here.
> Also, I suppose that is obvious, but just to make it clear, it would
> be good to put a clarification that this is not a mandatory way of
> storing CBOR. 
>
> Cheers,
> Alexander
>
> On Tue, Feb 16, 2021 at 11:27 PM Ira McDonald <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     +1
>
>     On Tue, Feb 16, 2021 at 3:17 PM Laurence Lundblade
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         +1
>
>
>         > On Feb 16, 2021, at 12:18 PM, Christian Amsüss
>         <[email-masked] <mailto:[email-masked]>> wrote:
>         >
>         > Hello CBOR group,
>         >
>         <https://tools.ietf.org/html/draft-richardson-cbor-file-magic-01
>         <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-richardson-cbor-file-magic-01&data=04%7C01%7Cmarco.tiloca%40ri.se%7C7388e12d31ef46c57a2708d8d322c76c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637491494108393761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=S3gfpH2JOC9O042VAlkS%2BcpDyXzaZ0RW3sWmyqUJqw4%3D&reserved=0>>,
>         <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2Finterim-2021-cbor-03%2Fsession%2Fcbor&data=04%7C01%7Cmarco.tiloca%40ri.se%7C7388e12d31ef46c57a2708d8d322c76c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637491494108393761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yqlMP48KYy%2BeYui%2FOumqiHK6cF2UqIamElCQuzMAdJk%3D&reserved=0>
>         >
>         > --
>         > [email-masked] <mailto:[email-masked]>
>         <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcbor&data=04%7C01%7Cmarco.tiloca%40ri.se%7C7388e12d31ef46c57a2708d8d322c76c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637491494108403715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DH4HeNWECFsMoTicM0tqr0HBUZkEPpyF0FnmtpQuD%2FA%3D&reserved=0>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcbor&data=04%7C01%7Cmarco.tiloca%40ri.se%7C7388e12d31ef46c57a2708d8d322c76c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637491494108403715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DH4HeNWECFsMoTicM0tqr0HBUZkEPpyF0FnmtpQuD%2FA%3D&reserved=0>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcbor&data=04%7C01%7Cmarco.tiloca%40ri.se%7C7388e12d31ef46c57a2708d8d322c76c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637491494108403715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DH4HeNWECFsMoTicM0tqr0HBUZkEPpyF0FnmtpQuD%2FA%3D&reserved=0>
>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Feb 2021 12:11:53 -0500

> encoding" somewhat interchangeably. Maybe I'm missing something here.

Generally, a CBOR Protocol, or CBOR-based Protocol is a way to do something
using CBOR.
The thing using the CBOR (e.g. COSE, or a RATS EAT), is the Protocol, and
that document needs to explain things.

The thing that is sent over the wire, the Protocol, need not include the
entire file encoding. (X509 PEM files are seldom sent over the wire in their
base64 form; TLS and SIME sends the DER, for instance)

That's why the discussion was about CBOR Sequence vs using a Tag to wrap the item.
It seems to me, that a 12-byte CBOR Sequence preceeding the item is really
easy to remove.

    > good to put a clarification that this is not a mandatory way of storing

That's why the intended status is BCP, not standards track.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Feb 2021 12:14:53 -0500

Laurence Lundblade <[email-masked]> 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.

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 18 Feb 2021 10:54:18 -0700

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 <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Feb 2021 15:00:20 -0500

Laurence Lundblade <[email-masked]> wrote:
    > 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?

That's why the CBOR Sequence: if you want the mark in the file, but not on
the wire.

I think that 0xd9d9f6 or 0xd9d9f8 could be used for CBOR Sequence, and it
would also not be valid UTF-8.  While "0xd9" is a valid first byte of a three
byte sequence, 0xd9 is not a valid second byte.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [