Re: [urn] Namespace Identifier: Requested of IANA - cdx

Peter Saint-Andre <stpeter@stpeter.im> Tue, 04 January 2022 21:18 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CB63A0ABB for <urn@ietfa.amsl.com>; Tue, 4 Jan 2022 13:18:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.812
X-Spam-Level:
X-Spam-Status: No, score=-2.812 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, NICE_REPLY_A=-0.714, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=stpeter.im header.b=rPGJkkmw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Hi9MSty7
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 V-_Tx7SP1Q-U for <urn@ietfa.amsl.com>; Tue, 4 Jan 2022 13:18:10 -0800 (PST)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D873A0AB5 for <urn@ietf.org>; Tue, 4 Jan 2022 13:18:10 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7CD253201D90; Tue, 4 Jan 2022 16:18:09 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 04 Jan 2022 16:18:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:to:references:from:subject :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=y dPHYSKyFQiIvIY6ZltgChOP8iFVz/s8Xi6gbzdUx/E=; b=rPGJkkmwdaakE/F48 lwhZ6Epn0eri7zU9hu8qQa0jsi1ZxgMTnZRjCvRkRRJmgLCQhMGPHFBJrhyr7wvF mkGenXIhPUNXbLnKb8utVHZIPRJYqJ8cPMWkF8InTpKM4tHF2bxrWmiNaleXXQq+ rg6FEs8CniJkwAQn1KFziZ3zTktkfVlEr/PcKWSdBWqe7kZkqhZYAtfQRQ5qlQDp 5O6+vfDxUbSiRBuR4nrLRbDMThJeuR632tJpqdJ+3btAOjhKX9Wpcbc4AjxyXlM4 EjDc4BD6BKX/gyG3N3DVX7OxidJk9xl9D4OmveFdY9KjVnfgzw0SK4pFBAs0S6p/ YEikw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=fm1; bh=ydPHYSKyFQiIvIY6ZltgChOP8iFVz/s8Xi6gbzdUx /E=; b=Hi9MSty7wQL7bDJ0VKDE9a8UG3zLnkPdEPYQ3w5ySnz3qf9MagK89R/m1 1W1mw7RsBLYAqIS1nXwwNBFoxK9AV7B98Y6yAeSvH2f3ULTDs/YZHR8LsltPoowK NzPv9FrGtCoghGo6gTkvDx/mPdmKKJw8YezHL0QU2ZowAdXJBYLhDU9Q20qmWHPg tgMNp8CBF/tLdNMj8D/yEJGg6p6+wIWA8fKGiOvp6TjXu3wKhgYGsYsRqIgj2LPK AOdNq/pVs/rUldofnVjEt9BefSus1TgjnUMw8BqymtLuW0WG9QREVqkcPhwQ369O i2ypuMsyQlR9MI0DhyL9MJ4YOpD0w==
X-ME-Sender: <xms:kLnUYfykhSehYYN1DMVC7JeC7-HbMAQ28x9RrsQsEmnvRRmcTCLdlA> <xme:kLnUYXTDZ84bFCj_-58YscM1v4vXLIeDbj8ZR45uRJPRo6ordIo3D3aUiZqklzQKI TntJw_YAxebVysdXw>
X-ME-Received: <xmr:kLnUYZXIGNonvPDBKQKXnyVb40fQOceuvZCuVPGqgXp6eq58ZN-bpmTmRwtfHc2KW8s3Wz8-RPIUpo9UllHGa-WP3hU11V-NM6JGJwk>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudeffedgudegjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enfghrlhcuvffnffculddqiedmnecujfgurhepkfffgggfvfhfhffujggtgfesthekredt tdefjeenucfhrhhomheprfgvthgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvghtvg hrsehsthhpvghtvghrrdhimheqnecuggftrfgrthhtvghrnhepleehueekgeeiieettdei vdduudeifeegtefghfdtffejheeftdffvdetheetfedunecuffhomhgrihhnpegthigtlh honhgvugigrdhorhhgpdhnthhirgdrghhovhdpihgvthhfrdhorhhgnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtphgvthgvrhesshhtph gvthgvrhdrihhm
X-ME-Proxy: <xmx:kLnUYZixAoUoxuG2fsl7Jw8IBGO0gx3zCnmkyjMXigy88f-YUjCHGQ> <xmx:kLnUYRDyF9JV12a1zOSo_jkjRQvARunzv2M14PfP_ElVSloe_l2s5w> <xmx:kLnUYSINU3_ukGicVkbumMlZJi1OSDBHqcwswUY46ex_ySwl81DXhQ> <xmx:kLnUYe5X9f_6dURNX0GInsU-A-JSmuA8XD7OD7wQCGbeJ72jjI4daw>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 4 Jan 2022 16:18:08 -0500 (EST)
Message-ID: <30b772a4-e339-613d-7cc3-fba9e6995f1b@stpeter.im>
Date: Tue, 04 Jan 2022 14:18:02 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
Content-Language: en-US
To: Patrick Dwyer <patrick.dwyer@owasp.org>, urn@ietf.org
References: <d3762641-86d3-8ac0-587d-8fb0c702c26e@owasp.org>
From: Peter Saint-Andre <stpeter@stpeter.im>
In-Reply-To: <d3762641-86d3-8ac0-587d-8fb0c702c26e@owasp.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/e7kV4Am_ZLGDBZKXB3kkdP2OuUA>
Subject: Re: [urn] Namespace Identifier: Requested of IANA - cdx
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jan 2022 21:18:15 -0000

Hi Patrick,

Thanks for posting this. In general it looks good to me.

Out of curiosity, I have one question: do you have or need a way to 
identify components of components? Would the f-component syntax limit 
this ability?

Peter

On 12/31/21 11:39 PM, Patrick Dwyer wrote:
> Hi folks,
> 
> Seeking your review on this URN namespace registration.
> 
> Regards,
> Pat
> 
> Namespace Identifier:  Requested of IANA - cdx
> 
> Version:  1
> 
> Date:  2022-01-01
> 
> Registrant:
> 
> Patrick Dwyer, on behalf of OWASP CycloneDX
> Email: patrick.dwyer@owasp.org
> Address:
> The OWASP Foundation Inc.
> 401 Edgewater Place, Suite 600
> Wakefield, MA 01880
> 
> Purpose:
> 
> CycloneDX is an open source software bill of materials OWASP standard. 
> CycloneDX bill of materials documents (BOMs) are intended to be 
> exchanged between different parties of the software supply chain.
> 
> The “cdx” namespace is to be used as a means of persistently identifying 
> CycloneDX BOMs.
> 
> When creating a BOM that describes multiple components, a CycloneDX URN 
> can be used to reference an upstream BOM for a component rather than 
> embedding it inline. This may be a consideration for performance 
> reasons. Especially in resource constrained environments such as 
> embedded devices. But can also be used when a software supplier does not 
> have authority to share upstream BOM content directly.
> 
> CycloneDX also supports “BOM refs”. BOM refs are unique BOM scoped 
> references to a particular element. A URN with an optional BOM ref 
> f-component can be used to reference an element within another BOM.
> 
> Referencing a specific element in a BOM is particularly relevant for use 
> cases like describing known vulnerabilities in a component in the 
> context of a particular assembled piece of software or embedded device.
> 
> Syntax:
> 
> The syntax for a CycloneDX URN namestring is defined using the Augmented 
> Backus-Naur Form (ABNF) below. And uses “UUID” as defined in [RFC4122] 
> and “fragment” as defined in [RFC3986].
> 
>      namestring             = assigned-name [ "#" f-component ]
>      assigned-name          = "urn:cdx:" NSS
>      NSS                    = bom-serial-number-uuid "/" bom-version
>      bom-serial-number-uuid = UUID
>      bom-version            = 1*digit
>      f-component            = fragment
> 
> Assignment:
> 
> CycloneDX URNs are assigned in a decentralised way, using the BOM serial 
> number. CycloneDX BOM serial numbers are unique to a specific BOM. And 
> are version 4 UUID URNs as defined in [RFC4122].
> 
> Security and Privacy:
> 
> As CycloneDX URNs are based on UUIDs they have the same security 
> considerations as UUID URNs as per [RFC4122].
> 
> Additionally, there are no specification limitations on what information 
> can be included in a “BOM ref”. When using BOM refs for f-components, 
> consideration must be given to any restrictions imposed on sharing of 
> information within a BOM. And what information may “leak” by including a 
> BOM ref as an f-component in a CycloneDX URN.
> 
> For producers of BOMs who have high confidentiality requirements it is 
> recommended to use UUIDs for BOM refs.
> 
> Interoperability:
> 
> Although CycloneDX BOMs already use a UUID URN to identify a BOM this 
> information isn’t sufficient when referencing a BOM.
> 
> A particular BOM may be revised over time. Especially in the case of 
> legacy software as mistakes and omissions are corrected. In this 
> scenario the BOM serial number remains static and the version is 
> incremented.
> 
> It also isn’t sufficient for use cases that require referencing a 
> specific component within a BOM.
> 
> Resolution:
> 
> No prescriptive resolution mechanisms are envisioned.
> 
> Resolution mechanisms will be determined between parties in the software 
> supply chain, or by organizations using CycloneDX BOMs internally.
> 
> Documentation:
> 
> Please note, this URL will be updated to reference the URN registration.
> 
> https://cyclonedx.org/capabilities/rfc-tbd/
> 
> Additional Information:
> 
> More information about CycloneDX can be found on the project homepage at 
> https://cyclonedx.org
> 
> More general information about software bill of materials can be found 
> at https://www.ntia.gov/sbom
> 
> 
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn