Re: [Suit] How are firmware and firmware versions expressed in manifest?

[Michael Richardson <[e-mail]>]

Hannes Tschofenig <[e-mail]> wrote:
    > * Finally, there is also a version condition. This allows to express
    > that a manifest is applicable to one or multiple versions of the
    > firmware. As described in the information model draft, this situation
    > occurs when you upload an application that relies on existing software
    > to be present on the device. (Think of it as an API version.)

    > It is important to note that the manifest is not meant to be used to
    > describe the software running on the device. This is the job of other
    > tools, such as COSWID. The manifest instead provides instructions on
    > how to update firmware and to accomplish secure boot.

There are some efforts to include RFC8520 (MUD) definitions into the
Manifest, either by value or reference. (Henk!)

There are other efforts to include CoSWID into RFC8520, I think.
I may be mistaken as to the direction of the arrows here.

    DB> I'm hoping to use the manifest as a virtual SBOM. Will let you know
    DB> if I'm successful in this regard.

The manifest could include a reference to a SBOM, but I don't think it is
reasonable to to include it by value.  I think that the right place to get
the SBOM is via an RFC8520 (MUD) object.

I think that it would help if SUIT considered how some BCPs and/or
Applicability statements that helped to tie some things together.
(Specifically, from the charter:
       This group will not define any new transport or discovery mechanisms,
       but may describe how to use existing mechanisms within the architecture.
)
A lot of Enterprises would like to cache all firmware contents somewhere
locally, avoiding external access for devices.  There is an overlap here
with processes that might report on success updates, caching the new SBOMs
into an audit system, etc.

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