Re: [Suit] Packed CBOR

[Brendan Moran <[e-mail]>]

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 <[e-mail]> wrote:
>
> 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 <[e-mail]> wrote:
>>
>> 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.
>> _______________________________________________
>> Suit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/suit
>

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.