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

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 4 Jan 2022 14:18:02 -0700

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: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Patrick Dwyer <[email-masked]>
Date: Wed, 5 Jan 2022 07:43:43 +1000

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 4 Jan 2022 14:52:48 -0700

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

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 05 Jan 2022 18:52:45 -0500

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.

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 ...'.

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.

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:".)

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.

--

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

---

From: Patrick Dwyer <[email-masked]>
Date: Mon, 10 Jan 2022 10:31:27 +1000

Thanks for the great feedback Dale.

Revised below:

Version:  1

Date:  2022-01-01

Registrant:

Patrick Dwyer, on behalf of the OWASP CycloneDX project.
Email: [email-masked]
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:

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:

Documentation:

Additional Information:

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 14 Jan 2022 06:24:00 +0000

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 <[email-masked]> Puolesta Patrick Dwyer
Lähetetty: maanantai 10. tammikuuta 2022 2.31
Vastaanottaja: Dale R. Worley <[email-masked]>
Kopio: [email-masked]
Aihe: Re: [urn] Namespace Identifier: Requested of IANA - cdx

Revised below:

Version:  1

Date:  2022-01-01

Registrant:

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].

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:

Resolution mechanisms will be determined between parties in the software supply chain, or by organizations using CycloneDX BOMs internally.

Documentation:

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 <[email-masked]> 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?
>
> ----------
>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 20 Jan 2022 21:35:01 -0500

> Namespace Identifier:  Requested of IANA - cdx
[...]

That covers everything I thought was an issue.  It looks good to me.

Dale

---

From: Patrick Dwyer <[email-masked]>
Date: Tue, 1 Feb 2022 12:27:42 +1000

Juha, thanks for more great feedback.

Apologies for taking so long to get this revision back to the group.

New version:

Version: 1

Date: 2022-01-01

Registrant: Patrick Dwyer, on behalf of the OWASP CycloneDX project.
Email: [email-masked]
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 f-component specifying the location of the element
within the BOM identified by the URN.

Syntax:

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 [RFC3986].

Assignment:

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.

Security and Privacy:

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.