Draft: draft-ietf-sacm-coswid

Commentary: based on : 
 PR summarized in for WG feedback .
Mailing list commentary: Hi ! Thanks for publishing -21 in response to IESG review . I was asked to clarify why draft - ietf - sacm - coswid-21 is in " Revised ID Needed " state -- a number of COMMENTs from the IESG review still need attention . Specifically : [ Source : ] = =[ snip : Francesca 's position ]= = Francesca Palombini No Objection 1 . ----- If the patch item is set to " true " , the tag SHOULD contain at least one link item ( see Section 2.7 ) with both the rel item value of " patches " and an href item specifying an association with the software that was patched . If the supplemental item is set to " true " , the tag SHOULD contain at least one link item with both the rel item value of " supplemental " and an href item specifying an association with the software that is supplemented . : This is missing text about why these are SHOULD and not MUST or MAY . I agree with , who formulated it very clearly : If SHOULD is used , then it must be accompanied by at least one of : ( 1 ) A general description of the character of the exceptions and/or in what areas exceptions are likely to arise . Examples are fine but , except in plausible and rare cases , not enumerated lists . ( 2 ) A statement about what should be done , or what the considerations are , if the " SHOULD " requirement is not met . ( 3 ) A statement about why it is not a MUST . [ Roman on -21 ] Thanks for the new language . It does n't appear to provide much clarification . The preamble to the bulleted list says " If any of these constraints is not met , a signed tag can not be used anymore as a signed statement . " I do n't follow what " can not be used anymore " means . Is that saying that a tag is signed with a valid signature , but the contents do n't make sense so it should just be ignored ? I ' m not sure how to assess conformance when the four subsequent bullets include a ( bullet 1 ) , SHOULD ( bullet 2 ) , SHOULD ( bullet 3 ) and ( bullet 4 ) . If one treats conformance with the mindset of boolean algebra - the bullet 2 and 3 are irrelevant because the weaker SHOULD could go either way . 2 . ----- r artifact ( index : 37 ): To be used with rel="installation - media " , : Should " installation - media " be " installationmedia " instead ? [ Roman on -21 ] Please fix 3 . ----- date ( index 35 ): The date and time the information was collected pertaining to the evidence item . FP : Please add a reference to Section 3.4.1 [ RFC8949 ] and mention that this is the standard date / time string . [ Roman on -21 ] This seems like a helpful clarifying refence for the reader . 4 . ----- space , the " decimal " version scheme SHOULD be used .  : Here ( and following bullets ) is another case that either requires a better context description about the use of SHOULD , or should be rephrased ( possibly avoiding the BCP 14 SHOULD ) for example : space , it is expected that the " decimal " version be used . [ Roman on -21 ] Thanks for the next text of " the " decimal " version scheme SHOULD be assumed . " I do n't see how it does n't simply state ( " be used " = = > " be assumed " ) responds to the ambiguity issued suggested by this COMMENT . Are the " SHOULDs " in these three bulleted clauses needed ? = =[ end ]= = = =[ snip : 's position ]= = ( was ) No Objection Comment ( 2022 - 03 - 21 ) Hi , I ' ve discussed this with Roman and and I ' ve agreed to remove my discuss so that the document can be approved and move forward before the new IESG handover . The proposal for the two issues below are : ( 1 ) I think that it would be helpful to have a liaison statement between the SACM WG and ISO that confirms the ongoing expectation and evolution of SWID and CoSWID , i.e. , my understanding is that ISO intends to reuse the IANA registry and I think that it would be good to get that more formally confirmed now whilst everyone agrees , so that this does n't end up being a problem in future when participants have changed and moved on to new projects . This does n't need to block the progression of this document , it could be done in parallel . I also do n't think that this had to be written into the document , but possibly a comment in the document may be helpful to set the context for future readers . [ Roman on -21 ] Rob cleared his DISCUSS on faith to ensure this document did n't lose positions in the AD turnover at IETF 113 . I have seen no explanation to back to . I share 's concerns . The coevolution of this specification with SWID has been a moving target . When I first inquired about this during AD review in October 2020 ( ) , I heard that CoSWID would independently evolve via it 's self - defined IANA registries . That was consistent with the current text which effectively positioned this document as a fork . During IETF LC OPSDIR directorate review ( ) the story changed to SWID now planning to use the IETF registries which suggests that they would co - evolve . This intended co - evolution was the motivation for keeping certain IANA registry names " swid " as opposed to " coswid " . However , the document still has the following text in Section 1 ( which seems to contradict the co - evolution idea ): While an attempt to align SWID and CoSWID tags has been made here , future revisions of ISO / IEC - 2:2015 or this specification might cause this implicit information model to diverge , since these specifications are maintained by different standards groups . Can the current swid - coswid coevolution plan be explained ? Can the basis of this plan also be clarified - one approach could be a liaison statement . ] In addition to this discussion , I believe this document needs to clearly set expectation for implementers with the information we have now - is this CoSWID document ( a ) an alternative data model for - 2:2015 / SWID in CBOR with full feature parity ( i.e. , if I can do it in - 2:2015 , I can do it CoSWID ; and vice versa ) ; or ( b ) a forked data model of - 2:2015 / SWID in CBOR that has additional capability ( i.e. , do n't assume that just because something can be represented in the CoSWID data model , that it can be converted / represented in - 2:2015 SWID ) . Please refine this limited set of expectations as appropriate . ( 2 ) Regarding the Semver 2.0.0 reference , the suggestion from Roman , which I agree with is that it would be better if the SEMVER reference cited the ITU SWID spec as the normative reference and the current accurate github reference becomes informative . [ Roman on -21 ] [ SEMVER ] is still a normative reference . = =[ snip : from = to " Section 2.4 , paragraph 2 " , which mostly do n't seem to make sense to me . Please double - check . Section 2.3 version - scheme ( index 14 ): An integer or textual value representing the versioning scheme used for the software - version item , as an integer label with text escape ( Section 2 , for the needs a close paren somewhere [ Roman on -21 ] Please fix Section 9 Converse , generators of CoSWID tags need to ensure that only public " Conversely " [ Roman on -21 ] Please fix . = =[ end ]= = Regards , Roman
Hi Roman , a big thank you for your support of steering the various inputs . That really helped us moving forward . As a result , there is now : Individual commits addressing distinguishable topics , as well as additional comments are in - line . I messed up one commit ( as it addresses two issues ) and one issue we will address in a separate email ( as is it not solved by a simple commit ) . ,  To stay consistent and aligned with the SWID specification all ( remaining ) bullet items are now MUST statements . The statement on supplemental tag was removed as the index 11 definition in Section 4.4 . sufficiently defines the use of supplemental tag use and conditions when to use it and does not require additional normative statements here . Fixed in commit Fixed in commit Fixed in commit ( this also includes the next issue 4 , sry ) Fixed in commit With respect to ( 1 ) , we 'll split this topic off into a separate thread and will cover that topic last - if that is okay . Lazy oversight that is fixed in commit Fixed in commit and Fixed in commit and thanks again !
Paragraph (version A):
All names registered with IANA according to requirements in iana-
value-registries also MUST be valid according to the XML Schema
NMTOKEN data type (see W3C.REC-xmlschema-2-20041028 Section 3.3.4) to
ensure compatibility with the SWID specification where these names
are used.
Paragraph (version B):
All names registered with IANA according to requirements in iana-
value-registries also MUST be valid according to the XML Schema
NMTOKEN data type (see W3C.REC-xmlschema-2-20041028, Section 3.3.4)
to ensure compatibility with the SWID specification where these names
are used.
Paragraph (version A):
The inclusion of extension points in the CoSWID specification
using CDDL sockets (see RFC8610 Section 3.9).  The use of CDDL
sockets allow for well-formed extensions to be defined in
supplementary CDDL descriptions that support additional uses of
CoSWID tags that go beyond the original scope of ISO-19770-2:2015
tags.  This extension mechanism can also be used to update the
CoSWID format as revisions to ISO-19770-2 are published.
Paragraph (version B):
The inclusion of extension points in the CoSWID specification
using CDDL sockets (see RFC8610).  The use of CDDL sockets allow
for well-formed extensions to be defined in supplementary CDDL
descriptions that support additional uses of CoSWID tags that go
beyond the original scope of ISO-19770-2:2015 tags.
Paragraph (version A):
version-scheme (index 14): An integer or textual value
representing the versioning scheme used for the software-version
item, as an integer label with text escape (data-def, for the
"Version Scheme" registry indexed-version-scheme.  . If an integer
value is used it MUST be an index value in the range -256 to
65535.  Integer values in the range -256 to -1 are reserved for
testing and use in closed environments (see iana-private-use).
Integer values in the range 0 to 65535 correspond to registered
entries in the IANA "Software Tag Version Scheme Values" registry
(see iana-version-scheme.
Paragraph (version B):
version-scheme (index 14): An integer or textual value
representing the versioning scheme used for the software-version
item, as an integer label with text escape (data-def, for the
"Version Scheme" registry indexed-version-scheme).  If an integer
value is used it MUST be an index value in the range -256 to
65535.  Integer values in the range -256 to -1 are reserved for
testing and use in closed environments (see iana-private-use).
Integer values in the range 0 to 65535 correspond to registered
entries in the IANA "Software ID Version Scheme Values" registry
(see iana-version-scheme).
Paragraph (version A):
The following co-constraints apply to the information provided in the
concise-swid-tag group.  If any of these constraints is not met, a
signed tag cannot be used anymore as a signed statement.
Paragraph (version A):
If the patch item is set to "true", the tag SHOULD contain at
least one link item (see model-link) with both the rel item value
of "patches" and an href item specifying an association with the
software that was patched.  Without at least one link item the
target of the patch cannot be identified and the patch tag cannot
be applied without external context.
Paragraph (version A):
If the supplemental item is set to "true", the tag SHOULD contain
at least one link item with both the rel item value of
"supplemental" and an href item specifying an association with the
software that is supplemented.  Without at least one link item the
target of supplement tag cannot be identified and the patch tag
cannot be applied without external context.
Paragraph (version B):
The following co-constraints apply to the information provided in the
concise-swid-tag group.
Paragraph (version B):
If the patch item is set to "true", the tag MUST contain at least
one link item (see model-link) with both the rel item value of
"patches" and an href item specifying an association with the
software that was patched.  Without at least one link item the
target of the patch cannot be identified and the patch tag cannot
be applied without external context.
Paragraph (version A):
role (index 33): An integer or textual value (integer label with
text escape, see data-def) representing the relationship(s)
between the entity, and this tag or the referenced software
component.  If an integer value is used it MUST be an index value
in the range -256 to 255.  Integer values in the range -256 to -1
are reserved for testing and use in closed environments (see iana-
private-use).  Integer values in the range 0 to 255 correspond to
registered entries in the IANA "Software Tag Entity Role Values"
registry (see iana-entity-role.
Paragraph (version B):
role (index 33): An integer or textual value (integer label with
text escape, see data-def) representing the relationship(s)
between the entity, and this tag or the referenced software
component.  If an integer value is used it MUST be an index value
in the range -256 to 255.  Integer values in the range -256 to -1
are reserved for testing and use in closed environments (see iana-
private-use).  Integer values in the range 0 to 255 correspond to
registered entries in the IANA "Software ID Entity Role Values"
registry (see iana-entity-role).
Paragraph (version A):
artifact (index 37): To be used with rel="installation-media",
this item's value provides the absolute filesystem path to the
installer executable or script that can be run to launch the
referenced installation.  Links with the same artifact name MUST
be considered mirrors of each other, allowing the installation
media to be acquired from any of the described sources.
Paragraph (version B):
artifact (index 37): To be used with rel="installationmedia", this
item's value provides the absolute filesystem path to the
installer executable or script that can be run to launch the
referenced installation.  Links with the same artifact name MUST
be considered mirrors of each other, allowing the installation
media to be acquired from any of the described sources.
Paragraph (version A):
ownership (index 39): An integer or textual value (integer label
with text escape, see data-def, for the "Software Tag Link
Ownership Values" registry indexed-link-ownership) used when the
"href" item references another software component to indicate the
degree of ownership between the software component referenced by
the CoSWID tag and the software component referenced by the link.
If an integer value is used it MUST be an index value in the range
-256 to 255.  Integer values in the range -256 to -1 are reserved
for testing and use in closed environments (see iana-private-use).
Integer values in the range 0 to 255 correspond to registered
entries in the "Software Tag Link Ownership Values" registry.
Paragraph (version B):
ownership (index 39): An integer or textual value (integer label
with text escape, see data-def, for the "Software ID Link
Ownership Values" registry indexed-link-ownership) used when the
"href" item references another software component to indicate the
degree of ownership between the software component referenced by
the CoSWID tag and the software component referenced by the link.
If an integer value is used it MUST be an index value in the range
-256 to 255.  Integer values in the range -256 to -1 are reserved
for testing and use in closed environments (see iana-private-use).
Integer values in the range 0 to 255 correspond to registered
entries in the "Software ID Link Ownership Values" registry.
Paragraph (version A):
entries in the "Software Tag Link Ownership Values" registry.
Paragraph (version B):
entries in the "Software ID Link Ownership Values" registry.
Paragraph (version A):
rel (index 40): An integer or textual value that (integer label
with text escape, see data-def, for the "Software Tag Link Link
Relationship Values" registry indexed-link-ownership) identifies
the relationship between this CoSWID and the target resource
identified by the "href" item.  If an integer value is used it
MUST be an index value in the range -256 to 65535.  Integer values
in the range -256 to -1 are reserved for testing and use in closed
environments (see iana-private-use).  Integer values in the range
0 to 65535 correspond to registered entries in the IANA "Software
Tag Link Relationship Values" registry (see iana-link-rel.  If a
string value is used it MUST be either a private use name as
defined in iana-private-use or a "Relation Name" from the IANA
"Link Relation Types" registry: https://www.iana.org/assignments/
link-relations/link-relations.xhtml as defined by RFC8288.  When a
string value defined in the IANA "Software Tag Link Relationship
Values" registry matches a Relation Name defined in the IANA "Link
Relation Types" registry, the index value in the IANA "Software
Tag Link Relationship Values" registry MUST be used instead, as
this relationship has a specialized meaning in the context of a
CoSWID tag.  String values correspond to registered entries in the
"Software Tag Link Relationship Values" registry.
Paragraph (version B):
rel (index 40): An integer or textual value that (integer label
with text escape, see data-def, for the "Software ID Link Link
Relationship Values" registry indexed-link-ownership) identifies
the relationship between this CoSWID and the target resource
identified by the "href" item.  If an integer value is used it
MUST be an index value in the range -256 to 65535.  Integer values
in the range -256 to -1 are reserved for testing and use in closed
environments (see iana-private-use).  Integer values in the range
0 to 65535 correspond to registered entries in the IANA "Software
ID Link Relationship Values" registry (see iana-link-rel).  If a
string value is used it MUST be either a private use name as
defined in iana-private-use or a "Relation Name" from the IANA
"Link Relation Types" registry: https://www.iana.org/assignments/
link-relations/link-relations.xhtml as defined by RFC8288.  When a
string value defined in the IANA "Software ID Link Relationship
Values" registry matches a Relation Name defined in the IANA "Link
Relation Types" registry, the index value in the IANA "Software ID
Link Relationship Values" registry MUST be used instead, as this
relationship has a specialized meaning in the context of a CoSWID
tag.  String values correspond to registered entries in the
"Software ID Link Relationship Values" registry.
Paragraph (version A):
iana-link-use.  If a string value is used it MUST be a private use
name as defined in iana-private-use.  String values correspond to
registered entries in the "Software Tag Link Use Values" registry.
Paragraph (version B):
iana-link-use).  If a string value is used it MUST be a private
use name as defined in iana-private-use.  String values correspond
to registered entries in the "Software ID Link Use Values"
registry.
Paragraph (version A):
date (index 35): The date and time the information was collected
pertaining to the evidence item.
Paragraph (version B):
date (index 35): The date and time the information was collected
pertaining to the evidence item in Epoch-Based Date/Time format as
specified in RFC8949.
Paragraph (version A):
The values above are registered in the IANA "Software Tag Version
Scheme Values" registry defined in Section iana-version-scheme.
Additional entries will likely be registered over time in this
registry.
Paragraph (version B):
The values above are registered in the IANA "Software ID Version
Scheme Values" registry defined in iana-version-scheme.  Additional
entries will likely be registered over time in this registry.
Paragraph (version A):
"decimal" and "multipartnumeric" partially overlap in their value
space when a value matches a decimal number.  When a corresponding
software-version item's value falls within this overlapping value
space, the "decimal" version scheme SHOULD be assumed.
Paragraph (version A):
"multipartnumeric" and "semver" partially overlap in their value
space when a "multipartnumeric" value matches the semantic
versioning syntax.  When a corresponding software-version item's
value falls within this overlapping value space, the "semver"
version scheme SHOULD be assumed.
Paragraph (version A):
"alphanumeric" and other version schemes might overlap in their
value space.  When a corresponding software-version item's value
falls within this overlapping value space, the other version
scheme SHOULD be assumed instead of "alphanumeric".
Paragraph (version B):
"decimal" and "multipartnumeric" partially overlap in their value
space when a value matches a decimal number.  When a corresponding
software-version item's value falls within this overlapping value
space, it is expected that the "decimal" version scheme is used.
Paragraph (version B):
"multipartnumeric" and "semver" partially overlap in their value
space when a "multipartnumeric" value matches the semantic
versioning syntax.  When a corresponding software-version item's
value falls within this overlapping value space, it is expected
that the "semver" version scheme is used.
Paragraph (version B):
"alphanumeric" and other version schemes might overlap in their
value space.  When a corresponding software-version item's value
falls within this overlapping value space, it is expected that the
other version scheme is used and "alphanumeric" is not used.
Paragraph (version A):
The values above are registered in the IANA "Software Tag Entity Role
Values" registry defined in iana-entity-role.  Additional values will
likely be registered over time.
Paragraph (version B):
The values above are registered in the IANA "Software ID Entity Role
Values" registry defined in iana-entity-role.  Additional values will
likely be registered over time.
Paragraph (version A):
The values above are registered in the IANA "Software Tag Link
Ownership Values" registry defined in iana-link-ownership.
Additional values will likely be registered over time.
Paragraph (version B):
The values above are registered in the IANA "Software ID Link
Ownership Values" registry defined in iana-link-ownership.
Additional values will likely be registered over time.
Paragraph (version A):
The values above are registered in the IANA "Software Tag Link
Relationship Values" registry defined in iana-link-rel.  Additional
values will likely be registered over time.
Paragraph (version B):
The values above are registered in the IANA "Software ID Link
Relationship Values" registry defined in iana-link-rel.  Additional
values will likely be registered over time.
Paragraph (version A):
The values above are registered in the IANA "Software Tag Link Use
Values" registry defined in iana-link-use.  Additional values will
likely be registered over time.
Paragraph (version B):
The values above are registered in the IANA "Software ID Link Use
Values" registry defined in iana-link-use.  Additional values will
likely be registered over time.
Paragraph (version A):
For URIs that use the "swid" scheme, the scheme specific part MUST
consist of a referenced software tag's tag-id.  This tag-id MUST be
URI encoded according to RFC3986 Section 2.1.
Paragraph (version B):
For URIs that use the "swid" scheme, the scheme specific part MUST
consist of a referenced software tag's tag-id.  This tag-id MUST be
URI encoded according to RFC3986.
Paragraph (version A):
The scheme specific part MUST be an XPath expression as defined by
W3C.REC-xpath20-20101214.  The included XPath expression will be
URI encoded according to RFC3986 Section 2.1.
Paragraph (version A):
This XPath is evaluated over SWID tags, or COSWID tags transformed
into SWID tags, found on a system.  A given tag MUST be considered
a match if the XPath evaluation result value has an effective
boolean value of "true" according to W3C.REC-xpath20-20101214
Section 2.4.3.
Paragraph (version B):
The scheme specific part MUST be an XPath expression as defined by
W3C.REC-xpath20-20101214.  The included XPath expression will be
URI encoded according to RFC3986.
Paragraph (version B):
This XPath is evaluated over SWID tags, or COSWID tags transformed
into SWID tags, found on a system.  A given tag MUST be considered
a match if the XPath evaluation result value has an effective
boolean value of "true" according to W3C.REC-xpath20-20101214,
Section 2.4.3.
Paragraph (version A):
The following IANA registries provide a mechanism for new values to
be added over time to common enumerations used by SWID and CoSWID.
While neither the CoSWID nor SWID specification is subordinate to the
other and will evolve as their respective standards group chooses,
there is value in supporting alignment between the two standards.
Shared use of common code points, as spelled out in these registries,
will facilitate this alignment, hence the intent for shared use of
these registries and the decision to use "swid" (rather than
"coswid") in registry names.
Paragraph (version B):
The following IANA registries provide a mechanism for new values to
be added over time to common enumerations used by SWID and CoSWID.
While neither the CoSWID nor SWID specification is subordinate to the
other and will evolve as their respective standards group chooses,
there is value in supporting alignment between the two standards.
Shared use of common code points, as spelled out in these registries,
will facilitate this alignment, hence the intent for shared use of
these registries and the decision to use "swidsoftware-id" (rather
than "swid" or "coswid") in registry names.
Paragraph (version A):
The following registries also reserve the integer-based index values
in the range of -1 to -256 for private use as defined by BCP26 in
Section 4.1.  This allows values -1 to -24 to be expressed as a
single uint_8t in CBOR, and values -25 to -256 to be expressed using
an additional uint_8t in CBOR.
Paragraph (version B):
The following registries also reserve the integer-based index values
in the range of -1 to -256 for private use as defined by BCP26.  This
allows values -1 to -24 to be expressed as a single uint_8t in CBOR,
and values -25 to -256 to be expressed using an additional uint_8t in
CBOR.
Paragraph (version A):
All registered names MUST be valid according to the XML Schema
NMTOKEN data type (see W3C.REC-xmlschema-2-20041028
Section 3.3.4).  This ensures that registered names are compatible
with the SWID format SWID where they are used.
Paragraph (version B):
All registered names MUST be valid according to the XML Schema
NMTOKEN data type (see W3C.REC-xmlschema-2-20041028,
Section 3.3.4).  This ensures that registered names are compatible
with the SWID format SWID where they are used.
Paragraph (version A):
This document establishes a new registry titled "Software Tag Version
Scheme Values".  This registry provides index values for use as
version-scheme item values in this document and version scheme names
for use in SWID.
Paragraph (version B):
This document establishes a new registry titled "Software ID Version
Scheme Values".  This registry provides index values for use as
version-scheme item values in this document and version scheme names
for use in SWID.
Paragraph (version A):
Initial registrations for the "Software Tag Version Scheme Values"
registry are provided below, which are derived from the textual
version scheme names defined in SWID.
Paragraph (version B):
Initial registrations for the "Software ID Version Scheme Values"
registry are provided below, which are derived from the textual
version scheme names defined in SWID.
Paragraph (version A):
This document establishes a new registry titled "Software Tag Entity
Role Values".  This registry provides index values for use as entity-
entry role item values in this document and entity role names for use
in SWID.
Paragraph (version B):
This document establishes a new registry titled "Software ID Entity
Role Values".  This registry provides index values for use as entity-
entry role item values in this document and entity role names for use
in SWID.
Paragraph (version A):
Initial registrations for the "Software Tag Entity Role Values"
registry are provided below, which are derived from the textual
entity role names defined in SWID.
Paragraph (version B):
Initial registrations for the "Software ID Entity Role Values"
registry are provided below, which are derived from the textual
entity role names defined in SWID.
Paragraph (version A):
This document establishes a new registry titled "Software Tag Link
Ownership Values".  This registry provides index values for use as
link-entry ownership item values in this document and link ownership
names for use in SWID.
Paragraph (version B):
This document establishes a new registry titled "Software ID Link
Ownership Values".  This registry provides index values for use as
link-entry ownership item values in this document and link ownership
names for use in SWID.
Paragraph (version A):
Initial registrations for the "Software Tag Link Ownership Values"
registry are provided below, which are derived from the textual
entity role names defined in SWID.
Paragraph (version B):
Initial registrations for the "Software ID Link Ownership Values"
registry are provided below, which are derived from the textual
entity role names defined in SWID.
Paragraph (version A):
This document establishes a new registry titled "Software Tag Link
Relationship Values".  This registry provides index values for use as
link-entry rel item values in this document and link ownership names
for use in SWID.
Paragraph (version B):
This document establishes a new registry titled "Software ID Link
Relationship Values".  This registry provides index values for use as
link-entry rel item values in this document and link ownership names
for use in SWID.
Paragraph (version A):
Initial registrations for the "Software Tag Link Relationship Values"
registry are provided below, which are derived from the link
relationship values defined in SWID.
Paragraph (version B):
Initial registrations for the "Software ID Link Relationship Values"
registry are provided below, which are derived from the link
relationship values defined in SWID.
Paragraph (version A):
This document establishes a new registry titled "Software Tag Link
Use Values".  This registry provides index values for use as link-
entry use item values in this document and link use names for use in
SWID.
Paragraph (version B):
This document establishes a new registry titled "Software ID Link Use
Values".  This registry provides index values for use as link-entry
use item values in this document and link use names for use in SWID.
Paragraph (version A):
Initial registrations for the "Software Tag Link Use Values" registry
are provided below, which are derived from the link relationship
values defined in SWID.
Paragraph (version B):
Initial registrations for the "Software ID Link Use Values" registry
are provided below, which are derived from the link relationship
values defined in SWID.
Paragraph (version A):
CoSWID tags are intended to contain public information about software
components and, as such, the contents of a CoSWID tag (as opposed to
the set of tags that apply to the endpoint, see below) does not need
to be protected against unintended disclosure on an endpoint.
Converse, generators of CoSWID tags need to ensure that only public
information is disclosed.  Entitlement Keys are an example for
information where particular care is required; tag authors are
advised not to record unprotected, private software license keys in
this field.
Paragraph (version B):
CoSWID tags are intended to contain public information about software
components and, as such, the contents of a CoSWID tag (as opposed to
the set of tags that apply to the endpoint, see below) does not need
to be protected against unintended disclosure on an endpoint.
Conversely, generators of CoSWID tags need to ensure that only public
information is disclosed.  Entitlement Keys are an example for
information where particular care is required; tag authors are
advised not to record unprotected, private software license keys in
this field.
Paragraph (version A):
protected as both security and privacy sensitive information.
Paragraph (version B):
protected as both security and privacy-sensitive information.