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

[Patrick Dwyer <[e-mail]>]

Thanks for the great feedback Dale.

Revised below:

Namespace Identifier:  Requested of IANA - cdx

Version:  1

Date:  2022-01-01

Registrant:

Patrick Dwyer, on behalf of the OWASP CycloneDX project.
Email: [e-mail]
Address:
The OWASP Foundation Inc.
401 Edgewater Place, Suite 600
Wakefield, MA 01880

Purpose:

CycloneDX is a 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.

URNs in the "cdx" namespace are used as a means of persistently identifying
CycloneDX BOMs.

When creating a BOM, 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. It can also be used when a software supplier does not
have authority to share upstream BOM content directly.

CycloneDX also supports "BOM refs". A BOM ref is a reference to a particular
element within a BOM. A "cdx" URN with an f-component is a BOM ref, with the
fragment identifier specifying the element within the BOM identifier by the URN.

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 "/" bom-version
     bom-serial-number-uuid = UUID
     bom-version            = nonzero-digit *digit ; an integer >= 1
     f-component            = fragment
     nonzero-digit          = %x31-39 ; 1-9

Assignment:

CycloneDX URNs are assigned in a decentralised way, using the bom-serial-number.
A bom-serial-number is a version 4 UUID as defined in [RFC4122]. And is unique
to a specific BOM.

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 beyond [RFC3986] on what
can be included in an f-component. Given that f-components may be published in
CyclineDX URNs, producers of BOMs should avoid using any value on which there
are sharing restrictions. For producers of BOMs who have high confidentiality
requirements, it is recommended to use UUIDs for f-components.

Interoperability:

Although CycloneDX BOMs may use a UUID URN to identify a BOM via its BOM serial
number, the serial number isn’t sufficient when referencing a BOM because a
particular BOM may be revised over time. Even in the case of legacy software
that is not conceptualized as changing, mistakes and omissions can be corrected
over time causing changes in the BOM. This is allowed for by successive "cdx"
URNs in which the BOM serial number is static and the version is incremented.

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


On Thu, Jan 6, 2022 at 9:52 AM Dale R. Worley <[e-mail]> wrote:
>
> I've got a number of editorial nits, and one technical question:  Should
> it revise the syntax of bom-version based on its underlying semantics?
>
> ----------
>
> There are some places where the sentence structure is rough, so you
> probably want someone to copy-edit the text.
>
>     Patrick Dwyer, on behalf of OWASP CycloneDX
>
> You probably want to say "on behalf of OWASP", as CycloneDX isn't an
> organization.  Alternatively, you may want to conceptualize "the
> CycloneDX project" apart from OWASP, in which case you'd say "on
> behalf of the CycloneDX project".
>
>     CycloneDX is an open source software bill of materials OWASP
>     standard.
>
> I'm not sure of the significance of "open source" here.  Is CycloneDX
> only applicable to open-source software?  Or is the standard somehow
> open-source?
>
>     The “cdx” namespace is used ...
>
> Better, 'URNs in the "cdx" namespace are used ...'.
>
>     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.
>
> This text is interesting, but it seems to me that you'd need quite a
> bit more description to enable the reader to understand the import of
> BOM refs.  So I think you should trim it back to provide just enough
> context for why the grammar specifies f-components.  Say:
>
>     CycloneDX also supports “BOM refs”. A BOM ref is a reference to a
>     particular element within a BOM.  A "cdx" URN with an f-component is
>     a BOM ref, with the fragment identifier specifying the element
>     within the BOM identified by the URN.
>
> That makes the purpose clear without even getting into the details of
> what an "element of a BOM" is.
>
>     bom-version            = 1*digit
>
> There are a bunch of interesting questions here!  As written,
> bom-version is a string of digits, and "00", "000", "1", and "0001"
> are all different.  Is bom-version intended to denote an integer?  If
> so, what range does the integer have; specifically, does it include
> zero?  If it is intended to be an integer, you should adjust the
> syntax to permit only the canonical way of writing those integers.
>
>     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].
>
> In the first sentence, it would be preferable to say
> "bom-serial-number-uuid" rather than "BOM serial number", as that is
> what the grammar says -- unless CycloneDX uses the term "BOM serial
> number" a lot, in which case I'd change "bom-serial-number-uuid" to
> "bom-serial-number" in the grammar.
>
> In the second sentence, I'd clarify the correspondence between serial
> numbers and BOMs by making both parts of the sentence singular, "A
> CycloneDX BOM serial number is unique to a specific BOM."
>
> I would clarify the third sentence by saying "A CycloneDX BOM serial
> number is a version 4 UUID as defined in [RFC4122]."  (A BOM serial
> number *itself* isn't a URN, as it is a UUID [RFC4122] and does not
> start with "urn:".)
>
>     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.
>
> I'm not clear what exactly counts as a "BOM ref" -- Is it the
> URN-with-f-component, or is it just the f-component?  Or is it the
> abstract concept and we also use the term vaguely to mean both the
> URN-with-f-component and f-component?  It might be better to limit
> this paragraph to talking about f-components to avoid any
> complications:
>
>     Additionally, there are no specification limitations beyond
>     [RFC3986] on what can be included the f-component.  Given that
>     f-components may be published in CyclineDX URNs, producers of BOMs
>     should avoid using any value on which there are sharing
>     restrictions.  For producers of BOMs who have high confidentiality
>     requirements, it is recommended to use UUIDs for f-components.
>
> --
>
>     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.
>
> I think this can be clarified considerably:
>
>     Although CycloneDX BOMs may use a UUID URN to identify a BOM via
>     its BOM serial number, the serial number isn’t sufficient when
>     referencing a BOM because a particular BOM may be revised over
>     time.  Even in the case of legacy software that is not
>     conceptualized as changing, mistakes and omissions can be
>     corrected over time causing changes in the BOM.  This is allowed
>     for by successive "cdx" URNs in which the BOM serial number
>     remains static and the version is incremented.
>
> Dale