Re: [Fud] Editorial Charter Update

Russ Housley <> Tue, 03 October 2017 13:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3DEE1345E3 for <>; Tue, 3 Oct 2017 06:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UwDu179t1BY6 for <>; Tue, 3 Oct 2017 06:43:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E784913243A for <>; Tue, 3 Oct 2017 06:43:06 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09CAC300563 for <>; Tue, 3 Oct 2017 09:43:06 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id lWtcO6OSWWdS for <>; Tue, 3 Oct 2017 09:43:04 -0400 (EDT)
Received: from a860b60074bd.home ( []) by (Postfix) with ESMTPSA id 6160B300558 for <>; Tue, 3 Oct 2017 09:43:04 -0400 (EDT)
From: Russ Housley <>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 3 Oct 2017 09:43:03 -0400
References: <>
To: "" <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [Fud] Editorial Charter Update
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Oct 2017 13:43:10 -0000

Here is an update to the charter text based on the comments.

Note that the WG name is still FUD.  Any name change will be handled by the IESG.


= = = = = = =

Firmware Updating Description (FUD)
[Alternative proposal: SUIT (Software Updates for Internet of Things)]

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 a lack of a modern interoperable approach of securely updating the
software in IoT devices.

A firmware update solution consists of several components, including:
  *  A mechanism to transport firmware images to IoT 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.

RFC 4108 provides a manifest format that uses the Cryptographic Message
Syntax (CMS) to protect firmware packages.

More than ten years have passed since the publication of RFC 4108, and
greater experience with IoT deployments has lead to additional
functionality, requiring the work done with RFC 4108 to be revisited.
The purpose of this group is to produce a second version of RFC 4108
that reflects the current best practices.  This group will focus on
defining a firmware update solution for Class 1 devices, as defined in
RFC 7228, that is -- IoT devices with ~10 KiB RAM and ~100 KiB flash.
This group will not define any transport mechanisms.

In June of 2016 the Internet Architecture Board organized a workshop on
'Internet of Things (IoT) Software Update (IOTSU)', which took place at
Trinity College in Dublin, Ireland.  The main goal of the workshop was
to foster a discussion on requirements, challenges, and solutions for
bringing software and firmware updates to IoT devices.  This workshop
also made clear that there is a lack of regulatory requirements, which
contributes to challenges associated with misaligned incentives.  It is
nevertheless seen as important to create standard building blocks that
help interested parties implement and deploy a solid firmware update

In particular this group aims to publish three documents, namely:
  *  An IoT firmware update architecture that includes a description of
     the involved entities, security threats, and assumptions.
  *  The manifest format.
  *  A revision to RFC 4108 that reflects the current best practices.

This group will use draft-moran-fud-architecture as a starting point for
discussion of the "Architecture" document.

This group will use draft-moran-fud-manifest as a starting point for
discussion of the "Manifest Format" specification.

This group does not aim to create a standard for a generic software
update mechanism for use by rich operating systems, like Linux, but
instead this group will focus on software development practices in the
embedded industry.  "Software update solutions that target updating
software other than the firmware binary (e.g. updating scripts) are
also out of scope.

This group will aim to develop a close relationship with silicon vendors
and OEMs that develop IoT operating systems.


Dec 2017     Submit RFC 4108bis document as WG item.

Dec 2017     Submit "Architecture" document as WG item.

Dec 2017     Submit "Manifest Format" specification as WG item.

Jul 2018     Submit "Architecture" to the IESG for publication as an
             Informational RFC.

Nov 2018     Submit RFC 4108bis document to the IESG for publication as
             a Proposed Standard.

Nov 2018     Submit "Manifest Format" to the IESG for publication as
             a Proposed Standard.

Additional calendar items:

Mar 2018     Release initial version of the manifest creation tools as
             open source.

Apr 2018     Release first version of manifest test tools as open

Jun 2018     Release first IoT OS implementation of firmware update
             mechanisms as open source.