Subject: Re: [Suit] Packed CBOR

From: Brendan Moran <[email-masked]>
Date: Wed, 2 Sep 2020 15:29:46 +0000

> On 10 Aug 2020, at 17:14, Michael Richardson <[email-masked]> wrote:
> Brendan Moran <[email-masked]> wrote:
>
>> 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.

As mentioned in SUIT meeting, I think we all agree that waiting is pretty much untenable at this point. I think we should move forward with what we have and change things if and only if we can prove any of:

1. Smaller encoding
2. Smaller code size
3. Lower complexity

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

Agreed.

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

Yes, this is complicated. I think that a manifest would have to be considered illegal if it did not specify the OOB manifest in some way. Either IANA registry, or URL, or something else.

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

I think option 2.b is even better: do nothing and attempt to prove whether or not there’s enough benefit to justify a v2.

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

I would leave it out and use it as an excuse for v2. I’ll have a look at the version text and see if there’s something that makes sense to add about version mismatches. There’s already some text in “required checks."

Brendan
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
> -= IPv6 IoT consulting =-

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: Carsten Bormann <[email-masked]>
Date: Wed, 2 Sep 2020 17:51:03 +0200

> It might be worth some text in 8.6.1 about what to do if you see Version 2.

I’ll add this to my “versions are stupid” slides:

The version number will be embedded in the packed CBOR, so indicating in the CBOR unpack result that packed CBOR was used is, er, pointless.

Grüße, Carsten