Re: [Suit] How are firmware and firmware versions expressed in manifest?

Dick Brooks <dick@reliableenergyanalytics.com> Sat, 06 June 2020 13:52 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 D6A043A08AD for <suit@ietfa.amsl.com>; Sat, 6 Jun 2020 06:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 kx80Q7baVvt4 for <suit@ietfa.amsl.com>; Sat, 6 Jun 2020 06:52:53 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F86F3A08A2 for <suit@ietf.org>; Sat, 6 Jun 2020 06:52:53 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6E9D25C007F; Sat, 6 Jun 2020 09:52:52 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 06 Jun 2020 09:52:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=Ywm7L9 Zo3FAE3FrcinmXqzDfIEQE9L9Zl+lyEiffP58=; b=umYVncYdrgSuF7Sg6nSdKP DAcqXuqJmLi9hIlJYPN/4J4qFxj/CKCHKm/w52XTGkcJf0/iTZfZpU/p0y8DSX8g dUMo/zEgIVaLx0Ijo8ahWp1x6OhIsVYuA+bZafb/ru8kPZHG3c0GjtPahIxK7osP 5BSLjQQdYw8Y3R9indCHMOv14I7wQif/y60U7MmHevOv3KOzM3nh87r5iSsDhZvf C0covBtz5YnIa9Yw+n9clzrcl/pwvTmZumj/Myy6KHJtM5qEMA28MBjvdRl8W3wA BC2+rjcwrVo2TIVoUMbA8Z7D2+rnVIFQA3H+CzshOk4JfiRlBj3QJsXQvaiP31Tg ==
X-ME-Sender: <xms:s5_bXisXxkAtVu8AjZwMvGHJYE8vDaOHdijvVU5qvV_VdapW83QVNQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeghedgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdlqdegmdenucfjughrpefhvfhfjgfuffhokfggtgfothesrhdtreep vddtjeenucfhrhhomhepfdffihgtkhcuuehrohhokhhsfdcuoeguihgtkhesrhgvlhhirg gslhgvvghnvghrghihrghnrghlhihtihgtshdrtghomheqnecuggftrfgrthhtvghrnhep feehheejjeelkefgheeihfelueejjeelteetkedttdeiteevfeevgfffieffiedunecuff homhgrihhnpehrvghlihgrsghlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhmpdhs uhhnrdhjrghvrgdpughotgdrghhovhenucfkphepvdduiedrudelfedrudegvddrvddvne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughitghk sehrvghlihgrsghlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhm
X-ME-Proxy: <xmx:s5_bXnebwnrwdbXrpTV-0I2bpkTfra9igikSD5qIbnw5qob38J9x5A> <xmx:s5_bXtxznZfjbJnaDdUJ_r5wP8tNPkXv06P-y5AP_uCZUzrNRz83-w> <xmx:s5_bXtNo1d8F_gS66zvfYwmdqK5YFAT0veQI7eamDDXiqBun_cOPmg> <xmx:tJ_bXnGwWuFua6khUWvKtVwKfCFGs9u8vfrZ8M9NhJr1bMo1iFC9wQ>
Received: from farpoint (unknown [216.193.142.22]) by mail.messagingengine.com (Postfix) with ESMTPA id 59D833280065; Sat, 6 Jun 2020 09:52:51 -0400 (EDT)
From: "Dick Brooks" <dick@reliableenergyanalytics.com>
To: "'Eliot Lear'" <lear@cisco.com>, "'Hannes Tschofenig'" <Hannes.Tschofenig@arm.com>
Cc: "'Michael Richardson'" <mcr@sandelman.ca>, <suit@ietf.org>, "'Henk Birkholz'" <henk.birkholz@sit.fraunhofer.de>
References: <AM0PR08MB371631B7C1E6B50DCA29049AFA880@AM0PR08MB3716.eurprd08.prod.outlook.com> <8b6d01d639d0$62614150$2723c3f0$@reliableenergyanalytics.com> <AM0PR08MB37166AD36B5AA36EA7D7CA9BFA890@AM0PR08MB3716.eurprd08.prod.outlook.com> <20437.1591317129@localhost> <1076601d63b3a$d53f5d90$7fbe18b0$@reliableenergyanalytics.com> <BF5D5E46-4A7C-44A7-8554-5DE1E03A3F21@cisco.com> <AM0PR08MB3716C555048993639B14D76FFA860@AM0PR08MB3716.eurprd08.prod.outlook.com> <5820.1591393073@localhost> <AM0PR08MB3716939E832E5483CB8575EBFA870@AM0PR08MB3716.eurprd08.prod.outlook.com> <04B8CB97-9BB2-49CC-A3EB-875596C1B134@cisco.com>
In-Reply-To: <04B8CB97-9BB2-49CC-A3EB-875596C1B134@cisco.com>
Date: Sat, 6 Jun 2020 09:52:47 -0400
Organization: Reliable Energy Analytics
Message-ID: <157a601d63c09$c4dd2d90$4e9788b0$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_157A7_01D63BE8.3DCE9AD0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEpJGg3Q76y3b59AZfDOO6eGr7fRAJUo0s2Am+d4lkB06Pk1ADWaYOUAhdO83ACM65vWAF5pebOAo/piAQB3DbXe6mY0a7g
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/Zt_BbQT6x68QJ_GHox5ps_9yEYE>
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?
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: Sat, 06 Jun 2020 13:52:56 -0000

Thank you, Eliot. That was very insightful and useful. I’ll check out the ntia work – looks promising.

 

Thanks,

 

Dick Brooks



 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com

Email:  <mailto:dick@reliableenergyanalytics.com> dick@reliableenergyanalytics.com

Tel: +1 978-696-1788

 

From: Eliot Lear <lear@cisco.com> 
Sent: Saturday, June 06, 2020 5:04 AM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Michael Richardson <mcr@sandelman.ca>ca>; Dick Brooks <dick@reliableenergyanalytics.com>om>; suit@ietf.org; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?

 

The NTIA is conducting an effort relatied to this known as SBOM (Software Bill of Materials).  They are in trials with healthcare delivery organizations (HDOs) medical device manufacturers (MDMs) and software providers, including people from the Linux Foundation.  There are several different formats discussed, including Software ID Tags (SWID) (ISO-19770) and Software Package Data Exchange (SPDX) which looks very much like what you showed, Dick.  NTIA takes no position on what formats are used.  NIST is planning to move toward SWID as they transition away from the structure used in the National Vulnerability Database (NVD).  I take no position on which of these formats is better, so long as a downstream consumer can easily determine which format is being presented ;-)

 

The goal of SBOM is to provide transparency throughout the supply chain as to what is running on an IoT device.  SBOMs at a minimum are intended to provide a manifest, and then optionally some additional stuff like a dependency graph, licensing information, and maybe some additional security attributes such as access requirements, and links assertions about whether a particular component has a vulnerability or has been patched.

 

The US FDA is planning to require SBOMs as a part of pre-sales qualification.

 

There are great many open issues with regard to SBOMs, some of which this group and the TEEP folk may wish to pursue.  The biggest issue is around naming.  When referring to Java, is that com.sun.java or com.oracle.java or does it matter?  When referring to a supplier, is that IBM or Red Hat (or if it’s REALLY old software, Cygnus)?

 

A similar issue arises with versioning.  Is that openssl 1.0.1 version patched or unpatched and how does one know?

 

Another issue is how an SBOM is retrieved.  What is its well known location?  Does the BOM reside on the device, and is there an interface to retrieve it?  If not, where else is it?  Is it even retrievable?  Does it require permissions to do so if it resides at a vendor locale, and if so, how is versioning managed?

 

This is the basis for draft-lear-opsawg-mud-sbom-00.txt that Scott Rose from NIST and I put together, and would like to present at opsawg.  The goal of that draft is simply a means o discovery to determine how to retrieve an SBOM.  An example of how one would use this extension for an on-the-box approach in its simplest form would be that the manufacturer advertises a RESTful interface at /.well-known/sbom and returns its favorite format (let’s say SPDX).  The back end interface could be as simple as ‘cat /var/lib/dkpg/installed’ or perhaps a bit more complex using a more secure interface to retrieve a signed manifest.

 

Anyway, I provide this information mostly without fully understanding the context here, but it seems relevant, given the line of discussion.  NTIA project information can be found at https://www.ntia.doc.gov/SoftwareTransparency.

 

Eliot

 





On 6 Jun 2020, at 10:19, Hannes Tschofenig <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com> > wrote:

 

I think the BOM terminology is misleading because hardware is not software. The bill of material to produce an IoT product typically does not change (unless you desolder parts) while the software and configuration will regularly change.

Leaving that aside, I believe someone active in COSWID needs to clarify what COSWID does. My understanding was that it documents the software libraries on devices. Whether it would be " libcurl 1.0.2" alone or all the libraries that are used to build "libcurl 1.0.2" is a granularity question that the COSWID specs should / could also answer. That's why I thought it would be useful to have it included in the manifest (as supplementary information; as a severable field).

If COSWID does not do this then someone needs to explain to me what purpose it serves.

Ciao
Hannes

-----Original Message-----
From: Michael Richardson < <mailto:mcr@sandelman.ca> mcr@sandelman.ca>
Sent: Friday, June 5, 2020 11:38 PM
To: Hannes Tschofenig < <mailto:Hannes.Tschofenig@arm.com> Hannes.Tschofenig@arm.com>
Cc: Eliot Lear < <mailto:lear@cisco.com> lear@cisco.com>gt;; Dick Brooks < <mailto:dick@reliableenergyanalytics.com> dick@reliableenergyanalytics.com>gt;;  <mailto:suit@ietf.org> suit@ietf.org; Saad EL JAOUHARI < <mailto:saadeljaou@gmail.com> saadeljaou@gmail.com>gt;; Henk Birkholz < <mailto:henk.birkholz@sit.fraunhofer.de> henk.birkholz@sit.fraunhofer.de>
Subject: Re: [Suit] How are firmware and firmware versions expressed in manifest?


Hannes Tschofenig <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com> > wrote:



FWIW I thought that COSWID would provide information about the software
libraries on a device.


No, AFAIK, it just identifies the materials. (i.e. "libcurl 1.0.2")

Assembling them into a BOM requires another process:
 "curl 1.0.2" contains "libcurl 1.0.2", "curl-main",
                       "libssl 1.1.1f", "glibc 2.19", "pcre 1.0.2"

I could mis-understand though.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca <mailto:mcr@sandelman.ca>   http://www.sandelman.ca/        |   ruby on rails    [

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.