SUIT                                                            B. Moran
Internet-Draft                                             H. Tschofenig
Intended status: Standards Track                             Arm Limited
Expires: July 22, 2019 January 9, 2020                                     H. Birkholz
                                                          Fraunhofer SIT
                                                        January 18,
                                                           July 08, 2019

 Firmware Updates for Internet of Things Devices - An Information Model
                             for Manifests
                  draft-ietf-suit-information-model-02
                  draft-ietf-suit-information-model-03

Abstract

   Vulnerabilities with Internet of Things (IoT) devices have raised the
   need for a solid and secure firmware update mechanism that is also
   suitable for constrained devices.  Incorporating such an update
   mechanism to fix vulnerabilities, to update configuration settings settings,
   as well as adding new functionality is recommended by security
   experts.

   One component of such a firmware update is the meta-data, a concise and machine-
   processable meta-data document, or manifest, that describes the
   firmware image(s) and offers appropriate protection.  This document
   describes all the information that must be present in the manifest.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 22, 2019. January 9, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
   3.  Manifest Information Elements . . . . .
     2.1.  Requirements Notation . . . . . . . . . . .   5
     3.1.  Manifest Element: version identifier of the manifest
           structure . . . . . . .   6
   3.  Manifest Information Elements . . . . . . . . . . . . . . . .   6
     3.1.  Manifest Element: Version ID of the manifest structure  .   5   6
     3.2.  Manifest Element: Monotonic Sequence Number . . . . . . .   6
     3.3.  Manifest Element: Vendor ID Condition . . . . . . . . . . . . . . .   6
       3.3.1.  Example: Domain Name-based UUIDs  . . . . . . . . . .   6   7
     3.4.  Manifest Element: Class ID Condition  . . . . . . . . . .   6 . . . . .   7
       3.4.1.  Example 1: Different Classes  . . . . . . . . . . . .   7   8
       3.4.2.  Example 2: Upgrading Class ID . . . . . . . . . . . .   7   8
       3.4.3.  Example 3: Shared Functionality . . . . . . . . . . .   8   9
     3.5.  Manifest Element: Precursor Image Digest Condition  . . .   8   9
     3.6.  Manifest Element: Required Image Version List . . . . . .   8   9
     3.7.  Manifest Element: Best-Before timestamp condition Expiration Time . . . .   9 . . . . . . . .  10
     3.8.  Manifest Element: Payload Format  . . . . . . . . . . . .   9  10
     3.9.  Manifest Element: Processing Steps  . . . . . . . . . . .   9  10
     3.10. Manifest Element: Storage Location  . . . . . . . . . . .   9  11
       3.10.1.  Example 1: Two Storage Locations . . . . . . . . . .  10  11
       3.10.2.  Example 2: File System . . . . . . . . . . . . . . .  10  11
       3.10.3.  Example 3: Flash Memory  . . . . . . . . . . . . . .  10  11
     3.11. Manifest Element: Component Identifier  . . . . . . . . .  10  11
     3.12. Manifest Element: URIs  . . . . . . . Resource Indicator  . . . . . . . . . .  10  12
     3.13. Manifest Element: Payload Digest Digests . . . . . . . . . . . .  11  12
     3.14. Manifest Element: Size  . . . . . . . . . . . . . . . . .  11  12
     3.15. Manifest Element: Signature . . . . . . . . . . . . . . .  11  13
     3.16. Manifest Element: Directives Additional installation instructions  .  13
     3.17. Manifest Element: Aliases . . . . . . . . . . . . .  11
     3.17. . . .  13
     3.18. Manifest Element: Aliases Dependencies  . . . . . . . . . . . . .  13
     3.19. Manifest Element: Encryption Wrapper  . . .  12
     3.18. . . . . . . .  14
     3.20. Manifest Element: Dependencies XIP Address . . . . . . . . . . . . .  12
     3.19. .  14
     3.21. Manifest Element: Content Key Distribution Method Load-time metadata  . . . .  12
     3.20. . . . . . .  14
     3.22. Manifest Element: XIP Address Run-time metadata . . . . . . . . . . .  14
     3.23. Manifest Element: Payload . . . .  12
     3.21. . . . . . . . . . . . .  15
     3.24. Manifest Element: Load-time metadata Key Claims  . . . . . . . . . .  13 . . . .  15
   4.  Motivation for Manifest Fields  . . . . . . . . . . . . . . .  13  15
     4.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  13  15
     4.2.  Threat Descriptions . . . . . . . . . . . . . . . . . . .  13  16
       4.2.1.  Threat MFT1:  THREAT.IMG.EXPIRED: Old Firmware  . . . . . . . . . .  16
       4.2.2.  THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old
               Firmware  . . . .  13
       4.2.2.  Threat MFT2: Mismatched Firmware . . . . . . . . . .  14 . . . . . . . .  16
       4.2.3.  Threat MFT3: Offline device + Old  THREAT.IMG.INCOMPATIBLE: Mismatched Firmware  . . . . .  14  16
       4.2.4.  Threat MFT4:  THREAT.IMG.FORMAT: The target device misinterprets
               the type of payload . . . . . . . . . . . . . . . . . . . . .  15  17
       4.2.5.  Threat MFT5:  THREAT.IMG.LOCATION: The target device installs the
               payload to the wrong location . . . . . . . . . . . .  17
       4.2.6.  THREAT.NET.REDIRECT: Redirection to inauthentic
               payload hosting . . . .  15
       4.2.6.  Threat MFT6: Redirection . . . . . . . . . . . . . .  15 .  18
       4.2.7.  Threat MFT7: Payload Verification on Boot  THREAT.NET.MITM . . . . . .  16
       4.2.8.  Threat MFT8: Unauthenticated Updates . . . . . . . .  16
       4.2.9.  Threat MFT9: Unexpected Precursor images . . . . .  18
       4.2.8.  THREAT.IMG.REPLACE: Payload Replacement .  16
       4.2.10. Threat MFT10: Unqualified Firmware . . . . . .  18
       4.2.9.  THREAT.IMG.NON_AUTH: Unauthenticated Images . . .  17
       4.2.11. Threat MFT11: Reverse Engineering Of Firmware Image
               for Vulnerability Analysis . .  18
       4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor
               images  . . . . . . . . . . .  18
       4.2.12. Threat MFT12: Overriding Critical Manifest Elements .  18
       4.2.13. Threat MFT13: Manifest Element Exposure . . . . . . .  18
     4.3.  Security Requirements . . . .  18
       4.2.11. THREAT.UPD.INTEROP: Unqualified Firmware  . . . . . .  19
       4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of
               Firmware Image for Vulnerability Analysis . . . . . .  20
       4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest
               Elements  . .  19
       4.3.1.  Security Requirement MFSR1: Monotonic Sequence
               Numbers . . . . . . . . . . . . . . . . . . . .  20
       4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element
               Exposure  . . .  19
       4.3.2.  Security Requirement MFSR2: Vendor, Device-type
               Identifiers . . . . . . . . . . . . . . . . . . .  21
       4.2.15. THREAT.IMG.EXTRA: Extra data after image  . .  19
       4.3.3.  Security Requirement MFSR3: Best-Before Timestamps .  19
       4.3.4.  Security Requirement MFSR5: Cryptographic
               Authenticity . . .  21
     4.3.  Security Requirements . . . . . . . . . . . . . . . . .  20
       4.3.5.  Security Requirement MFSR4a: Authenticated Payload
               Type .  21
       4.3.1.  REQ.SEC.SEQUENCE: Monotonic Sequence Numbers  . . . .  21
       4.3.2.  REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers .  22
       4.3.3.  REQ.SEC.EXP: Expiration Time  . . . . . . . . . . . .  22
       4.3.4.  REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . .  22
       4.3.5.  REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . .  20  22
       4.3.6.  Security Requirement MFSR4b: REQ.SEC.AUTH.IMG_LOC:
               Authenticated Storage Location  . . . . . . . . . . . . . . . . . . . . . .  20  23
       4.3.7.  Security Requirement MFSR4c:  REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote
               Resource Location . . . . . . . . . . . . . . . . . .  20  23
       4.3.8.  Security Requirement MFSR4d:  REQ.SEC.AUTH.EXEC: Secure Boot Execution . . . . . .  21 . . .  23
       4.3.9.  Security Requirement MFSR4e:  REQ.SEC.AUTH.PRECURSOR: Authenticated precursor
               images  . . . . . . . . . . . . . . . . . . . . . . .  21  23
       4.3.10. Security Requirement MFSR4f: REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and
               Class IDs . . . . . . . . . . . . . . . . . . . . . .  21  23
       4.3.11. Security Requirement MFSR4f: Authenticated Vendor and
               Class IDs REQ.SEC.RIGHTS: Rights Require Authenticity . . . . .  24
       4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . .  24
       4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control  . . . . . . .  24
       4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . .  25
       4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . .  25
     4.4.  User Stories  . .  21

       4.3.12. Security Requirement MFSR6: Rights Require
               Authenticity . . . . . . . . . . . . . . . . . . . .  21
       4.3.13. Security Requirement MFSR7: Firmware encryption  25
       4.4.1.  USER_STORY.INSTALL.INSTRUCTIONS: Installation
               Instructions  . . .  22
       4.3.14. Security Requirement MFSR8: Access Control Lists . .  22
       4.3.15. Security Requirement MFSR9: Encrypted Manifests . . .  22
     4.4.  User Stories . . . . . . . . . . . .  25
       4.4.2.  USER_STORY.MFST.FAIL_EARLY: Fail Early  . . . . . . . . . .  23
       4.4.1.  Use Case MFUS1: Installation Instructions . . . . . .  23
       4.4.2.  Use Case MFUS2: Override Non-Critical Manifest
               Elements  26
       4.4.3.  USER_STORY.OVERRIDE: Override Non-Critical Manifest
               Elements  . . . . . . . . . . . . . . . . . . . . . .  23
       4.4.3.  Use Case MFUS3: Modular  26
       4.4.4.  USER_STORY.COMPONENT: Component Update  . . . . . . . . . . .  24
       4.4.4.  Use Case MFUS4:  27
       4.4.5.  USER_STORY.MULTI_AUTH: Multiple Authorisations  . . . . . . .  24
       4.4.5.  Use Case MFUS5:  27
       4.4.6.  USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . . . .  24
       4.4.6.  Use Case MFUS6:  27
       4.4.7.  USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential
               Information Disclosures . . . . . . . . . . . . . . . . . . . . .  24
       4.4.7.  Use Case MFUS7:  27
       4.4.8.  USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from
               Unpacking Unknown Formats . . . . . . . . . . . . . . . . . . .  24
       4.4.8.  Use Case MFUS8:  27
       4.4.9.  USER_STORY.IMG.CURRENT_VERSION: Specify Version
               Numbers of Target Firmware  . . . . . . . . . . . . .  28
       4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose
               Between Images  . . . . . . . . .  25
       4.4.9.  Use Case MFUS9: Enable Devices to Choose Between
               Images  . . . . . . . . . . .  28
       4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using
               Manifests . . . . . . . . . . . .  25
       4.4.10. Use Case MFUS10: Secure Boot Using Manifests . . . .  25
       4.4.11. Use Case MFUS11: Decompress on Load . . . . . .  28
       4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load  . . .  25
       4.4.12. Use Case MFUS12:  28
       4.4.13. USER_STORY.MFST.IMG: Payload in Manifest  . . . . . . . .  26
       4.4.13. Use Case MFUS13:  28
       4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . .  29
       4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in
               Manifest  . . .  26
     4.5.  Usability Requirements . . . . . . . . . . . . . . . . .  26
       4.5.1.  Usability Requirement MFUR1 . .  29
       4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation  . . . .  29
     4.5.  Usability Requirements  . . . . . . .  26
       4.5.2.  Usability Requirement MFUR2 . . . . . . . . . .  29
       4.5.1.  REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . .  26
       4.5.3.  Usability Requirement MFUR3  29
       4.5.2.  REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote
               Resource Location . . . . . . . . . . . . .  27
       4.5.4.  Usability Requirement MFUR4 . . . . .  30
       4.5.3.  REQ.USE.MFST.COMPONENT: Component Updates . . . . . .  30
       4.5.4.  REQ.USE.MFST.MULTI_AUTH: Multiple authentications . .  28  31
       4.5.5.  REQ.USE.IMG.FORMAT: Format Usability Requirement MFUR5  . . . . . . . .  31
       4.5.6.  REQ.USE.IMG.NESTED: Nested Formats  . . . . .  28
       4.5.6.  Usability Requirement MFUR6 . . . .  32
       4.5.7.  REQ.USE.IMG.VERSIONS: Target Version Matching . . . .  32
       4.5.8.  REQ.USE.IMG.SELECT: Select Image by Destination . . .  32
       4.5.9.  REQ.USE.EXEC: Executable Manifest . .  28
       4.5.7.  Usability Requirement MFUR7 . . . . . . . .  32
       4.5.10. REQ.USE.LOAD: Load-Time Information . . . . .  28
       4.5.8.  Usability Requirement MFUR8 . . . .  33
       4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure .  33
       4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . .  29
       4.5.9.  Usability Requirement MFUR9: Bootable Manifest . . .  29
       4.5.10. Usability Requirement MFUR10: Load-Time Information .  29
       4.5.11. Usability Requirement MFUR11: Payload  33
       4.5.13. REQ.USE.DELEGATION: Delegation of Authority in
               Manifest
               Superstructure  . . . . . . . . . . . . . . . . . . .  29
       4.5.12. Usability Requirement MFUR12: Simple Parsing  . . . .  30  33
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  30  34
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30  34
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  30  34
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  30  34
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  30  34
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  31  35
   Appendix A.  Mailing List Information . . . . . . . . . . . . . .  32  36
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32  36

1.  Introduction

   The information model describes all the information elements required
   to secure firmware updates of IoT devices from the threats described
   in Section 4.1 and enable enables the user stories captured in Section 4.4.
   These threats and user stories are not intended to be an exhaustive
   list of the threats against IoT devices, nor of the possible use
   cases of user
   stories that describe how to conduct a firmware update; instead update.  Instead they
   are intended to describe the threats against firmware update updates in
   isolation and provide sufficient motivation to provide specify the
   information elements that cover a wide range of
   use cases. user stories.  The
   information model does not define the serialization, encoding,
   ordering, or structure of information elements, only their semantics.

   Because the information model covers a wide range of user stories and
   a wide range of threats, not all information elements apply to all
   scenarios.  As a result, many various information elements could be
   considered optional to implement and optional to use, depending on
   which threats exist in a particular system domain of application and which use cases
   user stories are required.  Elements marked as mandatory provide
   baseline security and usability properties that are expected to be
   required for most applications.  Those elements are mandatory to
   implement and mandatory to use.  Elements marked as recommended
   provide important security or usability properties that are needed on
   most devices.  Elements marked as optional enable security or
   usability properties that are useful in some applications.

   The definition of some of the information elements include examples
   that illustrate their semantics and how they are intended to be used.

2.  Conventions and Terminology

   This document uses terms defined in [I-D.ietf-suit-architecture].
   The term 'Operator' refers to both, Device and Network Operator.

   This document treats devices with a homogeneous storage architecture
   as devices with a heterogeneous storage architecture, but with a
   single storage subsystem.

2.1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

   This document uses terms defined in [I-D.ietf-suit-architecture].
   The term 'Operator' refers to both, Device
   BCP 14 [RFC2119] [RFC8174] when, and Network Operator. only when, they appear in all
   capitals, as shown here.

3.  Manifest Information Elements

   Each manifest information element is anchored in a security
   requirement or a usability requirement.  The manifest elements are
   described below and below, justified by their requirements.

3.1.  Manifest Element: version identifier Version ID of the manifest structure

   An identifier that describes which iteration of the manifest format
   is contained in the structure.

   This element is MANDATORY and must MUST be present in order to allow
   devices to identify the version of the manifest data model that is in
   use.

3.2.  Manifest Element: Monotonic Sequence Number

   A monotonically increasing sequence number.  For convenience, the
   monotonic sequence number MAY be a UTC timestamp.  This allows global
   synchronisation of sequence numbers without any additional
   management.  This number MUST be easily accessible so that code
   choosing one out of several manifests can choose which is the latest.

   This element is MANDATORY and is necessary to prevent malicious
   actors from reverting a firmware update against the wishes policies of the
   relevant authority.

   Implements: Security Requirement MFSR1. REQ.SEC.SEQUENCE (Section 4.3.1)

3.3.  Manifest Element: Vendor ID Condition

   Vendor IDs MUST be unique.  This is to prevent similarly, or
   identically named entities from different geographic regions from
   colliding in their customer's infrastructure.  Recommended practice
   is to use type [RFC4122] version 5 UUIDs with the vendor's domain name and
   the UUID DNS prefix.  Other options include type 1 and type 4 UUIDs.

   This

   Vendor ID is RECOMMENDED and not intended to be a human-readable element.  It is
   intended for match/mismatch comparison only.

   The use of a Vendor ID is RECOMMENDED.  It helps to distinguish
   between identically named products from different vendors.

   Implements: Security Requirement MFSR2, MFSR4f. REQ.SEC.COMPATIBLE (Section 4.3.2),
   REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10).

3.3.1.  Example: Domain Name-based UUIDs

   Vendor A creates a UUID based on their domain name:

   vendorId = UUID5(DNS, "vendor-a.com")

   Because the DNS infrastructure prevents multiple registrations of the
   same domain name, this UUID is guaranteed to be unique.  Because the
   domain name is known, this UUID is reproducible.  Type 1 and type 4
   UUIDs produce similar guarantees of uniqueness, but not
   reproducibility.

   This approach creates a contention when a vendor changes its name or
   relinquishes control of a domain name.  In this scenario, it is
   possible that another vendor would start using that same domain name.
   However, this UUID is not proof of identity; a device's trust in a
   vendor must be anchored in a cryptographic key, not a UUID.

3.4.  Manifest Element: Class ID Condition

   A device "Class" is defined as any a set of different device types that can accept
   the same firmware update without modification.  Class Identifiers IDs MUST be
   unique within the scope of a Vendor ID.  This is to prevent
   similarly, or identically named devices colliding in their customer's
   infrastructure.

   Recommended practice is to use type [RFC4122] version 5 UUIDs with as much
   information as necessary to define firmware compatibility.  Possible
   information used to derive the
   model, class UUID includes:

   o  model name or number

   o  hardware revision, etc. and revision

   o  runtime library version

   o  bootloader version

   o  ROM revision
   o  silicon batch number

   The Class Identifier UUID SHOULD use the Vendor ID as the UUID
   prefix.  Other options include type version 1 and type 4 UUIDs.  Classes MAY be implemented in a
   more granular way. than is required to identify firmware compatibility.
   Classes MUST NOT be
   implemented in a less granular way.  Class ID can encompass model
   name, hardware revision, software revision. than is required to identify
   firmware compatibility.  Devices MAY have multiple Class IDs.

   Note Well:

   Class ID is not intended to be a human-readable element.  It is
   intended for match/mismatch use comparison only.

   This

   The use of Class ID is RECOMMENDED and RECOMMENDED.  It allows devices to determine
   applicability of a firmware in an unambiguous way.

   If Class ID is not implemented, then each logical device class MUST
   use a unique Root of Trust for authorisation.

   Implements: Security Requirement MFSR2, MFSR4f. REQ.SEC.COMPATIBLE (Section 4.3.2),
   REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10).

3.4.1.  Example 1: Different Classes

   Vendor A creates product Z and product Y.  The firmware images of
   products Z and Y are not interchangeable.  Vendor A creates UUIDs as
   follows:

   -

   o  vendorId = UUID5(DNS, "vendor-a.com")

   -

   o  ZclassId = UUID5(vendorId, "Product Z")

   -

   o  YclassId = UUID5(vendorId, "Product Y")

   This ensures that Vendor A's Product Z cannot install firmware for
   Product Y and Product Y cannot install firmware for Product Z.

3.4.2.  Example 2: Upgrading Class ID

   Vendor A creates product X.  Later, Vendor A adds a new feature to
   product X, creating product X v2.  Product X requires a firmware
   update to work with firmware intended for product X v2.

   Vendor A creates UUIDs as follows:

   -

   o  vendorId = UUID5(DNS, "vendor-a.com")

   -

   o  XclassId = UUID5(vendorId, "Product X")

   -

   o  Xv2classId = UUID5(vendorId, "Product X v2")
   When product X receives the firmware update necessary to be
   compatible with product X v2, part of the firmware update changes the
   class ID to Xv2classId.

3.4.3.  Example 3: Shared Functionality

   Vendor A produces two products, product X and product Y.  These
   components share a common core (such as an operating system), but
   have different applications.  The common core and the applications
   can be updated independently.  To enable X and Y to receive the same
   common core update, they require the same class ID.  To ensure that
   only product X receives application X and only product Y receives
   application Y, product X and product Y must have different class IDs.
   The vendor creates Class IDs as follows:

   -

   o  vendorId = UUID5(DNS, "vendor-a.com")

   -

   o  XclassId = UUID5(vendorId, "Product X")

   -

   o  YclassId = UUID5(vendorId, "Product Y")

   -

   o  CommonClassId = UUID5(vendorId, "common core")

   Product X matches against both XclassId and CommonClassId.  Product Y
   matches against both YclassId and CommonClassId.

3.5.  Manifest Element: Precursor Image Digest Condition

   When a precursor image is required by the payload format, a precursor
   image digest condition MUST be present in the conditions list.  The
   precursor image may be installed or stored as a candidate.

   This element is MANDATORY for OPTIONAL to implement.

   Enables feature: differential updates.  Otherwise, it is
   not needed.

   Implements: Security Requirement MFSR4e REQ.SEC.AUTH.PRECURSOR (Section 4.3.9)

3.6.  Manifest Element: Required Image Version List

   When a payload applies to multiple versions of a firmware, the
   required image version list specifies which versions must be present
   for the update to be applied.  This allows the update author to
   target specific versions of firmware for an update, while excluding
   those to which it should not be applied.

   Where an update can only be applied over specific predecessor
   versions, that version MUST be specified by the Required Image
   Version List.

   This element is OPTIONAL.

   Implements: MFUR7 REQ.USE.IMG.VERSIONS (Section 4.5.7)

3.7.  Manifest Element: Best-Before timestamp condition Expiration Time

   This element tells a device the last application time. time at which the manifest expires
   and should no longer be used.  This is only usable in conjunction
   with a secure clock. source of time.

   This element is OPTIONAL and MAY enable use cases user stories where a secure
   clock
   source of time is provided and firmware is intended to expire regularly.
   predictably.

   Implements: Security Requirement MFSR3 REQ.SEC.EXP (Section 4.3.3)

3.8.  Manifest Element: Payload Format

   The format of the payload must MUST be indicated to devices is in an
   unambiguous way.  This element provides a mechanism to describe the
   payload format, within the signed metadata.

   This element is MANDATORY and MUST be present to enable devices to
   decode payloads correctly.

   Implements: Security Requirement MFSR4a, Usability Requirement MFUR5 REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT
   (Section 4.5.5)

3.9.  Manifest Element: Processing Steps

   A list representation of all payload processors necessary the Processing Steps required to process decode a nested format
   payload.  The representation MUST describe which algorithm(s) is used
   and any additional parameters needed required by those payload processors.  Each the algorithm(s).  The
   representation MAY group Processing Steps together in predefined
   combinations.

   A Processing Step SHOULD MAY indicate the expected digest of the payload
   after the processing is complete.

   Processing steps are distinct from
   Directives in that Directives apply to the manifest as a whole,
   whereas Processing Steps apply to an individual payload and provide
   instructions on how RECOMMENDED to unpack it. implement.

   Enables feature: Encrypted, compressed, packed formats

   Implements: Usability Requirement MFUR6 REQ.USE.IMG.NESTED (Section 4.5.6)

3.10.  Manifest Element: Storage Location

   This element tells the device which component is being updated. where to store a payload within a given
   component.  The device can use this to establish which permissions
   are necessary and the physical storage location to use.

   This element is MANDATORY and MUST be present to enable devices to
   store payloads to the correct location.

   Implements: Security Requirement MFSR4b REQ.SEC.AUTH.IMG_LOC (Section 4.3.6)

3.10.1.  Example 1: Two Storage Locations

   A device supports two components: an OS and an application.  These
   components can be updated independently, expressing dependencies to
   ensure compatibility between the components.  The firmware authority
   chooses two storage identifiers:

   -  OS

   -  APP

   o  "OS"

   o  "APP"

3.10.2.  Example 2: File System

   A device supports a full filesystem.  The firmware authority chooses
   to make use the storage identifier as the path at which to install the
   payload.  The payload may be a tarball, in which case, it unpacks the
   tarball into the specified path.

3.10.3.  Example 3: Flash Memory

   A device supports flash memory.  The firmware authority chooses to
   make the storage identifier the offset where the image should be
   written.

3.11.  Manifest Element: Component Identifier

   In a heterogeneous storage architecture, a storage identifier is
   insufficient to identify where and how to store a payload.  To
   resolve this, a component identifier indicates which part of the
   storage architecture is targeted by the payload.  In a homogeneous
   storage architecture, this element is unnecessary.

   This element is OPTIONAL and only necessary in heterogeneous storage
   architecture devices.

   N.B.  A serialisation MAY choose to combine Component Identifier and
   Storage Location (Section 3.10)
   Implements: MFUR3 REQ.USE.MFST.COMPONENT (Section 4.5.3)

3.12.  Manifest Element: URIs Resource Indicator

   This element is a list of weighted URIs that provides the information required for the device uses to
   select where to obtain a payload.
   acquire the resource.  This can be encoded in several ways:

   o  One URI

   o  A list of URIs

   o  A prioritised list or URIs

   o  A list of signed URIs

   This element is OPTIONAL and only needed when the target device does
   not intrinsically know where to find the payload.

   Note:

   N.B.  Devices will typically require URIs.

   Implements: Security Requirement MFSR4c REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7)

3.13.  Manifest Element: Payload Digest Digests

   This element contains the digest one or more digests of the payload. one or more payloads.
   This allows the target device to ensure authenticity of the payload.  It
   payload(s).  A serialisation MUST be
   possible provide a mechanism to specify more than select one
   payload digest, indexed by Manifest
   Element: from a list based on system parameters, such as XIP Address. address.

   This element is MANDATORY to implement and fundamentally necessary to
   ensure the authenticity and integrity of the payload.  Support for
   more than one digest is OPTIONAL to implement in a recipient device.

   Implements: Security Requirement MFSR4d, Usability Requirement MFUR8 REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT
   (Section 4.5.8)

3.14.  Manifest Element: Size

   The size of the payload in bytes.

   Variable-size storage locations MUST be set to exactly the size
   listed in this element.

   This element is MANDATORY and informs the target device how big of a
   payload to expect.  Without it, devices are exposed to some classes
   of denial of service attack.

   Implements: Security Requirement MFSR4d REQ.SEC.AUTH.EXEC (Section 4.3.8)

3.15.  Manifest Element: Signature

   This is not strictly a manifest element.  Instead, the manifest is
   wrapped by a standardised authentication container, such as a COSE
   ([RFC8152]) or CMS ([RFC5652]) signature object.  The authentication
   container MUST support multiple actors and multiple authentications. authentication
   methods.

   This element is MANDATORY and represents the foundation of all
   security properties of the manifest.  There are two exceptions to
   this requirement: 1) if the manifest is authenticated by a second
   manifest as a dependency and 2) if the manifest is authenticated by
   channel security and contains only channel information (such as
   URIs).

   Implements: Security Requirement MFSR5, MFSR6, MFUR4 REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS
   (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4)

3.16.  Manifest Element: Directives

   A list of Additional installation instructions

   Instructions that the device should execute, in order, execute when processing the
   manifest.  This information is distinct from the information
   necessary to process a payload (Processing Steps) and
   applies to the whole manifest including all payloads that it
   references.  Directives payload.  Additional installation instructions
   include information such as update timing (For example, install only
   on Sunday, at 0200), procedural considerations (for example, shut
   down the equipment under control before executing the update), pre
   and post-installation steps (for example, run a script).

   This element is OPTIONAL and enables some use cases. OPTIONAL.

   Implements: Usability Requirement MFUR1 REQ.USE.MFST.PRE_CHECK (Section 4.5.1)

3.17.  Manifest Element: Aliases

   A list of Digest/URI pairs.  A device should build an alias table
   while paring mechanism for a manifest tree and treat any aliases as top-ranked to augment or replace URIs
   for the corresponding digest. or URI lists
   defined by one or more of its dependencies.

   This element is OPTIONAL and enables some use cases. user stories.

   Implements: Usability Requirement MFUR2 REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2)

3.18.  Manifest Element: Dependencies

   A list of Digest/URI pairs that refer to other manifests by digest.
   The manifests that are linked in this way must be acquired and
   installed simultaneously in order to form required by the current manifest.
   Manifests are identified an an unambiguous way, such as a complete update. digest.

   This element is MANDATORY to use in deployments that include both
   multiple authorities and multiple payloads.

   Implements: Usability Requirement MFUR3 REQ.USE.MFST.COMPONENT (Section 4.5.3)

3.19.  Manifest Element: Content Key Distribution Method Encryption Wrapper

   Encrypting firmware images requires symmetric content encryption
   keys.  Since there are several methods to protect or distribute the
   symmetric content  The encryption keys, the manifest contains a element
   for wrapper provides the Content Key Distribution Method.  One examples information needed for such a
   Content Key Distribution Method is the usage of Key Tables, pointing
   device to content encryption keys, which themselves are encrypted using obtain or locate a key that it uses to decrypt the
   public keys of devices.
   firmware.  Typical choices for an encryption wrapper include CMS
   ([RFC5652]) or COSE ([RFC8152]).  This MAY be included in a
   decryption step contained in Processing Steps. Steps (Section 3.9).

   This element is MANDATORY to use for encrypted payloads,

   Implements: Security Requirement MFSR7. REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)

3.20.  Manifest Element: XIP Address

   In order to support XIP systems with multiple possible base
   addresses, it is necessary to specify which address the payload is
   linked for.

   For example a microcontroller may have a simple bootloader that
   chooses one of two images to boot.  That microcontroller then needs
   to choose one of two firmware images to install, based on which of
   its two images is older.

   Implements: MFUR8 REQ.USE.IMG.SELECT (Section 4.5.8)

3.21.  Manifest Element: Load-time metadata

   ## Manifest Element: Boot-time

   Load-time metadata ## provides the device with information that it needs
   in order to load one or more images.  This is effectively a copy
   operation from the permanent storage location of an image into the
   active use location of that image.  The metadata contains the source
   and destination of the image as well as any operations that are
   performed on the image.

   Implements: REQ.USE.LOAD (Section 4.5.10)

3.22.  Manifest Element: Run-time metadata

   Run-time metadata provides the device with any extra information
   needed to boot the device.  This may include information such as the
   entry-point of an XIP image or the kernel command-line of a linux
   image.

   Implements: REQ.USE.EXEC (Section 4.5.9)

3.23.  Manifest Element: Payload

   The Payload element provides a recipient device with the whole
   payload, contained within the manifest superstructure.  This enables
   the manifest and payload to be delivered simultaneously.

   Implements: REQ.USE.PAYLOAD (Section 4.5.11)

3.24.  Manifest Element: Key Claims

   The Key Claims element is not authenticated by the Signature
   (Section 3.15), instead, it provides a chain of key delegations (or
   references to them) for the device to follow in order to verify the
   key that authenticated the manifest using a trusted key.

   Implements: REQ.USE.DELEGATION (Section 4.5.13)

4.  Motivation for Manifest Fields

   The following sub-sections describe the threat model, user stories,
   security requirements, and usability requirements.

4.1.  Threat Model

   The following sub-sections aim to provide information about the
   threats that were considered, the security requirements that are
   derived from those threats and the fields that permit implementation
   of the security requirements.  This model uses the S.T.R.I.D.E.
   [STRIDE] approach.  Each threat is classified according to:

   -

   o  Spoofing Identity

   -

   o  Tampering with data

   -

   o  Repudiation

   -

   o  Information disclosure

   -

   o  Denial of service

   -

   o  Elevation of privilege

   This threat model only covers elements related to the transport of
   firmware updates.  It explicitly does not cover threats outside of
   the transport of firmware updates.  For example, threats to an IoT
   device due to physical access are out of scope.

4.2.  Threat Descriptions

4.2.1.  Threat MFT1:  THREAT.IMG.EXPIRED: Old Firmware

   Classification: Elevation of Privilege

   An attacker sends an old, but valid manifest with an old, but valid
   firmware image to a device.  If there is a known vulnerability in the
   provided firmware image, this may allow an attacker to exploit the
   vulnerability and gain control of the device.

   Threat Escalation: If the attacker is able to exploit the known
   vulnerability, then this threat can be escalated to ALL TYPES.

   Mitigated by: MFSR1 REQ.SEC.SEQUENCE (Section 4.3.1)

4.2.2.  Threat MFT2: Mismatched Firmware

   Classification: Denial of Service

   An attacker sends a valid firmware image, for the wrong type of
   device, signed by an actor with firmware installation permission on
   both types of device.  The firmware is verified by the device
   positively because it is signed by an actor with the appropriate
   permission.  This could have wide-ranging consequences.  For devices
   that are similar, it could cause minor breakage, or expose security
   vulnerabilities.  For devices that are very different, it is likely
   to render devices inoperable.

   Mitigated by: MFSR2

   Example:

   Suppose that two vendors, Vendor A and Vendor B, adopt the same trade
   name in different geographic regions, and they both make products
   with the same names, or product name matching is not used.  This
   causes firmware from Vendor A to match devices from Vendor B.

   If the vendors are the firmware authorities, then devices from Vendor
   A will reject images signed by Vendor B since they use different
   credentials.  However, if both devices trust the same firmware
   authority, then, devices from Vendor A could install firmware
   intended for devices from Vendor B.

4.2.3.  Threat MFT3:  THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old Firmware

   Classification: Elevation of Privilege

   An attacker targets a device that has been offline for a long time
   and runs an old firmware version.  The attacker sends an old, but
   valid manifest to a device with an old, but valid firmware image.
   The attacker-provided firmware is newer than the installed one but
   older than the most recently available firmware.  If there is a known
   vulnerability in the provided firmware image then this may allow an
   attacker to gain control of a device.  Because the device has been
   offline for a long time, it is unaware of any new updates.  As such
   it will treat the old manifest as unaware of any new updates.  As such
   it will treat the old manifest as the most current.

   Threat Escalation: If the attacker is able to exploit the known
   vulnerability, then this threat can be escalated to ALL TYPES.

   Mitigated by: REQ.SEC.EXP (Section 4.3.3)

4.2.3.  THREAT.IMG.INCOMPATIBLE: Mismatched Firmware

   Classification: Denial of Service

   An attacker sends a valid firmware image, for the wrong type of
   device, signed by an actor with firmware installation permission on
   both types of device.  The firmware is verified by the device
   positively because it is signed by an actor with the appropriate
   permission.  This could have wide-ranging consequences.  For devices
   that are similar, it could cause minor breakage, or expose security
   vulnerabilities.  For devices that are very different, it is likely
   to render devices inoperable.

   Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2)

4.2.3.1.  Example:

   Suppose that two vendors, Vendor A and Vendor B, adopt the most current.

   Threat Escalation: If same trade
   name in different geographic regions, and they both make products
   with the attacker same names, or product name matching is able not used.  This
   causes firmware from Vendor A to exploit match devices from Vendor B.

   If the known
   vulnerability, vendors are the firmware authorities, then this threat can be escalated to ALL TYPES.

   Mitigated by: MFSR3 devices from Vendor
   A will reject images signed by Vendor B since they use different
   credentials.  However, if both devices trust the same firmware
   authority, then, devices from Vendor A could install firmware
   intended for devices from Vendor B.

4.2.4.  Threat MFT4:  THREAT.IMG.FORMAT: The target device misinterprets the type of
        payload

   Classification: Denial of Service

   If a device misinterprets the type format of the firmware image, it may
   cause a device to install a firmware image incorrectly.  An
   incorrectly installed firmware image would likely cause the device to
   stop functioning.

   Threat Escalation: An attacker that can cause a device to
   misinterpret the received firmware image may gain elevation of
   privilege and potentially expand this to all types of threat.

   Mitigated by: MFSR4a REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5)

4.2.5.  Threat MFT5:  THREAT.IMG.LOCATION: The target device installs the payload to
        the wrong location

   Classification: Denial of Service

   If a device installs a firmware image to the wrong location on the
   device, then it is likely to break.  For example, a firmware image
   installed as an application could cause a device and/or an
   application to stop functioning.

   Threat Escalation: An attacker that can cause a device to
   misinterpret the received code may gain elevation of privilege and
   potentially expand this to all types of threat.

   Mitigated by: MFSR4b REQ.SEC.AUTH.IMG_LOC (Section 4.3.5)

4.2.6.  Threat MFT6:  THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting

   Classification: Denial of Service

   If a device does not know where to obtain the payload for an update,
   it may be redirected to an attacker's server.  This would allow an
   attacker to provide broken payloads to devices.

   Mitigated by: MFSR4c REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7)

4.2.7.  Threat MFT7:  THREAT.NET.MITM

4.2.8.  THREAT.IMG.REPLACE: Payload Verification on Boot Replacement

   Classification: Elevation of Privilege

   An attacker replaces a newly downloaded firmware after a device
   finishes verifying a manifest.  This could cause the device to
   execute the attacker's code.  This attack likely requires physical
   access to the device.  However, it is possible that this attack is
   carried out in combination with another threat that allows remote
   execution.  This is a typical Time Of Check/Time Of Use threat.

   Threat Escalation: If the attacker is able to exploit a known
   vulnerability, or if the attacker can supply their own firmware, then
   this threat can be escalated to ALL TYPES.

   Mitigated by: MFSR4d

4.2.8.  Threat MFT8: REQ.SEC.AUTH.EXEC (Section 4.3.8)

4.2.9.  THREAT.IMG.NON_AUTH: Unauthenticated Updates Images

   Classification: Elevation of Privilege / All Types

   If an attacker can install their firmware on a device, by
   manipulating either payload or metadata, then they have complete
   control of the device.

   Threat Escalation: If the attacker is able to exploit a known
   vulnerability, or if the attacker can supply their own firmware, then
   this threat can be escalated to ALL TYPES.

   Mitigated by: MFSR5

4.2.9.  Threat MFT9: REQ.SEC.AUTHENTIC (Section 4.3.4)

4.2.10.  THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images

   Classification: Denial of Service / All Types

   An attacker sends a valid, current manifest to a device that has an
   unexpected precursor image.  If a payload format requires a precursor
   image (for example, delta updates) and that precursor image is not
   available on the target device, it could cause the update to break.

   Threat Escalation:

   An attacker that can cause a device to install a payload against the
   wrong precursor image could gain elevation of privilege and
   potentially expand this to all types of threat.  However, it is
   unlikely that a valid differential update applied to an incorrect
   precursor would result in a functional, but vulnerable firmware.

   Mitigated by: MFSR4e

4.2.10.  Threat MFT10: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9)

4.2.11.  THREAT.UPD.INTEROP: Unqualified Firmware

   Classification: Denial of Service, Elevation of Privilege

   This threat can appear in several ways, however it is ultimately
   about interoperability of devices with other systems.  The owner or
   operator of a network needs to approve firmware for their network in
   order to ensure interoperability with other devices on the network,
   or the network itself.  If the firmware is not qualified, it may not
   work.  Therefore, if a device installs firmware without the approval
   of the network owner or operator, this is a threat to devices and the
   network.

   Threat Escalation: If the firmware expects configuration that is
   present in devices deployed in Network A, but not in devices deployed
   in Network B, then the device may experience degraded security,
   leading to threats of All Types.

   Mitigated by: MFSR6, MFSR8

4.2.10.1. REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL
   (Section 4.3.13)

4.2.11.1.  Example 1: Multiple Network Operators with a Single Device
           Operator

   In this example let us example, assume that Device Operators expect the rights to
   create firmware but that Network Operators expect the rights to
   qualify firmware as fit-for-purpose on their networks.  Additionally  Additionally,
   assume that an Device Operators manage devices that can be deployed on
   any network, including Network A and B in our example.

   An attacker may obtain a manifest for a device on Network A.  Then,
   this attacker sends that manifest to a device on Network B.  Because
   Network A and Network B are under control of different Operators, and
   the firmware for a device on Network A has not been qualified to be
   deployed on Network B, the target device on Network B is now in
   violation of the Operator B's policy and may get be disabled by this
   unqualified, but signed firmware.

   This is a denial of service because it can render devices inoperable.
   This is an elevation of privilege because it allows the attacker to
   make installation decisions that should be made by the Operator.

4.2.10.2.

4.2.11.2.  Example 2: Single Network Operator with Multiple Device
           Operators

   Multiple devices that interoperate are used on the same network and
   communicate with each other.  Some devices are manufactured and
   managed by Device Operator A and other devices by Device Operator B.
   A new firmware is released by Device Operator A that breaks
   compatibility with devices from Device Operator B.  An attacker sends
   the new firmware to the devices managed by Device Operator A without
   approval of the Network Operator.  This breaks the behaviour of the
   larger system causing denial of service and possibly other threats.
   Where the network is a distributed SCADA system, this could cause
   misbehaviour of the process that is under control.

4.2.11.  Threat MFT11:

4.2.12.  THREAT.IMG.DISCLOSURE: Reverse Engineering Of Firmware Image
         for Vulnerability Analysis

   Classification: All Types

   An attacker wants to mount an attack on an IoT device.  To prepare
   the attack he or she retrieves the provided firmware image and
   performs reverse engineering of the firmware image to analyze it for
   specific vulnerabilities.

   Mitigated by: MFSR7

4.2.12.  Threat MFT12: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)

4.2.13.  THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements

   Classification: Elevation of Privilege

   An authorised actor, but not the firmware authority, uses an override
   mechanism (MFUS2) (USER_STORY.OVERRIDE (Section 4.4.3)) to change an
   information element in a manifest signed by the firmware authority.
   For example, if the authorised actor overrides the digest and URI of
   the payload, the actor can replace the entire payload with a payload
   of their choice.

   Threat Escalation: By overriding elements such as payload
   installation instructions or firmware digest, this threat can be
   escalated to all types.

   Mitigated by: MFSR8

4.2.13.  Threat MFT13: REQ.SEC.ACCESS_CONTROL (Section 4.3.13)

4.2.14.  THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure

   Classification: Information Disclosure

   A third party may be able may be able to extract sensitive information from the
   manifest.

   Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14)

4.2.15.  THREAT.IMG.EXTRA: Extra data after image

   Classification: All Types

   If a third party modifies the image so that it contains extra code
   after a valid, authentic image, that third party can then use their
   own code in order to extract sensitive information from the
   manifest. make better use of an existing vulnerability

   Mitigated by: MFSR9 REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15)

4.3.  Security Requirements

   The security requirements here are a set of policies that mitigate
   the threats described in Section 4.1.

4.3.1.  Security Requirement MFSR1:  REQ.SEC.SEQUENCE: Monotonic Sequence Numbers

   Only an actor with firmware installation authority is permitted to
   decide when device firmware can be installed.  To enforce this rule,
   manifests MUST contain monotonically increasing sequence numbers.
   Manifests MAY use UTC epoch timestamps to coordinate monotonically
   increasing sequence numbers across many actors in many locations.  If
   UTC epoch timestamps are used, they MUST NOT be treated as times,
   they MUST be treated only as sequence numbers.  Devices MUST reject
   manifests with sequence numbers smaller than any onboard sequence
   number.

   Note: This is not a firmware version.  It is a manifest sequence
   number.  A firmware version may be rolled back by creating a new
   manifest for the old firmware version with a later sequence number.

   Mitigates: Threat MFT1 THREAT.IMG.EXPIRED (Section 4.2.1)

   Implemented by: Manifest Element: Monotonic Sequence Number (Section 3.2)

4.3.2.  Security Requirement MFSR2:  REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers

   Devices MUST only apply firmware that is intended for them.  Devices
   MUST know with fine granularity that a given update applies to their
   vendor, model, hardware revision, software revision.  Human-readable
   identifiers are often error-prone in this regard, so unique
   identifiers SHOULD be used.

   Mitigates: Threat MFT2 THREAT.IMG.INCOMPATIBLE (Section 4.2.3)

   Implemented by: Manifest Elements: Vendor ID Condition, Condition (Section 3.3), Class ID Condition
   (Section 3.4)

4.3.3.  Security Requirement MFSR3: Best-Before Timestamps  REQ.SEC.EXP: Expiration Time

   Firmware MAY expire after a given time.  Devices MAY provide a secure
   clock (local or remote).  If a secure clock is provided and the
   Firmware manifest has a best-before an expiration timestamp, the device MUST reject
   the manifest if current time is larger later than the best-before expiration time.

   Mitigates: Threat MFT3 THREAT.IMG.EXPIRED.ROLLBACK (Section 4.2.2)

   Implemented by: Manifest Element: Best-Before timestamp condition Expiration Time (Section 3.7)

4.3.4.  Security Requirement MFSR5:  REQ.SEC.AUTHENTIC: Cryptographic Authenticity

   The authenticity of an update must MUST be demonstrable.  Typically, this
   means that updates must be digitally authenticated.  Because the
   manifest contains information about how to install the update, the
   manifest's authenticity must MUST also be demonstrable.  To reduce the
   overhead required for validation, the manifest contains the digest of
   the firmware image, rather than a second digital signature.  The
   authenticity of the manifest can be verified with a digital signature
   or Message Authentication Code, the authenticity of the firmware
   image is tied to the manifest by the use of a digest of the firmware
   image.

   Mitigates: Threat MFT8 THREAT.IMG.NON_AUTH (Section 4.2.9)

   Implemented by: Signature, Signature (Section 3.15), Payload Digest
   (Section 3.13)

4.3.5.  Security Requirement MFSR4a:  REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type

   The type of payload (which may be independent of format) MUST be
   authenticated.  For example, the target must know whether the payload
   is XIP firmware, a loadable module, or serialized configuration data.

   Mitigates: MFT4 THREAT.IMG.FORMAT (Section 4.2.4)

   Implemented by: Manifest Elements: Payload Format, Format (Section 3.8), Storage Location
   (Section 3.10)

4.3.6.  Security Requirement MFSR4b: REQ.SEC.AUTH.IMG_LOC: Authenticated Storage
        Location

   The location on the target where the payload is to be stored MUST be
   authenticated.

   Mitigates: MFT5 THREAT.IMG.LOCATION (Section 4.2.5)

   Implemented by: Manifest Elements: Storage Location (Section 3.10)

4.3.7.  Security Requirement MFSR4c:  REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Resource Location

   The location where a target should find a payload MUST be
   authenticated.

   Mitigates: MFT6 THREAT.NET.REDIRECT (Section 4.2.6)

   Implemented by: Manifest Elements: URIs Resource Indicator (Section 3.12)

4.3.8.  Security Requirement MFSR4d:  REQ.SEC.AUTH.EXEC: Secure Boot Execution

   The target SHOULD verify firmware at time of boot.  This requires
   authenticated payload size, and digest.

   Mitigates: MFT7 THREAT.IMG.REPLACE (Section 4.2.8)

   Implemented by: Manifest Elements: Payload Digest, Digest (Section 3.13), Size (Section 3.14)

4.3.9.  Security Requirement MFSR4e:  REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images

   If an update uses a differential compression method, it MUST specify
   the digest of the precursor image and that digest MUST be
   authenticated.

   Mitigates: MFT9 THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10)

   Implemented by: Manifest Elements: Precursor Image Digest Condition (Section 3.5)

4.3.10.  Security Requirement MFSR4f:  REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs

   The identifiers that specify firmware compatibility MUST be
   authenticated to ensure that only compatible firmware is installed on
   a target device.

   Mitigates: MFT2 THREAT.IMG.INCOMPATIBLE (Section 4.2.3)

   Implemented By: Manifest Elements: Vendor ID Condition, Class ID Condition

4.3.11.  Security Requirement MFSR4f: Authenticated Vendor and Class IDs

   The identifiers that specify firmware compatibility MUST be
   authenticated to ensure that only compatible firmware is installed on
   a target device.

   Mitigates: MFT2

   Implemented By: Manifest Elements: Vendor ID Condition, (Section 3.3), Class ID Condition

4.3.12.  Security Requirement MFSR6:
   (Section 3.4)

4.3.11.  REQ.SEC.RIGHTS: Rights Require Authenticity

   If a device grants different rights to different actors, exercising
   those rights MUST be accompanied by proof of those rights, in the
   form of proof of authenticity.  Authenticity mechanisms such as those
   required in MFSR5 REQ.SEC.AUTHENTIC (Section 4.3.4) are acceptable but need
   to follow the end-to-end security model.

   For example, if a device has a policy that requires that firmware
   have both an Authorship right and a Qualification right and if that
   device grants Authorship and Qualification rights to different
   parties, such as a Device Operator and a Network Operator,
   respectively, then the firmware cannot be installed without proof of
   rights from both the Device and the Network Operator.

   Mitigates: MFT10 THREAT.UPD.INTEROP (Section 4.2.11)

   Implemented by: Signature

4.3.13.  Security Requirement MFSR7: Firmware encryption (Section 3.15)

4.3.12.  REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption

   The manifest information model must MUST enable encrypted payloads.
   Encryption helps to prevent third parties, including attackers, from
   reading the content of the firmware image.  This can protect against
   confidential information disclosures and discovery of vulnerabilities
   through reverse engineering.  Therefore the manifest must convey the
   information required to allow an intended recipient to decrypt an
   encrypted payload.

   Mitigates: MFT11 THREAT.IMG.DISCLOSURE (Section 4.2.12)

   Implemented by: Manifest Element: Content Key Distribution Method

4.3.14.  Security Requirement MFSR8: Encryption Wrapper (Section 3.19)

4.3.13.  REQ.SEC.ACCESS_CONTROL: Access Control Lists

   If a device grants different rights to different actors, then an
   exercise of those rights must MUST be validated against a list of rights
   for the actor.  This typically takes the form of an Access Control
   List (ACL).  ACLs are applied to two scenarios:

   1.  An ACL decides which elements of the manifest may be overridden
       and by which actors.

   2.  An ACL decides which component identifier/storage identifier
       pairs can be written by which actors.

   Mitigates: MFT12, MFT10 THREAT.MFST.OVERRIDE (Section 4.2.13), THREAT.UPD.INTEROP
   (Section 4.2.11)

   Implemented by: Client-side code, not specified in manifest.

4.3.15.  Security Requirement MFSR9:

4.3.14.  REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests

   It must MUST be possible to encrypt part or all of the manifest.  This may
   be accomplished with either transport encryption or with at-rest
   encryption, for example COSE_Encrypt.
   encryption.

   Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14)

   Implemented by: External Encryption Wrapper / Transport Security

4.3.15.  REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest

   The digest SHOULD cover all available space in a fixed-size storage
   location.  Variable-size storage locations MUST be restricted to
   exactly the size of deployed payload.  This prevents any data from
   being distributed without being covered by the digest.  For example,
   XIP microcontrollers typically have fixed-size storage.  These
   devices should deploy a digest that covers the deployed firmware
   image, concatenated with the default erased value of any remaining
   space.

   Mitigates: MFT13 THREAT.IMG.EXTRA (Section 4.2.15)

   Implemented by: TLS/COSE Payload Digests (Section 3.13)

4.4.  User Stories

   User stories provide expected use cases.  These are used to feed into
   usability requirements.

4.4.1.  Use Case MFUS1:  USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions

   As an a Device Operator, I want to provide my devices with additional
   installation instructions so that I can keep process details out of
   my payload data.

   Some installation instructions might be:

   -

   o  Use a table of hashes to ensure that each block of the payload is
      validate before writing.

   -

   o  Do not report progress.

   -

   o  Pre-cache the update, but do not install.

   -

   o  Install the pre-cached update matching this manifest.

   -

   o  Install this update immediately, overriding any long-running
      tasks.

   Satisfied by: MFUR1 REQ.USE.MFST.PRE_CHECK (Section 4.5.1)

4.4.2.  Use Case MFUS2:  USER_STORY.MFST.FAIL_EARLY: Fail Early

   As a designer of a resource-constrained IoT device, I want bad
   updates to fail as early as possible to preserve battery life and
   limit consumed bandwidth.

   Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)

4.4.3.  USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements

   As a Network Operator, I would like to be able to override the non-
   critical information in the manifest so that I can control my devices
   more precisely.  This assumes that the Device Operator delegated
   rights about the device  The authority to override this information is
   provided via the Network Operator. installation of a limited trust relationship by
   another authority.

   Some examples of potentially overridable information:

   -  URIs:

   o  URIs (Section 3.12): this allows the Network Operator to direct
      devices to their own infrastructure in order to reduce network
      load.

   -

   o  Conditions: this allows the Network Operator to pose additional
      constraints on the installation of the manifest.

   -  Directives:

   o  Directives (Section 3.16): this allows the Network Operator to add
      more instructions such as time of installation.

   -

   o  Processing Steps: Steps (Section 3.9): If an intermediary performs an
      action on behalf of a device, it may need to override the
      processing steps.  It is still possible for a device to verify the
      final content and the result of any processing step that specifies
      a digest.  Some processing steps should be non-overridable.

   Satisfied by: MFUR2, MFUR3

4.4.3.  Use Case MFUS3: Modular USER_STORY.OVERRIDE (Section 4.4.3),
   REQ.USE.MFST.COMPONENT (Section 4.5.3)

4.4.4.  USER_STORY.COMPONENT: Component Update

   As an Operator, I want to divide my firmware into frequently updated
   and infrequently updated components, so that
   I can reduce the size of
   updates and updates, make different parties responsible
   for different components, and divide my firmware into frequently
   updated and infrequently updated components.

   Satisfied by: MFUR3

4.4.4.  Use Case MFUS4: REQ.USE.MFST.COMPONENT (Section 4.5.3)

4.4.5.  USER_STORY.MULTI_AUTH: Multiple Authorisations

   As a Device Operator, I want to ensure the quality of a firmware
   update before installing it, so that I can ensure interoperability of
   all devices in my product family.  I want to restrict the ability to
   make changes to my devices to require my express approval.

   Satisfied by: MFUR4, MFSR8

4.4.5.  Use Case MFUS5: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4),
   REQ.SEC.ACCESS_CONTROL (Section 4.3.13)

4.4.6.  USER_STORY.IMG.FORMAT: Multiple Payload Formats

   As an Operator, I want to be able to send multiple payload formats to
   suit the needs of my update, so that I can optimise the bandwidth
   used by my devices.

   Satisfied by: MFUR5

4.4.6.  Use Case MFUS6: REQ.USE.IMG.FORMAT (Section 4.5.5)

4.4.7.  USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information
        Disclosures

   As an firmware author, I want to prevent confidential information
   from being disclosed during firmware updates.  It is assumed that
   channel security or at-rest encryption is adequate to protect the
   manifest itself against information disclosure.

   Satisfied by: MFSR7

4.4.7.  Use Case MFUS7: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)

4.4.8.  USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking
        Unknown Formats

   As a Device Operator, I want devices to determine whether they can
   process a payload prior to downloading it.

   In some cases, it may be desirable for a third party to perform some
   processing on behalf of a target.  For this to occur, the third party
   MUST indicate what processing occurred and how to verify it against
   the Trust Provisioning Authority's intent.

   This amounts to overriding Processing Steps (Section 3.9) and URIs.
   Resource Indicator (Section 3.12).

   Satisfied by: MFUR6, MFUR2

4.4.8.  Use Case MFUS8: REQ.USE.IMG.FORMAT (Section 4.5.5), REQ.USE.IMG.NESTED
   (Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2)

4.4.9.  USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of
        Target Firmware

   As a Device Operator, I want to be able to target devices for updates
   based on their current firmware version, so that I can control which
   versions are replaced with a single manifest.

   Satisfied by: MFUR7

4.4.9.  Use Case MFUS9: REQ.USE.IMG.VERSIONS (Section 4.5.7)

4.4.10.  USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images

   As a developer, I want to be able to sign two or more versions of my
   firmware in a single manifest so that I can use a very simple
   bootloader that chooses between two or more images that are executed
   in-place.

   Satisfied by: MFUR8

4.4.10.  Use Case MFUS10: REQ.USE.IMG.SELECT (Section 4.5.8)

4.4.11.  USER_STORY.EXEC.MFST: Secure Boot Execution Using Manifests

   As a signer for both secure boot execution/boot and firmware deployment, I
   would like to use the same signed document for both tasks so that my
   data size is smaller, I can share common code, and I can reduce
   signature verifications.

   Satisfied by: MFUR9

4.4.11.  Use Case MFUS11: REQ.USE.EXEC (Section 4.5.9)

4.4.12.  USER_STORY.EXEC.DECOMPRESS: Decompress on Load

   As a developer of firmware for a run-from-RAM device, I would like to
   use compressed images and to indicate to the bootloader that I am
   using a compressed image in the manifest so that it can be used with
   secure boot. execution/boot.

   Satisfied by: MFUR10

4.4.12.  Use Case MFUS12: REQ.USE.LOAD (Section 4.5.10)

4.4.13.  USER_STORY.MFST.IMG: Payload in Manifest

   As an operator of a constrained network, I would like to be able to
   send a small payload in the same packet as the manifest so that I can
   reduce network traffic.

   Satisfied by: MFUR11

4.4.13.  Use Case MFUS13: REQ.USE.PAYLOAD (Section 4.5.11)

4.4.14.  USER_STORY.MFST.PARSE: Simple Parsing

   As a developer for constrained devices, I want a low complexity
   library for processing updates so that I can fit more application
   code on my device.

   Satisfied by: MFUR12 REQ.USE.PARSE (Section 4.5.12)

4.4.15.  USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest

   As an operator that rotates delegated authority more often than
   delivering firmware updates, I would like to delegate a new authority
   when I deliver a firmware update so that I can accomplish both tasks
   in a single transmission.

   Satisfied by: REQ.USE.DELEGATION (Section 4.5.13)

4.4.16.  USER_STORY.MFST.PRE_CHECK: Update Evaluation

   As an operator of a constrained network, I would like devices on my
   network to be able to evaluate the suitability of an update prior to
   initiating any large download so that I can prevent unnecessary
   consumption of bandwidth.

   Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)

4.5.  Usability Requirements

   The following usability requirements satisfy the user stories listed
   above.

4.5.1.  Usability Requirement MFUR1  REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks

   It must MUST be possible to provide all information necessary for the
   processing of a manifest into author to place ALL information
   required to process an update in the manifest.

   For example: Information about which precursor image is required for
   a differential update MUST be placed in the manifest, not in the
   differential compression header.

   Satisfies: User story MFUS1 [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check),
   USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1)

   Implemented by: Manifest Element: Directives Additional installation instructions (Section 3.16)

4.5.2.  Usability Requirement MFUR2  REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location

   It must MUST be possible to redirect payload fetches.  This applies where
   two manifests are used in conjunction.  For example, a Device
   Operator creates a manifest specifying a payload and signs it, and
   provides a URI for that payload.  A Network Operator creates a second
   manifest, with a dependency on the first.  They use this second
   manifest to override the URIs provided by the Device Operator,
   directing them into their own infrastructure instead.  Some devices
   may provide this capability, while others may only look at canonical
   sources of firmware.  For this to be possible, the device must fetch
   the payload, whereas a device that accpets accepts payload pushes will ignore
   this feature.

   N.B.  If a manifest is delivered over an authenticated channel and
   that manifest contains only override information for which the remote
   is authorised, then it can be considered authenticated by the channel
   authentication.

   Satisfies: User story MFUS2 USER_STORY.OVERRIDE (Section 4.4.3)

   Implemented by: Manifest Element: Aliases (Section 3.17)

4.5.3.  Usability Requirement MFUR3  REQ.USE.MFST.COMPONENT: Component Updates

   It must MUST be possible express the requirement to install one or more
   payloads from one or more authorities so that a multi-payload update
   can be described.  This allows multiple parties with different
   permissions to collaborate in creating a single update for the IoT
   device, across multiple components.

   This requirement effectively means that it must be possible to
   construct a tree of manifests on a multi-image target.

   Because

   In order to enable devices can be either HeSA or HoSA both with a heterogeneous storage architecture,
   the manifest must enable specification of both storage system and the
   storage location within that storage system must be possible
   to specify.  In a HoSA device, the payload location may be as simple
   as an address, or a file path.  In a HeSA device, the payload
   location may be scoped system.

   Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT
   (Section 4.4.4)

   Implemented by a component identifier.  It is expedient to
   consider that all HoSA devices are HeSA devices with a single
   component. Manifest Element: Dependencies, StorageIdentifier,
   ComponentIdentifier

4.5.3.1.  Example 1: Multiple Microcontrollers

   An IoT device with multiple microcontrollers in the same physical
   device (HeSA) will likely require multiple payloads with different
   component identifiers.

4.5.3.2.  Example 2: Code and Configuration

   A firmware image can be divided into two payloads: code and
   configuration.  These payloads may require authorizations from
   different actors in order to install (see MFSR6 and MFSR8). REQ.SEC.RIGHTS
   (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)).  This
   structure means that multiple manifests may be required, with a
   dependency structure between them.

4.5.3.3.  Example 3: Multiple Chunks Software Modules

   A firmware image can be divided into multiple functional blocks for
   separate testing and distribution.  This means that code would need
   to be distributed in multiple payloads.  For example, this might be
   desirable in order to ensure that common code between devices is
   identical in order to reduce distribution bandwidth.

   Satisfies: User story MFUS2, MFUS3

   Implemented by Manifest Element: Dependencies, StorageIdentifier,
   ComponentIdentifier

4.5.4.  Usability Requirement MFUR4  REQ.USE.MFST.MULTI_AUTH: Multiple authentications

   It MUST be possible to sign authenticate a manifest multiple times so that
   signatures
   authorisations from multiple parties with different permissions can
   be required in order to authorise installation of a manifest.

   Satisfies: User story MFUS4 USER_STORY.MULTI_AUTH (Section 4.4.5)

   Implemented by: COSE Signature (or similar) (Section 3.15)

4.5.5.  REQ.USE.IMG.FORMAT: Format Usability Requirement MFUR5

   The manifest format serialisation MUST accommodate any payload format that
   an Operator wishes to use.  This enables the recipient to detect
   which format the Operator has chosen.  Some examples of payload
   format would be:

   - are:

   o  Binary

   -

   o  Elf

   -

   o  Differential

   -

   o  Compressed

   -
   o  Packed configuration

   -

   o  Intel HEX

   -

   o  S-Record

   Satisfies: User story MFUS5 USER_STORY.IMG.FORMAT (Section 4.4.6)
   USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8)

   Implemented by: Manifest Element: Payload Format (Section 3.8)

4.5.6.  Usability Requirement MFUR6  REQ.USE.IMG.NESTED: Nested Formats

   The manifest format must serialisation MUST accommodate nested formats,
   announcing to the target device all the nesting steps and any
   parameters used by those steps.

   Satisfies: User story MFUS6 USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7)

   Implemented by: Manifest Element: Processing Steps (Section 3.9)

4.5.7.  Usability Requirement MFUR7  REQ.USE.IMG.VERSIONS: Target Version Matching

   The manifest format must serialisation MUST provide a method to specify multiple
   version numbers of firmware to which the manifest applies, either
   with a list or with range matching.

   Satisfies: User story MFUS8 USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9)

   Implemented by: Manifest Element: Required Image Version List (Section 3.6)

4.5.8.  Usability Requirement MFUR8  REQ.USE.IMG.SELECT: Select Image by Destination

   The manifest format must serialisation MUST provide a mechanism to list multiple
   equivalent payloads by Execute-In-Place Installation Address,
   including the payload digest and, optionally, payload URIs.

   Satisfies: User story MFUS9 USER_STORY.IMG.SELECT (Section 4.4.10)

   Implemented by: Manifest Element: XIP Address (Section 3.20)

4.5.9.  Usability Requirement MFUR9: Bootable  REQ.USE.EXEC: Executable Manifest

   It must MUST be possible to describe a bootable an executable system with a manifest
   on both Execute-In-Place microcontrollers and on complex operating
   systems.  This requires the manifest to specify the digest of each
   statically linked storage location. dependency.  In addition, the manifest must
   serialisation MUST be able to express metadata used by the bootloader, metadata, such as a kernel
   command-line.
   command-line, used by any loader or bootloader.

   Satisfies: User story MFUS10 USER_STORY.EXEC.MFST (Section 4.4.11)

   Implemented by: Manifest Element: Boot-time Metadata Run-time metadata (Section 3.22)

4.5.10.  Usability Requirement MFUR10:  REQ.USE.LOAD: Load-Time Information

   It must MUST be possible to specify additional metadata for load time
   processing of a payload, such as load-address, cryptographic information, load-
   address, and compression algorithm.

   N.B. load comes before boot. exec/boot.

   Satisfies: User Story MFUS11 USER_STORY.EXEC.DECOMPRESS (Section 4.4.12)

   Implemented by: Manifest Element: Load-time Metadata metadata (Section 3.21)

4.5.11.  Usability Requirement MFUR11:  REQ.USE.PAYLOAD: Payload in Manifest Superstructure

   It must MUST be possible to place a payload in the same structure as the
   manifest.  This typically places MAY place the payload in the same packet as the
   manifest.

   Satisfies: User Story MFUS12 USER_STORY.MFST.IMG (Section 4.4.13)

   Implemented by: Manifest Element: Payload (Section 3.23)

4.5.12.  Usability Requirement MFUR12:  REQ.USE.PARSE: Simple Parsing

   The structure of the manifest must MUST be simple to parse, without need
   for a general-purpose parser.

   Satisfies: User Story MFUS13 USER_STORY.MFST.PARSE (Section 4.4.14)

   Implemented by: N/A

4.5.13.  REQ.USE.DELEGATION: Delegation of Authority in Manifest

   Any serialisation MUST enable the delivery of a key claim with, but
   not authenticated by a manifest.  This key claim delivers a new key
   with which the recipient can verify the manifest.

   Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15)

   Implemented by: Key Claims (Section 3.24)

5.  Security Considerations

   Security considerations for this document are covered in Section 4.

6.  IANA Considerations

   This document does not require any actions by IANA.

7.  Acknowledgements

   We would like to thank our working group chairs, Dave Thaler, Russ
   Housley and David Waltermire, for their review comments and their
   support.

   We would like to thank the participants of the 2018 Berlin SUIT
   Hackathon and the June 2018 virtual design team meetings for their
   discussion input.  In particular, we would like to thank Koen
   Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus
   Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson,
   Jan-Frederik Rieckers Rieckers, Francisco Acosta, Anton Gerasimov, Matthias
   Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm,
   Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said
   Gharout, and Milen Stoychev.

   We would like to thank those who contributed to the development of
   this information model.  In particular, we would like to thank
   Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, Gary
   Thomson.

8.  References

8.1.  Normative References

   [I-D.ietf-suit-architecture]
              Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A
              Firmware Update Architecture for Internet of Things
              Devices", draft-ietf-suit-architecture-02 draft-ietf-suit-architecture-05 (work in
              progress), January April 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

8.2.  Informative References

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              DOI 10.17487/RFC4122, July 2005,
              <https://www.rfc-editor.org/info/rfc4122>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/info/rfc5652>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [STRIDE]   Microsoft, "The STRIDE Threat Model", May 2018,
              <https://msdn.microsoft.com/en-us/library/
              ee823878(v=cs.20).aspx>.

8.3.  URIs

   [1] mailto:suit@ietf.org

   [2] https://www1.ietf.org/mailman/listinfo/suit

   [3] https://www.ietf.org/mail-archive/web/suit/current/index.html

Appendix A.  Mailing List Information

   The discussion list for this document is located at the e-mail
   address suit@ietf.org [1].  Information on the group and information
   on how to subscribe to the list is at
   https://www1.ietf.org/mailman/listinfo/suit [2]

   Archives of the list can be found at: https://www.ietf.org/mail-
   archive/web/suit/current/index.html [3]

Authors' Addresses

   Brendan Moran
   Arm Limited

   EMail: Brendan.Moran@arm.com

   Hannes Tschofenig
   Arm Limited

   EMail: hannes.tschofenig@gmx.net

   Henk Birkholz
   Fraunhofer SIT

   EMail: henk.birkholz@sit.fraunhofer.de