Re: [Suit] Manifest-07 review

Dick Brooks <dick@reliableenergyanalytics.com> Wed, 24 June 2020 13:35 UTC

Return-Path: <dick@reliableenergyanalytics.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 C22C23A0D7B for <suit@ietfa.amsl.com>; Wed, 24 Jun 2020 06:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 zHKg7PmfDOP1 for <suit@ietfa.amsl.com>; Wed, 24 Jun 2020 06:35:50 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2C83A0C69 for <suit@ietf.org>; Wed, 24 Jun 2020 06:35:49 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4E1C65C00B9; Wed, 24 Jun 2020 09:35:49 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 24 Jun 2020 09:35:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=yyJuGEgcSFNTe24tGQIVNpEglusHFE9+xYCvRdUcW gM=; b=GTXW410WBlr4XfZ7+xgQBJSXhhN2vTc31n2TcHzfZi3hW/NerrnxcGkWy j4Fgj+yTKg7RT2kkSsGSz7QgrHUgr2cJzhZhINfwDp7mqlnT3Iab01I4pY+Y5C+G 7NuD7esTfHNUQI+bNDpmd9Pz5ijtwpwt4+bcSC609D2Tl3M9CGvNqNBmSMhOZuET CE8fW8QRhBIA3EgDCaSnc6muyPJz+zcdgLiS6frLIPw9BiZQrs76EzYZUs9hGpr+ rN9WWqF0AUllZedCZC65ubk86loFCvA0Nn0SBMq63x1QDALTS1rdkijV3RKyljUZ a5RjG1r3K9rssdHNrIdA9CTFzVRng==
X-ME-Sender: <xms:tFbzXr2-ahlTgYU-kjUGFN4DtlB5FcmPnqYXu_U_6q6Mm8Qf8czAaw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekjedgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvfhgjufffohfkgggtgffothesthhqredtvddtudenucfhrhhomhepfdff ihgtkhcuuehrohhokhhsfdcuoeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrg hlhihtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepgffhvdeuieehgfdvhfdtheff feffvdejteejffduffegffelvdefiedtueeffedunecuffhomhgrihhnpehrvghlihgrsg hlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhmpdhouhhtlhhoohhkrdgtohhmpdhi vghtfhdrohdpihgvthhfrdhorhhgnecukfhppedvudeirdduleefrddugedvrddvvdenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguihgtkhes rhgvlhhirggslhgvvghnvghrghihrghnrghlhihtihgtshdrtghomh
X-ME-Proxy: <xmx:tFbzXqEgA775CnUXlDJqaHkYoHYA2MxkZ3-Hkk2-ncxYSVNWBCmUJQ> <xmx:tFbzXr7icWCLLrP65-IqX6ShENHzb5uK5vGYb5rMwdhNbKFpvvrO1Q> <xmx:tFbzXg2rP3JgV10UeYjKuGQLIfE_t1HXR_VVDhxhPMgzwXzTmk-rkA> <xmx:tVbzXiRk2xOnqvDJkbYKf8b8mqzXerrXF4C4v3OYxelCWKgQClR5Zg>
Received: from farpoint (unknown [216.193.142.22]) by mail.messagingengine.com (Postfix) with ESMTPA id 65C833280059; Wed, 24 Jun 2020 09:35:48 -0400 (EDT)
From: "Dick Brooks" <dick@reliableenergyanalytics.com>
To: "'Waltermire, David A. \(Fed\)'" <david.waltermire=40nist.gov@dmarc.ietf.org>, =?iso-8859-1?Q?'R=F8nningstad=2C_=D8yvind'?= <Oyvind.Ronningstad@nordicsemi.no>, "'suit'" <suit@ietf.org>
References: <AM0PR05MB4339D51F857444D08ECAC41888950@AM0PR05MB4339.eurprd05.prod.outlook.com> <CH2PR09MB425136BCE8E859DFBED017DCF0950@CH2PR09MB4251.namprd09.prod.outlook.com>
In-Reply-To: <CH2PR09MB425136BCE8E859DFBED017DCF0950@CH2PR09MB4251.namprd09.prod.outlook.com>
Date: Wed, 24 Jun 2020 09:35:44 -0400
Organization: Reliable Energy Analytics
Message-ID: <1cd0f01d64a2c$5e98ffb0$1bcaff10$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKpL0nszvV6zOMibCT1agukCYEJygIeSVKVpzEGnuA=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/pQn6rQDRWtzx24iNTGze7590t5A>
Subject: Re: [Suit] Manifest-07 review
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 24 Jun 2020 13:35:52 -0000

Are there plans for a standard file naming nomenclature to identify software
objects that contain a suit manifest? 

Today, I use the filename extension to drive an introspection procedure to
generate an SBOM and having a defined filename extension to indicate that a
suit manifest is present would help, otherwise I have to parse each file to
determine which SBOM introspection procedure to invoke.

Thanks,

Dick Brooks

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: dick@reliableenergyanalytics.com
Tel: +1 978-696-1788

-----Original Message-----
From: Suit <suit-bounces@ietf.org> On Behalf Of Waltermire, David A. (Fed)
Sent: Wednesday, June 24, 2020 9:30 AM
To: Rønningstad, Øyvind <Oyvind.Ronningstad@nordicsemi.no>no>; suit
<suit@ietf.org>
Subject: Re: [Suit] Manifest-07 review

Øyvind,

Thanks for this review!

Dave

-----Original Message-----
From: Suit <suit-bounces@ietf.org> On Behalf Of Rønningstad, Øyvind
Sent: Wednesday, June 24, 2020 6:03 AM
To: suit <suit@ietf.org>
Subject: [Suit] Manifest-07 review

Hi guys, here is a review of manifest-07. Mostly small stuff.

Questions:
... Section 6.4: What are the guidelines for extracting the vendor-id,
class-id, device-id, or version of a component?
... Suit-condition-component-offset is used in an example, but marked as TBD
in its section. I see that it is described in 6.4 as
"assert(offsetof(component) == arg)". What are the semantics of "offsetof"?
... Can suit-directive-process-dependency be done on a component, or just on
a dependency? Generally, there seems to be some mismatch between the
description in 6.4 (which implies that most directives and conditions only
apply to a component index) and textual descriptions e.g. in 9.8.4.1 and
9.8.4.2 (which imply that directives and conditions apply to whichever is
available of component index and dependency index).
... (It would be very beneficial to make 6.4 "Abstract Machine Description"
more prominent, e.g. by linking from the individual section for commands,
since 6.4 contains very useful info about how the commands work, and it's
hard to discover otherwise.) .. What (if any) are the rules regarding when
to perform dependency-resolution, payload-fetch, and install, and when to
perform only validate, load, and run?
... suit-manifest-sequence-number: "Each Recipient MUST reject any manifest
that has a sequence number lower than its current sequence number." Are
there several "current sequence number"s or just one for each SUIT
processor. Exactly when is the "current sequence number" updated?
... What should the processor do when waiting on a suit-directive-wait? Can
it be interpreted as "try again later", or "busy wait"?
... There are important limitations to what sort of commands can be in
suit-common. Could the limitations be reflected in the CDDL? It seems like a
natural thing to do, to make the limitations more prominent.
... When processing dependencies, how do we know when to a) expect a
signature and b) check the signature on a dependency manifest?
... Did we mean for short payloads to be embeddable in the manifest (I can't
find this)? This would be very useful for setting configuration options via
SUIT manifests. 
... Is the device-identifier unique for each individual device, or for a
collection of devices?	
... Why are suit-directive-set-component-index and
suit-directive-set-dependency-index not implemented through set-parameters?
Are they subject to the same override mechanics? If not, it might be
confusing with suit-parameter-source-component, which seems to be analogous
to set-component-index, but might have subtly different behavior because of
override mechanics.

Nits:
... Suit-directive-fetch: "manifest-index" is not referred to elsewhere in
the document.
... Section 7: Suggested edit in bold: "A digest should always be set using
Override Parameters, since this prevents a less-privileged dependent OR
dependency from replacing the digest."
... suit-condition-update-authorized seems like it could use some metadata
to help determine what is being authorized, e.g. A human readable prompt if
user interaction is required, or an identifier if multiple instances of the
condition are used in a manifest.


Thanks for the good work,

Øyvind

_______________________________________________
Suit mailing list
Suit@ietf.org
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.o
rg%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdavid.waltermire%40nist.go
v%7C909e99a025494e915e6008d81825e30f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%
7C0%7C637285898291416907&amp;sdata=Hww6iMALkbaHZQLb1VeYGCDfb7yrQGbpUbUa%2FD5
u4Fo%3D&amp;reserved=0

_______________________________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit