Re: [Suit] Manifest-07 review

Dick Brooks <dick@reliableenergyanalytics.com> Wed, 24 June 2020 14:23 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 077C13A0E3B for <suit@ietfa.amsl.com>; Wed, 24 Jun 2020 07:23:01 -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 oz9ydgu9oMOQ for <suit@ietfa.amsl.com>; Wed, 24 Jun 2020 07:22:59 -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 19AA53A0E34 for <suit@ietf.org>; Wed, 24 Jun 2020 07:22:59 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 37D6F5C00A5; Wed, 24 Jun 2020 10:22:58 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 24 Jun 2020 10:22:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=EVQJ7z6rDUja3Fa4V8uUcGYx1NEUqkOKf14mH62Vz Zs=; b=cVRbMORCAiv1x1zR8bfWpieSwXpfr118ZUXCYIQhUR3QNsGMpCTD1EQch AarpmoayyjV3QgFGHXQgOcuec21KNYIDNpZ/uwH5Bbb3hvdtXkRSMqpleAPY5ZNa Sk2rP3pBoIPcY6CMjlSdGpa2xRgVzFz0QI6R3XfqzAj4sm1E9EiirGRmxlhJkZ/g oFpYT3A5pO2Ydt1/23JDFqyP8VBKFTRzcuTOpw07/3N2jGChZGfNNWVs3xQztWod ahjexUQPqJyaWSPPa16xfkv4rwL+abAHg+NykXmNKEQD5rAHDjLvsASIkI31aI9O 7swm+VEU4sOQHvLNyiJ31sdCUFk7Q==
X-ME-Sender: <xms:wWHzXpTKrS-VJRp8166oTKGjXu8gS7BtPHMAal0Qc7hARDkH-_omvA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekjedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvfhgjufffohfkgggtgffothesthhqredtvddtjeenucfhrhhomhepfdff ihgtkhcuuehrohhokhhsfdcuoeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrg hlhihtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepjeetffetfeduieelhfelieef vefgfeevgeetledttefhuefggfffhfehveeluefgnecuffhomhgrihhnpehrvghlihgrsg hlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhmnecukfhppedvudeirdduleefrddu gedvrddvvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrghlhihtihgtshdrtghomh
X-ME-Proxy: <xmx:wWHzXixVZtG1PTxxMttKhDrpSr8vzrIwZVp3oqP4py932zUc6dxMgA> <xmx:wWHzXu0jCL13zw9CfZh5qVid_zF3_UQxcVXs4DeaFm2dQncICueQ5g> <xmx:wWHzXhCmHbZWJCf0MJq8IrNAE15QedLO4E_TY94kpAnkLHnZYwISBw> <xmx:wmHzXttz7dX7NZWe8rTedn2S3zHvJqDMktV2MNRh8Oi2cVwA5fWt0A>
Received: from farpoint (unknown [216.193.142.22]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D5E43280066; Wed, 24 Jun 2020 10:22:57 -0400 (EDT)
From: "Dick Brooks" <dick@reliableenergyanalytics.com>
To: "'Russ Housley'" <housley@vigilsec.com>, "'Brendan Moran'" <Brendan.Moran@arm.com>
Cc: "'suit'" <suit@ietf.org>
References: <AM0PR05MB4339D51F857444D08ECAC41888950@AM0PR05MB4339.eurprd05.prod.outlook.com> <CH2PR09MB425136BCE8E859DFBED017DCF0950@CH2PR09MB4251.namprd09.prod.outlook.com> <1cd0f01d64a2c$5e98ffb0$1bcaff10$@reliableenergyanalytics.com> <54E7F290-B43D-4D72-9E8C-DE1B7E74F03E@arm.com> <dc6daca5-50b3-2bee-5180-3af97030f877@sit.fraunhofer.de> <74DED04B-800F-405A-B0F6-CD0AD125B04A@vigilsec.com>
In-Reply-To: <74DED04B-800F-405A-B0F6-CD0AD125B04A@vigilsec.com>
Date: Wed, 24 Jun 2020 10:22:53 -0400
Organization: Reliable Energy Analytics
Message-ID: <1d06d01d64a32$f4b6f6e0$de24e4a0$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKpL0nszvV6zOMibCT1agukCYEJygIeSVKVAmLOQoQBg0fzvgH/P7tTAUui7qmm94z8wA==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/tFdrHmePOOp2HyMbeKAwjBX3Hw0>
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 14:23:01 -0000

+1 +1 +1

That would be greatly appreciated - Thanks Russ. 

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 Russ Housley
Sent: Wednesday, June 24, 2020 10:02 AM
To: Brendan Moran <Brendan.Moran@arm.com>
Cc: suit <suit@ietf.org>
Subject: Re: [Suit] Manifest-07 review

I think .suit is a very reasonable choice.  We may also want to add a section that registers a media type for the manifest files, which helps with fetching these by HTTP and HTTPS.

Russ


> On Jun 24, 2020, at 9:48 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
> 
> Are we talking about every "software object" that starts with a CBOR tag as defined in this document?
> 
> I assume that a manifest in the form of a file can be wrapped or not be wrapped in a SUIT envelope. Would that result in the same file extension ".suit"?
> 
> Viele Grüße,
> 
> Henk
> 
> On 24.06.20 15:42, Brendan Moran wrote:
>> The intent is to register a CBOR tag that identifies the manifest envelope. This allows detection of manifests by signature in the first 2-3 bytes. A typical filename extension would be fine. I think the most suitable suggestion would be “.suit” if that suits the working group. We’re past the days of 3 letter extensions now, right?
>> Best Regards,
>> Brendan
>>> On 24 Jun 2020, at 14:35, Dick Brooks <dick@reliableenergyanalytics.com> wrote:
>>> 
>>> 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! T 
>>> 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%2Fww
>>> w.ietf.o 
>>> rg%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdavid.waltermire%4
>>> 0nist..go 
>>> v%7C909e99a025494e915e6008d81825e30f%7C2ab5d82fd8fa4797a93e054655c61
>>> dec%7C1%
>>> 7C0%7C637285898291416907&amp;sdata=Hww6iMALkbaHZQLb1VeYGCDfb7yrQGbpU
>>> bUa%2FD5
>>> u4Fo%3D&amp;reserved=0
>>> 
>>> _______________________________________________
>>> Suit mailing list
>>> Suit@ietf.org
>>> https://www.ietf.org/mailman/listinfo/suit
>>> 
>>> _______________________________________________
>>> Suit mailing list
>>> Suit@ietf.org
>>> https://www.ietf.org/mailman/listinfo/suit
>> 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.
>> _______________________________________________
>> Suit mailing list
>> Suit@ietf.org
>> https://www.ietf.org/mailman/listinfo/suit
> 
> _______________________________________________
> Suit mailing list
> Suit@ietf.org
> https://www.ietf.org/mailman/listinfo/suit

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