Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-10.txt

Dick Brooks <> Wed, 28 September 2022 13:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59AFDC15E41E for <>; Wed, 28 Sep 2022 06:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 903C8yJRgvKZ for <>; Wed, 28 Sep 2022 06:04:32 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id CB693C15E3F6 for <>; Wed, 28 Sep 2022 06:04:31 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailforward.nyi.internal (Postfix) with ESMTP id 62BB319413B0; Wed, 28 Sep 2022 09:04:30 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute2.internal (MEProxy); Wed, 28 Sep 2022 09:04:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1664370270; x=1664456670; bh=ME9liqcUH4Mfe c/pIggb4VMkpHs7yRzyItCuEHbXgG0=; b=V+Hc+bN/2IR8pirEeT3vDktqNAZpc THSFY9ixml8/Mr1fCcAQ+si1HqRn6URn1yDodQ44bxfu74xUKADg+V+pDGdLNsQc RWx217ZvIgJbta/qWfy8gFcU7DAaHXWmp91iBkS9mxqvFxwUp3aNRxA3T20Q9tmV k8Bn1OD1OhQ/BDyAPL1K2Yf4WZOFhIu/v7YYwn5ogtND6WDp7n7zqcgVw5vBEk1w 3t31mRCqClZ3wr2UNcimvhzkBFnhgSvFOtNA5NqNhpPENO/NQKxLi8GatbO6tu7t jUdo4l/dh9xji2Ksv41Jp7R8c/5sBWXaaNbc2h6OTQ/FbetxgF9yON2hg==
X-ME-Sender: <xms:XkY0Y9nKvDjOSqIUHDJM9w30PKQSDQxXpgxhng27o_gm0qvf5BlW8w> <xme:XkY0Y41wozzbRSK0v7vftGI3No72pfL59ND6iauatbl-oSSzExPAYwFyI93DTnBhx 9NJNCTQLX6kUZ-tpQ>
X-ME-Received: <xmr:XkY0YzryEaiQA6r-SdN1LnF8IKrLSfbcGwH46_ityNJ0NKp6lutUFMw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeegkedgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurheprhfhvfhfjgfuffhokfgg tgfothesrhdtghepvddtjeenucfhrhhomhepfdffihgtkhcuuehrohhokhhsfdcuoeguih gtkhesrhgvlhhirggslhgvvghnvghrghihrghnrghlhihtihgtshdrtghomheqnecuggft rfgrthhtvghrnhepvdetuddvgeeuieefgfehleekueduheefkeeuueeiudduueeltdelvd efvdduvddvnecuffhomhgrihhnpehgihhthhhusgdrihhopdhrvghlihgrsghlvggvnhgv rhhghigrnhgrlhihthhitghsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepughitghksehrvghlihgrsghlvggvnhgvrhhghigrnhgr lhihthhitghsrdgtohhm
X-ME-Proxy: <xmx:XkY0Y9mqn404YvpZ56Gsby4vahzTGPq4ccy6HGVxVv-LP5YOnYSbpQ> <xmx:XkY0Y714yqo1TehOAqkBNDnNiifwe19MMvhzxloXSpSZyHZi1Gmt6A> <xmx:XkY0Y8vS0VX1hypeQx4SnffJ_dYAIJsQY3vX1GJIFQP6EBIXebmelA> <xmx:XkY0YwhIHps0oNxYDr978ysga43_4O8S5EDb73ZVxkLPnJtKkjyUgw>
Feedback-ID: i57d944d0:Fastmail
Received: by (Postfix) with ESMTPA; Wed, 28 Sep 2022 09:04:29 -0400 (EDT)
Reply-To: <>
From: "Dick Brooks" <>
To: "'Eliot Lear'" <>, <>
References: <> <458e01d8d330$6a04cca0$3e0e65e0$> <> <464501d8d333$d184be00$748e3a00$> <>
In-Reply-To: <>
Date: Wed, 28 Sep 2022 09:04:26 -0400
Organization: Reliable Energy Analytics LLC
Message-ID: <473101d8d33a$d8a53820$89efa860$>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_4732_01D8D319.51960920"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQICLAMrAIoWuDeNuawABUXC5q+whQCzsakSAhDIsIkCClCUSQIc5toBrWq+5dA=
Content-Language: en-us
Archived-At: <>
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-10.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Sep 2022 13:04:36 -0000



I’ve made my points, will leave it up to those with authority to decide where this goes. 


FYI: SPDX V 2.3 is out and it supports linking to NIST VDR info; I’m sure Jeff can tell you all about how difficult it was to get this work completed in SPDX V 2.3: 


I was surprised by Cisco’s objections to including the NIST VDR reference in SPDX V 2.3 and that same bias is on display in this draft document. 




Dick Brooks


Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership


 <> Never trust software, always verify and report! ™


Email:  <>

Tel: +1 978-696-1788


From: Eliot Lear <> 
Sent: Wednesday, September 28, 2022 8:58 AM
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-10.txt



On 28.09.22 14:14, Dick Brooks wrote:

See response inline DB>
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, 
Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™
Email: <> 
Tel: +1 978-696-1788
-----Original Message-----
From: Eliot Lear  <> <> 
Sent: Wednesday, September 28, 2022 8:03 AM
To: <> ; <> ; <> 
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-10.txt
Hi Dick,
On 28.09.22 13:49, Dick Brooks wrote:

I find this material misleading and incomplete.
The title infers the ability to discover and retrieve vulnerability 
information. However the text of this draft makes clear that retrieval 
is not supported, ref Page 2:
   "This memo does not specify how vulnerability information may be
    retrieved directly from the endpoint.  That's because vulnerability
    information changes occur at different rates to software updates.
    However, some SBOM formats may also contain vulnerability

The information can be retrieved, but not from the endpoint. That's not misleading.
DB> I agree vulnerability information can be retrieved and some SBOM formats, i.e. SPDX Version 2.3 provide retrieval information for vulnerabilities associated with SBOM's: 
The draft could be more accurate and complete by indicating that access to vulnerability information at the SBOM component level may be indicated in an SBOM.

It says precisely that:

   System vulnerabilities may similarly be described using several data
   formats, including the aforementioned CycloneDX, Common Vulnerability
   Reporting Framework [CVRF], the Common Security Advisory Format
   [CSAF].  This information is typically used to report to
   administrators the state of a system.

If SPDX 3.0 were out, I'd add that too.



The draft makes no mention of the NIST Vulnerability Disclosure Report (VDR)
that is used to inform consumers of the vulnerability status of a software
product at the SBOM component level, ref: NIST SP 800-161 RA-5.

A specification would be incomplete if the reference is necessary for 
implementation.  How is this reference necessary for implementation?
DB> The NIST VDR is no different from other items you reference i.e. CDX VEX and CSAF. Also, parties in the US subject to Executive Order 14028 and OMB memo M 22-18 may need to implement NIST recommendations for SBOM and vulnerability reporting. If this draft guidance is not intended for use by the US Government with regard to these mandates, then you may have a point. 

Those formats are mentioned because they are directly relevant to implementation.