Subject: Re: [Fud] Editorial Charter Update
From: Hannes Tschofenig <[email-masked]>
To: Carsten Bormann <[email-masked]>, Russ Housley <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Mon, 9 Oct 2017 10:24:21 +0200
List-Id: FUD - Firmware Updating Description <fud.ietf.org>

Hi Carsten

I had provided a response to your comment and asked whether it clarifies
things.

I don't believe you have responded.

So far, I haven't heard you saying anything about what you would like to
see done in this working group. I would also like to know what you see
wrong with bug fixing and tweaking?

Ciao
Hannes

On 10/04/2017 07:31 PM, Carsten Bormann wrote:
> Hi Russ, 
> 
> I had a comment about a possible misunderstanding of the FUD/suit WG
> being misunderstood as the rfc4108 bug fixing and tweaking WG. I'm not
> sure that had been addressed. I'm mostly offline in the next seven days
> or so. 
> 
> Sent from mobile
> 
> On 3. Oct 2017, at 16:43, Russ Housley <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>> 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.
>>
>> Russ
>>
>> = = = = = = =
>>
>> 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
>> mechanism.
>>
>> 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.
>>
>>
>> Milestones:
>>
>> 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
>>             source.
>>
>> Jun 2018     Release first IoT OS implementation of firmware update
>>             mechanisms as open source.
>>
>> _______________________________________________
>> Fud mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/fud
>>
> 
> 
> _______________________________________________
> Fud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fud
>