Change:
Only install firmware that is before its best-before timestamp. <del> Only install firmware with metadata signed/authenticated by a trusted actor. Only allow an actor to exercise rights on the device via a manifest if that actor has signed the manifest. Only allow a firmware installation if all required rights have been met through signatures/MACs (one or more) or manifest dependencies (one or more). Use the instructions provided by the manifest to install the firmware. Install any and all firmware images that are linked together with manifest dependencies. </del> <ins> Only allow a firmware installation if dependencies have been met. </ins> Choose the mechanism to install the firmware, based on the type of firmware it is. 5. <del> We start the architectural description with the security model.  It is based on end-to-end security.  In e2e-figure a firmware image is created by an author, sent to the device and subsequently installed. When the author is ready to distribute the firmware image it is conveyed using some communication channel to the device, which will typically involve the use of untrusted storage.  Examples of untrusted storage are FTP servers, Web servers or USB sticks.  End- to-end security mechanisms are used to protect the firmware image. e2e-figure does not show the manifest itself, which provides the meta-data about the firmware image and offers the security protection.  It may bundled with the firmware image or travel as a standalone item. </del> <ins> arch-figure shows the communication architecture where a firmware image is created by an author, and uploaded to a firmware server. The firmware image/manifest is distributed to the device either in a push or pull manner using the communicator residing on the device. The device operator keeps track of the process using the status tracker.  This allows the device operator to know and control what devices have received an update and which of them are still pending an update. End-to-end security mechanisms are used to protect the firmware image and the manifest although e2e-figure does not show the manifest itself since it may be distributed independently. </ins> Whether the firmware image and the manifest is pushed to the device <del> or fetched by the device is outside the scope of this work and existing device management protocols can be used for efficiently distributing this information. </del> <ins> or fetched by the device is a deployment specific decision. </ins> The following assumptions are made to allow the device to verify the received firmware image and manifest before updating software: <del> To accept an update, a device needs to decide whether the author signing the firmware image and the manifest is authorized to make the updates.  We use public key cryptography to accomplish this. The device verifies the signature covering the manifest using a digital signature algorithm OR the device verifies the MAC covering the manifest using a MAC algorithm.  The device is provisioned with a trust anchor that is used to validate the digital signature or MAC produced by the author.  This trust anchor is potentially different from the trust anchor used to validate the digital signature produced for other protocols (such as device management protocols).  This trust anchor may be provisioned to the device during manufacturing or during commissioning. </del> <ins> To accept an update, a device needs to verify the signature covering the manifest.  There may be one or multiple manifests that need to be validated, potentially signed by different parties.  The device needs to be in possession of the trust anchors to verify those signatures.  Installing trust anchors to devices via the Trust Provisioning Authority happens in an out-of- band fashion prior to the firmware update process. Not all entities creating and signing manifests have the same permissions.  A device needs to determine whether the requested action is indeed covered by the permission of the party that signed the manifest.  Informing the device about the permissions of the different parties also happens in an out-of-band fashion and is also a duty of the Trust Provisioning Authority. </ins> For confidentiality protection of firmware images the author needs to be in possession of the certificate/public key or a pre-shared <del> key of a device. </del> <ins> key of a device.  The use of confidentiality protection of firmware images is deployment specific. </ins> There are different types of delivery modes, which are illustrated based on examples below.

Discussion:
Added David Brown as co-author Added further terms Updated text about permissions Re-wrote text about operating modes Editorial changes (including formatting) Revised section about claims Added new architecture figure Reworked security description Included device firmware update examples provided by David. Updated example flow (and included bootloader)