Re: [Suit] SUIT rechartering: proposed text

[Russ Housley <[e-mail]>]

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.

Review and comment most welcome.

Russ

= = = = = = = = 


Vulnerabilities in Internet of Things (IoT) devices have raised the need
for a secure firmware update mechanism that is also suitable for constrained
devices.  Security experts, researchers, and regulators recommend that all IoT
devices be equipped with such a mechanism.  While there are many proprietary
firmware update mechanisms in use today, there is no modern interoperable
approach allowing secure updates to firmware in IoT devices. In June 2016,
the Internet Architecture Board organized a workshop on 'Internet
of Things (IoT) Software Update (IOTSU)', and RFC 8240 documents various
requirements and challenges that are specific to IoT devices.

A firmware update solution consists of several components, including:
* A mechanism to transport firmware images to compatible devices.
* A manifest that provides meta-data about the firmware image (such as a
  firmware package identifier, the hardware the package needs to run, and
  dependencies on other firmware packages), as well as cryptographic
  information for protecting the firmware image in an end-to-end fashion.
* The firmware image itself.

The SUIT WG will focus on defining a firmware update solution (taking into
account past learnings from RFC 4108 and other proprietary firmware update
solutions) that will be usable on Class 1 (as defined in RFC 7228) devices,
i.e., devices with ~10 KiB RAM and ~100 KiB flash.  The solution may apply to
more capable devices as well.  The SUIT WG will not define any new transport
or discovery mechanisms, but may describe 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, the SUIT WG will has selected the
CBOR serialization formats and the associated COSE cryptographic mechanisms to
encode the SUIT manifest. The SUIT WG may 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 are expected to be expressive
enough to allow the use of different firmware sources and permission models.

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.

The SUIT WG will aim 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.