Subject: Re: [Suit] Separate manifest for the status tracker

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Dec 2021 12:22:42 -0500

Rønningstad, Øyvind wrote:
    > There has been some talk about status trackers decoding manifests. How
    > about creating separate manifests especially for the status tracker
    > (servers) and firmware servers?

I'm not enthusiastic about this.
I think that it gets in the way of properly auditing the manifest.

I also find that we need to have an IETF RFC-specified Status Tracker,
applicatble to greenfields and/or some set of restricted applicability.

    > Is this something that has been considered or discussed?  Thoughts?

It has not been discussed AFAIK.

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

---

From: Rønningstad, Øyvind <[email-masked]>
Date: Fri, 3 Dec 2021 11:02:58 +0000

> I think that it gets in the way of properly auditing the manifest.

How so? Which auditor and which manifest (the status tracker manifest or the device manifest)? All manifests will still be created and signed before distribution. The status tracker might edit the envelope, but this has already been proposed as a mechanism when stripping text, or when pre-fetching payloads.

 > I also find that we need to have an IETF RFC-specified Status Tracker, applicatble to greenfields and/or some set of restricted applicability.

To clarify: Do you suggest that the SUIT WG creates a Status Tracker specification?

Øyvind

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Dec 2021 16:36:19 -0500

> How so? Which auditor and which manifest (the status tracker manifest
    > or the device manifest)? All manifests will still be created and signed
    > before distribution. The status tracker might edit the envelope, but
    > this has already been proposed as a mechanism when stripping text, or
    > when pre-fetching payloads.

The purpose of the audit is to record what was sent to the devices to use.
If there is a different manifest for each, then that gets means that the
wrong thing is recorded.

    > To clarify: Do you suggest that the SUIT WG creates a Status Tracker specification?

Yes.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 10 Dec 2021 11:43:11 +0000

Hi Øyvind,

As part of the Mcuboot project we have spoken about decoding the SUIT manifest on the status tracker client and then using the decoded output as input to Mcuboot. The benefit of this approach would be to avoid having to change Mcuboot bootloader.

We have, however, not spoken about the idea of decoding the manifests at the status tracker server. This would also be an option. I do, however, wonder whether any change would be needed to a SUIT manifest. The status tracker would have to know about the firmware versions and other meta-data to fetch referenced payloads.

Ciao
Hannes
From: Suit <[email-masked]> On Behalf Of Rønningstad, Øyvind
Sent: Monday, November 29, 2021 2:12 PM
To: suit <[email-masked]>
Subject: [Suit] Separate manifest for the status tracker

There has been some talk about status trackers decoding manifests. How about creating separate manifests especially for the status tracker (servers) and firmware servers? This would also potentially solve the problem of signed recipient lists (the entire list can be signed in the status tracker manifest). We could potentially define directives especially for these purposes, such as directive-push ("opposite" of fetch), directive-notify (notify a device of a new update), directive-publish (make a payload available at a URI). This would for example allow creating a manifest which instructs the status tracker (or firmware server) to
1.       Fetch all the relevant payloads.
2.       Push subsets of the payloads to different devices on the network. If directive-push takes a list of payloads, it would allow the status tracker to construct a manifest with these payloads as integrated payloads.
This would save bandwidth compared to having to download a separate package (envelope) for each device.

Is this something that has been considered or discussed?
Thoughts?

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