[Fud] Editorial Charter Update

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 29 September 2017 11:00 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: fud@ietfa.amsl.com
Delivered-To: fud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EEA134290 for <fud@ietfa.amsl.com>; Fri, 29 Sep 2017 04:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.4
X-Spam-Level:
X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38rtHztxrexi for <fud@ietfa.amsl.com>; Fri, 29 Sep 2017 04:00:29 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6E3132D49 for <fud@ietf.org>; Fri, 29 Sep 2017 04:00:28 -0700 (PDT)
Received: from [192.168.91.203] ([80.92.122.248]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M4nt7-1d8gtD41Wv-00yvV3 for <fud@ietf.org>; Fri, 29 Sep 2017 13:00:27 +0200
To: "Fud@ietf.org" <fud@ietf.org>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <c14c92bf-cf99-efdb-6693-0e33519fbb0a@gmx.net>
Date: Fri, 29 Sep 2017 13:00:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:yUBNJpNOw5Q3W+rCRFsiyCBEhBSdwcsU6bscqits382TCAvakfM qIvlAno7KrLRkg48XDxvfF7xunpcYQX7rB+aoea8W4q7a1rh9Xy2ajSgXo/Zolwv5eZq3pn AMlWLAAIzoyFsngw74iPazCLJB7XgB2ht4Gnxti8vWZ1Q/Xn/lCt1QLFASTXgVD/FdH6Tjt MNUYPbed6mVVjDaYaBRcg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:GczvObEPbP8=:beLLX1nQSAPW+hxkipuAAj uDzkpc7Gjn4I4N+zBZNROvRzcrYSpd0fXjpVQdjAjB2seG0DSlgrXDQMPUKStT2uZQFjvyQsb Q65T9RloQHdNfvlUpgmBxczSGmBsKnelD+QNc0WDzUgdcAMuJkMVQnEu6/K1dq+VEfbOOkRta hSghHzzXA0ELMdC88VVgGb/5t6k5fQ5g0hm2aLkzHn4OodTAvz+Z/DLOLcLJFBY66gpxKaItM ZV0GvmStUM/RJtOPYTs0gCjQaEWVyaKzz12xPm8MoyEzS2hYCBAWJseyQRODT0ALGGWHkazl3 lBRmt7FJdyEetuoTKZU0ifN0EA8wXKDdxZ/xAhCSVk33QF8Wf3b9O8XxPJeh86RMv7Ng3J6+0 3cn58nrP/Uzf1k2QuuAet0fLCh4yL6Ci04ECs4huMRFz36nF1xBstURPGDhKNjIwWEFbEqnDx 59Q+EOag8i96HxfifeZQTZrtflzMtwOL2+CwDUTvsU7BXzWPs/NMRWZAUZo/c4SuKQiWAB6h/ UmlDOmqQOX5VVhBd2zvcC2ZU5+AT/J9Avjk4NcYQ37zMRusD45M7UuuxqXWbAuLA0Pc578yMd FY67Tl0sZO45x8ppXkA7476gjXfI0UIbsHE6sAR82brKYXRMQL/DddRS+4W6iKO5Gib3R1vx2 hK6APZfXSC1KzHbnrohDt/5bUol33Sxyx6DImU3C2XW2vyjI0toCOqOTtHJXp4C9ZLB1Cf3lt 9Ha9365s0gjSpJK/ssLaqkH930fkx3CImXAdI8umQa+rQikQRTi4nkHE8PbLGo8z9H7sXykvs 2e5MKoqoY1h46LMRRVWWrzlzHM6cUJJSkgeQmVnJZyxRFot5kw=
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/uvqbCtWTh2KAHa4Lu8qR_u236Pw>
Subject: [Fud] Editorial Charter Update
X-BeenThere: fud@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <fud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fud>, <mailto:fud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fud/>
List-Post: <mailto:fud@ietf.org>
List-Help: <mailto:fud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fud>, <mailto:fud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Sep 2017 11:00:32 -0000

Irit Arkin, my co-worker, helped to improve readability of the charter
text. Below is the updated charter text:

-----

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 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.

With RFC 4108 the IETF standardized 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 standardize a second version of RFC 4108 that
reflects the current best practices. This group focuses 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 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 are challenges
with lack of regulatory requirements and misaligned incentives. It is
nevertheless seen as important to standardize the building blocks that
help interested parties implement and deploy a solid firmware update
mechanism.

In particular this group aims to publish two documents, namely:
* An IoT firmware update architecture that includes a description of
the involved entities, security threats and assumptions.
* The manifest format itself.

This group does not aim to standardize a generic software update
mechanism used by rich operating systems, like Linux, but instead
focuses on software development practices in the embedded industry. Also
out of scope are
software update solutions that aim to take the features of scripting
languages, such as JavaScript variants like JerryScript, into account.

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

Milestones

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 "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 tool suite as open
source.

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