Re: [OPSAWG] 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

Eliot Lear <> Sun, 24 January 2021 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D88873A0D86 for <>; Sun, 24 Jan 2021 07:22:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.973
X-Spam-Status: No, score=-9.973 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vyd1cw9CcnUC for <>; Sun, 24 Jan 2021 07:22:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4B643A0D85 for <>; Sun, 24 Jan 2021 07:22:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5489; q=dns/txt; s=iport; t=1611501766; x=1612711366; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=GD5qL+XKf/F9Jchltem8foPcUi4lk9OcSHnNYrglqdI=; b=CnrmQ7gDE2A5XCbhvJ3+xtBvZzwyIv1faT+WSexvLYAZFEZRCrOUhnOs ZZTwgTuCNrV1oXO7nIl8FFGKQkvzFAMQGAtL7sJgPsawW4QdL/6WC3Dhg F8pYTq0kEG+vbSZWnT0olaW60WfOK4qPAFvJzhph3ZU1CfnLnu+PmzcIV 0=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.79,371,1602547200"; d="asc'?scan'208";a="32898865"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jan 2021 15:22:36 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTPS id 10OFMZcl016118 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 Jan 2021 15:22:35 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_4177674A-092C-4BD0-8570-74BD7150B26D"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Sun, 24 Jan 2021 16:22:34 +0100
In-Reply-To: <>
Cc: Henk Birkholz <>, opsawg <>
To: "Panwei (William)" <>
References: <> <>
X-Mailer: Apple Mail (2.3654.
X-Outbound-SMTP-Client:, []
Archived-At: <>
Subject: Re: [OPSAWG] =?utf-8?q?=F0=9F=94=94_WG_Adoption_Call_on_draft-lear-o?= =?utf-8?q?psawg-sbom-access-00?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Jan 2021 15:22:48 -0000

Hi Wei Pan,

Thanks for this excellent review.  Please see below.

> On 24 Jan 2021, at 15:14, Panwei (William) <> wrote:
> I've read the draft and I support the adoption. In addition, I have the following comments:
> 1)
> 1. Introduction
> An application-layer management system retrieving an SBOM in order
> to evaluate the posture of an application server of some form.
> These application servers may themselves be containers or
> hypervisors. Discovery of the topology of a server is beyond the
> scope of this memo.
> Comment> I know there are application-layer firewalls, but I don't think it's also appropriate to use "application-layer" to describe the management system. The management system manages the application server, but should not be specific to "application-layer".

I think your concern is with the term “application server”.  If so, I agree with you, the intent here is not to address application layer matters, but at the layer below.  Perhaps we could reword this to be a bit more clear.

> Comment> For an application server which doesn't support MUD before, if it wants to advertise its SBOM info, it needs to send a MUD URL and the related MUD file contains a SBOM URL, why doesn't it just send a SBOM URL?

Actually, the intent is to not require certain application servers to send any URL ;-). Rather, to have a well known URI prefix so that the SBOM can be discovered through a query.

> 2)
> 1. Introduction
> A network-layer management system retrieving an SBOM from an IoT
> device as part of its ongoing lifecycle. Such devices may or may
> not have interfaces available to query SBOM information.
> Comment> I also suggest not using "network-layer" to describe the management system, but saying that the management system evaluates the network behavior of the IoT devices.

I am happy to remove the word “network-layer”, but I would rather not get into behavioral evaluation, as these are two different functions.

> Comment> For disambiguation, in the last sentence, it's better to say "to be queried for SBOM information".


> 3)
> 1.3. Discussion points
> Are there other retrieval mechanisms that need to be specified?
> Comment> Can the SBOM info be directly stored/written in the MUD file?

Not in this design.  MUD is intended only for discovery, and is certainly not intended to be the only discovery mechanism.

> 4)
> 3. The mud-sbom augmentation to the MUD YANG model
> In the description of "leaf-list sbom-local", it is said:
> "The choice of sbom-local means that the SBOM resides at
> a location indicated by an indicted scheme for the
> device in question, at well known location
> ’/.well-known/sbom’. For example, if the MUD file
> indicates that coaps is to be used and the host is
> located at address, the SBOM could be retrieved
> at ’coaps://’. N.B., coap and
> http schemes are NOT RECOMMENDED.";
> Comment> The leaf-list "sbom-local" only indicates the transport Protocol, how can the MUD controller know the host address?

This has to be known by the MUD Manager.  I think it’s a good idea to say a bit more about this, though, since that may not be the case for all previous MUD Managers.  Do you agree?

> 5)
> 4. Examples
> The first MUD file demonstrates how to get the SBOM
> without ACLs, and the second has ACLs.
> Comment> Here should be "The first three MUD files demonstrate ..., and the forth has ACLs."

Yes indeed.

> 6)
> 5. Security Considerations
> Another risk is a skew in the SBOM listing and the actual software
> inventory of a device/container. For example, a manufactuer may
> update the SBOM on its server, but an individual device has not be
> upgraded yet. This may result in an incorrect policy being applied
> to a device. A unique mapping of a device’s firmware version and its
> SBOM can minimize this risk.
> Comment> Can we add the firmware version info in the MUD file? So that there will be the mapping of firmware version and SBOM.

Indeed that is available, but a caution: MUD files that are tied to X.509-based MUD-URLs won’t show latest and greatest firmware.  This draft actually could heal that deficiency - to a point.