Re: [Suit] Packed CBOR

[Michael Richardson <[e-mail]>]

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.

... given 10 days since this discussion started...
I am enthusiastic about Packed CBOR. But!

    > 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.

And the delay would be hard to predict at this point.
The architecture is up for the call this Thursday, and it seems that the
Information Model ought to follow "suit" (pun intended) very soon.
I believe that we pretty close to done? And I think the market is waiting.

    > It would have benefits:
    > 1. Simplify the manifest structure (complexity moved to packed cbor)
    > 2. Make the manifest smaller

Given that the network impact of firmware is likely dominated by the firmware
itself, saving bytes on the wire does not seem worth the hassle.
As we have a partial solution, how much savings in the manifest itself would occur?

The major benefit in my opinion is really (1).
We get the benefit of research into better compression mechanisms.
This also simplifies the effort on the part of auditing entities to
comprehend the variety of manifests they get.

From the point of view of the third party entities, the out-of-band
dictionary is the archilles of this proposal: will we (SUIT) have a standard
dictionary?  Will it be vendor specific?  Will specific verticals (TEEP)
adopt a dictionary?
Should the SUIT manifest establish a specific CBOR version which it expects
full support for? I think so.

    > 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 2 is the best.
When you say we have re-invented things, do you speak only about Common
(5.4.2 and 8.7.2)?

In the current document, it could be worth adding some text like:
  Future evolution of CBOR may include generic mechanisms to do compression,
  such as [non-normative-reference-to-CBOR-Packed].
  Manufacturers can decide to leverage new mechanisms as soon as the
  devices for which they are providing updates implement the appropriate
  decoders in their update process.

Or maybe we do not say this, but rather this is a reason to bump
suit-manifest-version in the future.
It might be worth some text in 8.6.1 about what to do if you see Version 2.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-