A Binary Manifest Serialization Format
draft-pagel-suit-manifest-00

Document Type Active Internet-Draft (individual)
Last updated 2018-09-12
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
SUIT                                                           M. Pagel
Internet Draft                                           Microsoft Corp
Intended status: Standards Track                     September 12, 2018
Expires: March 2018

                  A Binary Manifest Serialization Format
                         draft-pagel-suit-manifest-00

Abstract

   This specification describes the serialization format of a software
   update manifest that is suitable for low-end devices as it
   eliminates the need to execute a parser.

   A manifest is a metadata structure describing the firmware, the
   devices to which it applies, and cryptographic information
   protecting 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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on March 12, 2019.

Pagel                   Expires March 12, 2019                 [Page 1]
Internet-Draft          Binary Manifest Format           September 2018

Copyright Notice

   Copyright (c) 2018 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
   (http://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.

Table of Contents

   1. Introduction...................................................2
   2. Pros and Cons vs CBOR based Format.............................5
   3. Manifest Format in Detail......................................5
   4. Security Considerations........................................8
      4.1. MFSR1: Monotonic Sequence Numbers.........................8
      4.2. MFSR2: Vendor, Device-type Identifiers....................8
      4.3. MFSR3: Best-Before Timestamps.............................8
      4.4. MFSR5: Cryptographic Authenticity.........................9
      4.5. MFSR4a/b: Authenticated Payload Type and Storage Location.9
      4.6. MFSR4c: Authenticated Remote Resource Location............9
      4.7. MFSR4d: Secure Boot.......................................9
      4.8. MFSR4e: Authenticated precursor images....................9
      4.9. MFSR4f: Authenticated Vendor and Class IDs................9
      4.10. MFSR6: Rights Require Authenticity.......................9
      4.11. MFSR7: Firmware encryption..............................10
   5. IANA Considerations...........................................10
   6. Security Considerations.......................................10
   7. Mailing List Information......................................10
   8. References....................................................10
      8.1. Normative References.....................................10
   Author's Addresses...............................................11

1. Introduction

   This document describes a binary format for secured, signed software
   update "manifests" that is suitable for low-end devices as it
   eliminates the need to execute a parser.

   The SUIT architecture and information model are designed to maximize
   flexibility. However, in the field we expect each platform provider

Pagel                   Expires March 12, 2019                 [Page 2]
Internet-Draft          Binary Manifest Format           September 2018

   to pick a single option to implement within their software stack to
   keep code as small as possible. For example, basic devices typically
   support only a single compression or crypto algorithm and associated
   signature format. Therefore, the manifest used in the field does not
   need to specify such algorithms as such decision have already been
   made by the platform provider. SUIT compliant development tools or
   Update Servers may need to support different options if they want to
   target multiple device platforms.

   We expect each device platform to maintain a set of policies
Show full document text