[OPSAWG] draft-ietf-opsawg-sbom-access

Eliot Lear <lear@lear.ch> Fri, 28 April 2023 10:44 UTC

Return-Path: <lear@lear.ch>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7813CC151539 for <opsawg@ietfa.amsl.com>; Fri, 28 Apr 2023 03:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlKPMRuXhRXF for <opsawg@ietfa.amsl.com>; Fri, 28 Apr 2023 03:44:17 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [IPv6:2a00:bd80:aa::2]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 40A09C1516F2 for <opsawg@ietf.org>; Fri, 28 Apr 2023 03:44:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1682678645; bh=nyy5XSAvi1q4JJNYrSTO3tSEoZoDhvNf0pGiW9EsPp8=; h=Date:To:From:Subject:From; b=DWbs0yjWjhFfnvAFrFicFZO0j4t3tz7ovYC27koWUMltZgGC2kn2EdgZeS95NOkL1 NfDkQYp7Ai53GKPACSs/21zvIFT2NpiJwPrxF+mh91B2r0FU9r0gkc30KcBdT0jM5I nUhNpGQmdzEer79iJeFP2yWOcISOlmABGHnUMRKI=
Received: from [IPV6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 33SAi4ZI336031 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for <opsawg@ietf.org>; Fri, 28 Apr 2023 12:44:05 +0200
Message-ID: <7aa5c179-1fab-77ff-123e-35562d84fa64@lear.ch>
Date: Fri, 28 Apr 2023 12:44:03 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-US
To: "opsawg@ietf.org" <opsawg@ietf.org>
From: Eliot Lear <lear@lear.ch>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/UfUZT-doqgQhbQNM2tacQNSWisw>
Subject: [OPSAWG] draft-ietf-opsawg-sbom-access
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Apr 2023 10:44:21 -0000

During the IESG evaluation, I received a query from the AD about using 
leaf-lists instead of leafs for SBOM and vulnerability data.  Before we 
publish this document, I think it's probably worth reviewing those nodes.

Right now, everything is a leaf.  For SBOMs at least, to me this makes 
sense, since the SBOM should be a description of the system to which the 
schema refers.  Having multiple descriptions introduces the need for 
potential conflict resolution between those descriptions, and 
complicates processing in a way that could cause interoperability problems.

For vulnerability information, I feel differently.  It may be desirable 
to update the description by vulnerability, rather than to have one 
large file of vulnerabilities.  It may also be undesirable, in that it 
means you have to get description updates when vulnerabilities are 
updated, rather than just updating one file.  But I see no harm in 
allowing both methods.

Therefore, my suggestion is that we change vuln-url to be a leaf-list.

Are there any objections?

Eliot