[Suit] [suit]: draft-moran-suit-manifest-02
Brendan Moran <Brendan.Moran@arm.com> Tue, 03 July 2018 21:08 UTC
Return-Path: <Brendan.Moran@arm.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3926130E0F for <suit@ietfa.amsl.com>; Tue, 3 Jul 2018 14:08:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpO8FW_gQE_4 for <suit@ietfa.amsl.com>; Tue, 3 Jul 2018 14:08:05 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20084.outbound.protection.outlook.com [40.107.2.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335BF130DF5 for <suit@ietf.org>; Tue, 3 Jul 2018 14:08:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x2luU4OI2enrzzJBXArFN7vOCMxMUuVatcxxeBpsoXE=; b=Kn5t/x7cuQToamzS2GJCp4Y/Ucl5uV/zBM4PN1gnNA4iHqUvNrGT1iQnHj7zzDoA8wU0b6EK6cP83uyb0C24H/7HL2tH059X1+nV3EzPQlHMKq7RNuB65Y4bj7j834EiNkXxGAkgsP/dJ6Q+0s7WtUGrXu0OpW2xdbhezLqqsnY=
Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com (10.172.217.150) by AM4PR0802MB2339.eurprd08.prod.outlook.com (10.172.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.19; Tue, 3 Jul 2018 21:08:02 +0000
Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::3c9f:d4ca:23a0:2aad]) by AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::3c9f:d4ca:23a0:2aad%4]) with mapi id 15.20.0906.026; Tue, 3 Jul 2018 21:08:02 +0000
From: Brendan Moran <Brendan.Moran@arm.com>
To: suit <suit@ietf.org>
CC: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Thread-Topic: [suit]: draft-moran-suit-manifest-02
Thread-Index: AQHUExHtnaLT8k9ra0yYs7g0XR6lpQ==
Date: Tue, 03 Jul 2018 21:08:02 +0000
Message-ID: <FDAB87B5-A7CB-4BBC-B7CF-763355B099D8@arm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.8.2)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com;
x-originating-ip: [81.101.7.188]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR0802MB2339; 7:1TCty/isQQZdzRoAdxNrPYqLDSFxFFvTyK/4gVbP4pjcDF/QUdnZMvKwVG4u4UTSJK0TGbXLZn0PFP5YEa0nfLwzafPHxlL+pH/ZkVPjCTKOUTVEdY6Uqc9PwUzePDPmWdPrDOh+i9H+5oOp0AgTrFxTMa7xHb32W76wkeyZnwdO/ufcc/IhMsUDQpfEl6Mek2wHaeTXJIkyBoUqGRGlr3e1EQNfvWxz2ATFp2jzxGAOmihkh246d/eC8Yb0M2N/
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-ms-office365-filtering-correlation-id: 2241744a-cc4d-49b3-8b87-08d5e1291011
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:AM4PR0802MB2339;
x-ms-traffictypediagnostic: AM4PR0802MB2339:
x-microsoft-antispam-prvs: <AM4PR0802MB2339FE93B8DA759FDC084E95EA420@AM4PR0802MB2339.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(131327999870524)(223705240517415);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM4PR0802MB2339; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0802MB2339;
x-forefront-prvs: 0722981D2A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(396003)(366004)(39860400002)(189003)(199004)(40434004)(5250100002)(86362001)(102836004)(105586002)(14454004)(50226002)(106356001)(36756003)(6116002)(8936002)(6436002)(316002)(3846002)(606006)(68736007)(6506007)(53936002)(66066001)(7736002)(478600001)(6512007)(236005)(99286004)(486006)(6916009)(2906002)(72206003)(33656002)(6306002)(54896002)(5024004)(256004)(14444005)(25786009)(82746002)(81156014)(81166006)(186003)(2616005)(97736004)(2900100001)(4326008)(57306001)(6486002)(83716003)(1857600001)(966005)(476003)(5660300001)(26005)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0802MB2339; H:AM4PR0802MB2260.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: WRG+n4pJu6ycj7+G6OcLgeJouXMb2JqT+7ZQCIuc/MvpZVgHFLjR1iWKBgh3r8tmNnaYYJOT1jT14d3gZB8WisSXR8sE8RZZSf/bhx8KhzmwH4PGyVproOjNWGdUUsYd8on4WH62UcGFYW8ek2MzXKLR7sCg/QMANBbenmR+ccWKBMCnZgTKOT/ez7gfU1YU47O+9r7/eYK3anE3LWDO6QvmphBy2Ts/0EDC06DM0EpjVOwcy37bO7CnDL4C8iaoac07vbv+PitCiKwfc4+ap3+bnCaK9Fsib1r4eqKsBbeAHgHpY+3AgEeF/KqZF44juWQ8Np9PnWaq/m3qmx69SblMrhFXLZH/phcpZhDA4Ss=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_FDAB87B5A7CB4BBCB7CF763355B099D8armcom_"
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2241744a-cc4d-49b3-8b87-08d5e1291011
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2018 21:08:02.1066 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2339
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/rc1gkzf2jhICwcXHSq5JggdGiHo>
Subject: [Suit] [suit]: draft-moran-suit-manifest-02
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2018 21:08:10 -0000
This draft is a significant departure from previous drafts, so I think it is important to highlight the changes. The draft requires a lot of text that hasn’t been written yet, so I will try to put some of that here for discussion. https://datatracker.ietf.org/doc/draft-moran-suit-manifest/ # Summary of changes There are a large number of changes in this draft. In addition, the text description of the manifest is yet to be completed. The top level manifest element remains a CBOR array. The primary reason for this is that many of the initial elements are mandatory (see the information model for more detail). In addition to this, the ordering is important because the manifest is a signed document. COSE uses the same paradigm: where fields are mandatory, they are encoded as an array. Where there are optional fields (COSE_Headers) they are encoded as a map (if unsigned) or as a map, wrapped in a bstr if signed. The primary changes are: 1. Severable text 2. Digest Info is moved to a top-level element 3. Sequence number is now called sequence number instead of timestamp 4. Conditions are divided into preconditions and postconditions 5. Dependencies, Aliases, and payload info are now resources 6. Payloadinfo is divided into resources, processors, and targets # Severable text: Text is for humans. Devices shouldn’t parse it. Therefore, we have moved text information out of the manifest. However, humans need to know that the text they are reading correctly corresponds to the manifest they are looking at. Therefore, we have made a container for a COSE_Sign / COSE_Mac and a map of text values. In addition to this, the text values are hashed and the hash is included in the manifest to ensure that the text portion is not modified or corrupted in transit. This means that, while a manifest with text may be delivered to an update server, that server can strip off the text and deliver only the authenticated, machine-readable part to a target device. This results in reduced bandwidth, reduced buffer sizes, more expressive text information, and reduced opportunity to abuse variably sized fields. # Digest info at the top level Digests are used in many places in the manifest. The information required to interpret digests, therefore, must be a top-level element. All digests in any given manifest must use the same digest algorithm. # Sequence Number The use of timestamp as sequence number has caused confusion regularly, so we have changed timestamp to sequence number in this draft. # PreConditions and PostConditions There has been significant debate about the use of preconditions and postconditions, with several important use cases. Because of this, conditions has been divided into preconditions and postconditions. # Dependencies, Aliases, PayloadInfo Each of these has very similar information. Because of this, it seems reasonable to group them into a common structure that just identifies the type of reference. # Resources, Processors, Targets To satisfy complex requirements, we considered several use-cases: Differential update of a dual XIP MCU. To accomplish this and still obtain good compression, the installed image must be un-relocated, then a diff must be applied, then the resulting image must be relocated, then written to storage. This is even more complicated if the diff is compressed and encrypted. Furthermore, there are some differential algorithms that will need to be able to read the data they have written, which means that the target image must also be possible to read, un-relocate, and feed into the differential unpacking engine. Shared compression table. Several components of an update may be delivered with a single common compression table. If this is the case, then each target image must be decompressed using two inputs: the compressed file and the compression table The result of this is that we concluded that resources and targets cannot considered the same. While they are the same in the “raw binary” case, and they still appear to be the same in linear-processing case (where all processors have only one input and one output), once differential compression, table compression, and relocation are considered, it is clear that, since processors can require multiple inputs, there must be a way to describe each of these inputs. This clarifies that resources are distinct from the final image that is installed to a device. Because of this distinction and in order to describe complex use-cases, we have included a mechanism of describing the resources as input nodes to a graph, the installation targets as output nodes from the graph, and the intermediate states as internal nodes of the graph, where each processor forms an edge on the graph. For the installation of any given target, we expect that this graph could be reduced to a tree with an installation target at the root. In the simple case, a raw binary payload, one resource is required, identifying an output node, and one installation target is required, identifying the same node as an input node. Describing this structure as a graph, rather than a tree for each target is a design tradeoff. We believe that the graph as several advantages. First, it reduces the nesting depth of the CBOR parser. This is an important consideration for how much memory is consumed. Second, it allows a validator to iterate over the graph and identify whether it supports each specified processor without any comprehension of the tree structures or graph connectedness. Third, it eliminates repetitive description of resources and intermediates that are used in multiple trees, which could be used to eliminate download (resource acquisition) and processing overhead. We don’t think that the reduction in manifest size would be significant. As always, your input is most welcome! Thanks, Brendan IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 Rønningstad
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 David Brown
- [Suit] [suit]: draft-moran-suit-manifest-02 Brendan Moran
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 Kvamtrø
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 David Brown
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 David Brown
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 David Brown
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 Kvamtrø
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 David Brown
- Re: [Suit] [suit]: draft-moran-suit-manifest-02 David Brown