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

[Peter Saint-Andre <[e-mail]>]

Ah, that makes sense. Thus you don't need to embed that information in a 
single f-component, which is good.

As far as I'm concerned, this registration can be accepted. Let's see 
what the other members of the review team have to say.

Peter

On 1/4/22 2:43 PM, Patrick Dwyer wrote:
> Hi Peter,
> 
> Excellent consideration. That is possible. Each component has an
> independent "BOM ref". So whether a component is within a bundled
> assembly, or part of a complex dependency graph, it can be directly
> referenced.
> 
> Regards,
> Pat
> 
> On Wed, Jan 5, 2022 at 7:18 AM Peter Saint-Andre <[e-mail]> wrote:
>>
>> 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: [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/urn
>>