Re: [Suit] SUIT rechartering: proposed text

[Michael Richardson <[e-mail]>]

Russ Housley <[e-mail]> wrote:
    > Putting the text provided by Brendan and a bit of context to the work
    > that has alrady been done by the WG, I propose the following re-charter
    > text.

I guess my only comment is that the wording and the tense does not reflect
the work that has already been done.

    } The SUIT WG has focused on defining a firmware update solution,
    } that took into account learnings from RFC 4108 and other proprietary
    } firmware update solutions. The solution is usable on Class 1 (as defined
    } in RFC 7228) devices, i.e., devices with ~10 KiB RAM and ~100 KiB
    } flash.  The solution easily applies to more capable devices as well.  The
    } SUIT WG has not defined any new transport or discovery mechanisms, but
    } is still considering how to use existing mechanisms within the architecture.

...

    > The SUIT WG was already completed work on two documents: * An IoT
    > firmware update architecture that includes a description of the
    > involved entities, security threats, and assumptions.  * An information
    > model for the SUIT manifest.

    } Now that the information model is complete, and the SUIT WG has
    } selected the CBOR serialization formats and the associated COSE
    } cryptographic mechanisms to encode the SUIT manifest, the SUIT WG will
    } now consider a small number of additional formats in the future.
    } However, to reduce the complexity of a firmware management solution, a very
    } small number of formats is preferred. To support a wide range of
    } deployment scenarios, the formats have been designed to be expressive enough
    } to allow the use of different firmware sources and permission models.

no change:
    > The SUIT WG does not aim to create a standard for a generic application
    > software update mechanism, but instead the SUIT WG focus on firmware
    > development practices in the embedded industry. Software update
    > solutions that target updating software other than the firmware
    > binaries (e.g., applications) are also out of scope.

    > To support the SUIT manifest format, the SUIT WG will also define
    > formats and protocols that enable a Status Tracker to determine if a
    > particular manifest could be successfully deployed to a device and
    > determine if an operation was successful.

:
    > The SUIT WG will specify names or numbers will enable the use of SUIT
    > manifests, their precursors, and their successors within existing or
    > future protocols.

I don't know what this means anymore.

    } The SUIT WG continutes to maintain a close relationship with silicon
    } vendors and OEMs that develop IoT operating systems.

    > The SUIT WG aims to publish several additional documents, namely: * A
    > SUIT manifest format specification using CBOR.  * A firmware encryption
    > specification for use with SUIT manifests.  * A secure for IoT device
    > to reporting on firmware update status.  * A SUIT manifest extension to
    > include a MUD file as defined in RFC 8520.

Maybe past tense for some of these?

I think that at this point, we need some explanation of why the WG isn't done
yet.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


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