[Fud] Revised Charter Text
Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 25 September 2017 18:07 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 C1CA413451F for <fud@ietfa.amsl.com>; Mon, 25 Sep 2017 11:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 eM3_2BZp8QYb for <fud@ietfa.amsl.com>; Mon, 25 Sep 2017 11:07:23 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 B34AE1330B2 for <fud@ietf.org>; Mon, 25 Sep 2017 11:07:22 -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 0Lkwc9-1dOIph1LgD-00ajnQ for <fud@ietf.org>; Mon, 25 Sep 2017 20:07:20 +0200
To: fud@ietf.org
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <598d9373-4a4a-01c3-33e8-34ed1beceaa2@gmx.net>
Date: Mon, 25 Sep 2017 20:07:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:FI/0TPaq4b3SO9mWNBpfPaDHnP+9VJx/8AwpZ9e8xOH0bw+x94O UPGYQDRtrNfE/BgcwBk6IDxOEDNYZeac1DAkGSD/+sHlA173w1xlNQssw/8TSvuQnKrad3d /uyQMCAaFSE+1FBX2l/xDtQh2jw8mBNrURG+QTASjec38gAtUShHvwPBINEDCa+0QGwJr9c 2GhxIvOG1ylHi/rkNCP7A==
X-UI-Out-Filterresults: notjunk:1;V01:K0:X+s44UFeSfE=:NsTwYZr4GeFKlulQI+1/Ot c/n/a3ohaxU6fWdg7Wppcu+zKYaZXP0Sn7G/Y0z22S4YlPKez/sfaXisojRmGEui0yPcewqnO ObUAzHXOkdlOyO62EWW0XYY8G67lYMLcOQCv989flyM81ILfw81+Fpxp6x1UqPMKH0aEvkUO8 xVqwOt8bPKPP2LBYJa7U5VqHUbmNwb6qAc5r8LrpsQ/pxmyPHrSeCaiq1oXKCWFu4ohSrV+cs 7w37aPx02LrW/udCNA3/Xwcf/aDqzvozTZq62anuorULAqW3cWU7HOk2al31D0QkfIRCmn2Lx VLqTiG7Ff8zF2zwlvN9eHRSS0UxsUA2qc2G3VVgg0WwR0QizANZzg5DAPopsxoP8S866NhgRO mbJUuOB64d0uzm0Usa8MDpQkIRRFOYzpX+1neDJKqWO7P7cm2ZOBai4flLqJ+yloybPUfY7i2 0jU3tsE0bE6kntP+rXYrrBlDdOKPxoswiAsIhGRuTHhptFpIwdqzUjn/8CEcjXGrW8HtS+v3g arE+n9QnN/7eMKD/6qYxiX8SUC0NP7F1mnx1rwiLL77Ev9wobIrhVoQubra51lfrtCZIjdpwN 8+9B0dw5iA4+OUin+dmTeGAiu06YYUm1psZlPqMCr/OfYrpAoCzlaLWunFQjqXSZ6aNo+pHJx 3zAwuQGbCC/KOye885ZY6ry7KC++WfMP2i1jSth5nlY0nUbtaG88JK0fHe+eRyWG05/BkYEMq lwa7g6dSmHoUCax4XCPp6IXzwZBEibVlIA1DfWG51vDEcezrqlT44IcFJRKE7fdSa4SFPIUx1 YAKAaP5EGeYTuXL/pPk81B3P5bDgqUyhi65LUqSWVGa4CiXeEM=
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/ldoLD2yf6gdBEemTKB7kpYW-z9I>
Subject: [Fud] Revised Charter Text
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: Mon, 25 Sep 2017 18:07:25 -0000
Based on the feedback following the IETF meeting in Prague I have updated the charter text. Ciao Hannes ---- Firmware Updating Description (FUD) [Alternative proposal: SUIT (Software Updates for Internet of Things).] Vulnerabilities with 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 are 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, dependencies on other firmware packages, etc.) as well as cryptographic information for protecting the firmware image in an end-to-end fashion, and * the firmware image itself. With RFC 4108 the IETF standardized a manifest format that uses the Cryptographic Message Syntax (CMS) to protect firmware packages. Since the publication of RFC 4108 more than 10 years have passed and more experience with IoT deployments have lead to additional functionality requiring the work done with RFC 4108 to be revisited. The purpose of this group is to standardize a version 2 of RFC 4108 that reflects best current practices. This group focuses on defining a firmware update solution for Class 1 devices, as defined in RFC 7228, i.e., IoT devices with ~10 KiB RAM and ~100 KiB flash. This group will not define any transport mechanism. In 2016 the Internet Architecture Board organized a workshop on 'Internet of Things (IoT) Software Update (IOTSU)', which took place at Trinity College Dublin, Ireland on the 13-14 June 2016. 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 to 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, and * 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. Software update solutions that aim to take the features of scripting languages, such as JavaScript variants like JerryScript, into account are also outside the scope of this group. 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.
- Re: [Fud] Revised Charter Text Carsten Bormann
- Re: [Fud] Revised Charter Text Hannes Tschofenig
- Re: [Fud] Revised Charter Text Carsten Bormann
- Re: [Fud] Revised Charter Text Carsten Bormann
- Re: [Fud] Revised Charter Text Waltermire, David A. (Fed)
- Re: [Fud] Revised Charter Text Hannes Tschofenig
- [Fud] Revised Charter Text Hannes Tschofenig
- Re: [Fud] Revised Charter Text Michael Richardson
- Re: [Fud] Revised Charter Text Russ Housley