Subject: [Suit] Packed CBOR

From: Brendan Moran <[email-masked]>
Date: Thu, 30 Jul 2020 15:46:13 +0000

On Monday, Carsten presented Packed CBOR (draft-bormann-cbor-packed-00) at the CBOR working group, which adopted it. This is an extension to the CBOR standard (RFC7049) that enables “packing” of CBOR objects using a CBOR-based dictionary compression scheme.

If this had been in draft 18 months ago, the SUIT manifest would have used it instead of the “common” block. The common block is a de-facto packing mechanism that would be largely supplanted by packed CBOR. It simplifies many of the schemes that SUIT already uses and makes the manifest more compact besides.

If we were to adopt it now, this would cause two substantial changes in SUIT:

1. Removing several existing SUIT deduplication mechanisms.
2. Placing a dependency on draft-ietf-cbor-packed-00.

Both of these would delay SUIT.

It would have benefits:

1. Simplify the manifest structure (complexity moved to packed cbor)
2. Make the manifest smaller

I see several options ahead of us:
1. Make no change, apply packed CBOR as and when it makes sense.
2. Make no change now, but plan for a v2 SUIT manifest draft
3. Adopt packed CBOR & simplify manifest now.

Option 1 is somewhat problematic in that it splits the ecosystem we’re trying to create. Option 2 does the same, but provides more benefits. 2 is arguably more detectable, since it’s easier to report manifest v2 support, than to report support for a specific CBOR tag within the SUIT Manifest Processor.

Option 3 delays SUIT both for updates to SUIT itself, and for the dependency on draft-ietf-cbor-packed-00.

If it weren’t for the delays, I’d go for Option 3. With the delays, I’m not sure what the right answer is. 1 & 2 fracture the ecosystem of updatable devices into “haves” and “have nots.”

I plan to discuss this tomorrow at the SUIT meeting.

Best Regards,
Brendan
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Russ Housley <[email-masked]>
Date: Thu, 30 Jul 2020 12:02:55 -0400

Brendan:

Perhaps it is too early to say, but is this CBOR-based dictionary compression scheme likely to be widely supported in CBOR libraries?  To me, the answer to that question weighs heavily on the preferred way forward.

Russ

> On Jul 30, 2020, at 11:46 AM, Brendan Moran <[email-masked]> wrote:
> 
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Brendan Moran <[email-masked]>
Date: Thu, 30 Jul 2020 16:22:31 +0000

Hi Russ,

I really don’t know. I’m not sure if Carsten would have input on that point yet. Of course, if we adopt it, it will force me to support it in my pull parser!

Brendan

> On 30 Jul 2020, at 17:02, Russ Housley <[email-masked]> wrote:
>
> Brendan:
>

---

From: Jim Schaad <[email-masked]>
Date: Thu, 30 Jul 2020 10:51:25 -0700

Two things: 
1.  The CBOR working group has agreed to discuss the packed CBOR, but it has not yet been adopted and would, at a minimum still need to go through an adoption call.

2.  I cannot answer about all CBOR implementations, but I would expect that the ones that I regularly work with are very likely to adopt it.  

There are some ideas around things like dictionaries which have not been thought through with any degree of completeness.   My personal expectation is that 18 months would be an earliest possible date but others may disagree with that.

Jim

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Brendan Moran
Sent: Thursday, July 30, 2020 9:23 AM
To: Russ Housley <[email-masked]>
Cc: suit <[email-masked]>
Subject: Re: [Suit] Packed CBOR

Hi Russ,

Brendan

>> 2. Make no change now, but plan for a v2 SUIT manifest draft 3. Adopt 
>> packed CBOR & simplify manifest now.
>>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 31 Jul 2020 00:03:19 +0200

> 2.  I cannot answer about all CBOR implementations, but I would expect that the ones that I regularly work with are very likely to adopt it.  

Some implementations would only provide the unpacker, some would provide (various complexity levels of) packing as well.  Note that a CBOR library that does not implement any of this still enables doing the pointer-chasing in the application, so the actual coverage may be greater.

> There are some ideas around things like dictionaries which have not been thought through with any degree of completeness.   My personal expectation is that 18 months would be an earliest possible d…

The design space is huge, which tends to slow down development.  I think we will design this in a way that the basic tag 6 packing can be combined with other tags to achieve the more esoteric feature sets.  If we manage to get the interface to these (future) tags right, we might not need those 18 months.  (Anything below 12 months to RFC is certainly unlikely.)

Grüße, Carsten