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

["Hakala, Juha E" <[e-mail]>]

Hello Patrick, 

Dale and Peter did not leave much for me to say :-). In its revised form the text is almost fine; I found just some issues and minor typos.

You (or Dale, in fact) 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 identifier by the URN.

This combines URN syntax (URN f-component) and URI syntax (URI fragment identifier) when talking about the same thing. I found this confusing, since URI fragments have a role in identification, whereas f-components don't. It might be better to write the entire sentence from the URN syntax point of view. Also there seems to be a typo in "BOM identifier".  Suggested new text:

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 f-component specifying the location of the element within the BOM identified by the URN. 

 Word "and" seems to be misplaced here: 

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]

It is better to say: 

The syntax for a CycloneDX URN namestring is defined using the Augmented Backus-Naur Form (ABNF) below. It uses "UUID" as defined in [RFC4122] and "f-component" as defined in [RFC8141]

since, as I have said above, in the URN context URI fragments are called f-components in order to make clear that they do not identify anything; they just indicate the location of something within the identified resource. From BOM reference point of view URN approach is IMO sufficient. Elements within BOM do not require URNs of their own; it is enough to locate them. 

In this paragraph: 

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.

there is another misplaced "and".  It might be a good idea to say that bom-serial-numbers are not only unique but also persistent: 

CycloneDX URNs are assigned in a decentralised way, using the bom-serial-number.
bom-serial-numbers are version 4 UUIDs as defined in [RFC4122]. Once assigned, bom-serial-numbers are unique and persistent.

In the Interoperability clause, bom-serial-number is written as BOM serial number. I prefer this format, but you should decide which one to use throughout the document.

This is an interesting and relevant usage of URNs.  

All the best, 

Juha

-----Alkuperäinen viesti-----
Lähettäjä: urn <[e-mail]> Puolesta Patrick Dwyer
Lähetetty: maanantai 10. tammikuuta 2022 2.31
Vastaanottaja: Dale R. Worley <[e-mail]>
Kopio: [e-mail]
Aihe: Re: [urn] Namespace Identifier: Requested of IANA - cdx

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

_______________________________________________
urn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/urn