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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 05 June 2020 00:32 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 C2DEC3A10CC for <suit@ietfa.amsl.com>; Thu, 4 Jun 2020 17:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 jjdx3ek65F4D for <suit@ietfa.amsl.com>; Thu, 4 Jun 2020 17:32:12 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2BC3A10CB for <suit@ietf.org>; Thu, 4 Jun 2020 17:32:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4628538A18; Thu, 4 Jun 2020 20:29:46 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xLu2tjJC0cEQ; Thu, 4 Jun 2020 20:29:45 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 805C638A10; Thu, 4 Jun 2020 20:29:45 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A01813D2; Thu, 4 Jun 2020 20:32:09 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Dick Brooks <dick@reliableenergyanalytics.com>, "suit\@ietf.org" <suit@ietf.org>, 'Saad EL JAOUHARI' <saadeljaou@gmail.com>, Eliot Lear <lear@cisco.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
In-Reply-To: <AM0PR08MB37166AD36B5AA36EA7D7CA9BFA890@AM0PR08MB3716.eurprd08.prod.outlook.com>
References: <AM0PR08MB371631B7C1E6B50DCA29049AFA880@AM0PR08MB3716.eurprd08.prod.outlook.com> <8b6d01d639d0$62614150$2723c3f0$@reliableenergyanalytics.com> <AM0PR08MB37166AD36B5AA36EA7D7CA9BFA890@AM0PR08MB3716.eurprd08.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 04 Jun 2020 20:32:09 -0400
Message-ID: <20437.1591317129@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/aK-aYvffx1A6FBWghPEntKOiZDs>
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: Fri, 05 Jun 2020 00:32:15 -0000

Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
    > * Finally, there is also a version condition. This allows to express
    > that a manifest is applicable to one or multiple versions of the
    > firmware. As described in the information model draft, this situation
    > occurs when you upload an application that relies on existing software
    > to be present on the device. (Think of it as an API version.)

    > It is important to note that the manifest is not meant to be used to
    > describe the software running on the device. This is the job of other
    > tools, such as COSWID. The manifest instead provides instructions on
    > how to update firmware and to accomplish secure boot.

There are some efforts to include RFC8520 (MUD) definitions into the
Manifest, either by value or reference. (Henk!)

There are other efforts to include CoSWID into RFC8520, I think.
I may be mistaken as to the direction of the arrows here.

    DB> I'm hoping to use the manifest as a virtual SBOM. Will let you know
    DB> if I'm successful in this regard.

The manifest could include a reference to a SBOM, but I don't think it is
reasonable to to include it by value.  I think that the right place to get
the SBOM is via an RFC8520 (MUD) object.

I think that it would help if SUIT considered how some BCPs and/or
Applicability statements that helped to tie some things together.
(Specifically, from the charter:
       This group will not define any new transport or discovery mechanisms,
       but may describe how to use existing mechanisms within the architecture.
)
A lot of Enterprises would like to cache all firmware contents somewhere
locally, avoiding external access for devices.  There is an overlap here
with processes that might report on success updates, caching the new SBOMs
into an audit system, etc.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-