Draft: draft-ietf-sacm-coswid

Commentary: Edits to address AD review feedback from   , with specific focus on CoSWID issues
Paragraph (version A):
ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an
extensible XML-based structure to identify and describe individual
software components, patches, and installation bundles.  SWID tag
representations can be too large for devices with network and storage
constraints.  This document defines a concise representation of SWID
tags: Concise SWID (CoSWID) tags.  CoSWID supports the same features
as SWID tags, as well as additional semantics that allow CoSWIDs to
describe additional types of information, all in a more memory
efficient format.
Paragraph (version B):
ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an
extensible XML-based structure to identify and describe individual
software components, patches, and installation bundles.  SWID tag
representations can be too large for devices with network and storage
constraints.  This document defines a concise representation of SWID
tags: Concise SWID (CoSWID) tags.  CoSWID supports a similar set of
semantics and features as SWID tags, as well as new semantics that
allow CoSWIDs to describe additional types of information, all in a
more memory efficient format.
Paragraph (version A):
Remote Attestation, which requires a link between reference
integrity measurements (RIM) and security logs of measured
software components I-D.birkholz-rats-tuda.
Paragraph (version B):
Remote Attestation, which requires a link between reference
integrity measurements (RIM) and Attester-produced event logs that
complement attestation Evidence I-D.ietf-rats-architecture.
Paragraph (version A):
typical SWID tag.  This reduction is enabled through the use of the
Concise Binary Object Representation (CBOR) RFC7049, which maps the
human-readable labels of SWID data items to more concise integer
labels (indices).  The use of CBOR to express SWID information in
CoSWID tags allows both CoSWID and SWID tags to be part of an
enterprise security solution for a wider range of endpoints and
environments.
Paragraph (version B):
In a CoSWID, the human-readable labels of SWID data items are
replaced with more concise integer labels (indices).  This approach
allows SWID and CoSWID to share a common implicit information model,
with CoSWID providing an alternate data model RFC3444.  While SWID
and CoSWID are intended to share the same implicit information model,
this specification does not define this information model, or a
mapping between the the two data formats.  While an attempt to align
SWID and CoSWID tags has been made here, future revisions of ISO/IEC
19770-2:2015 or this specification might cause this implicit
information model to diverge, since these specifications are
maintained by different standards groups.
Paragraph (version B):
The use of CBOR to express SWID information in CoSWID tags allows
both CoSWID and SWID tags to be part of an enterprise security
solution for a wider range of endpoints and environments.
Paragraph (version A):
The type of a tag is determined by specific data elements, which are
discussed in semantics-tag-type.
Paragraph (version B):
The type of a tag is determined by specific data elements, which are
discussed in semantics-tag-type, which also provides normative
language for CoSWID semantics that implement this lifecycle.  The
following information helps to explain how these semantics apply to
use of a CoSWID tag.
Paragraph (version B):
fig-lifecycle illustrates the steps in the software lifecycle and
the relationships among those lifecycle events supported by the
four types of SWID and CoSWID tags.  A detailed description of the
four tags types is provided in model-concise-swid-tag.  The figure
identifies the types of tags that are used in each lifecycle
event.
Paragraph (version B):
There are many ways in which software tags might be managed for the
host the software is installed on.  For example, software tags could
be made available on the host or to an external software manager when
storage is limited on the host.
Paragraph (version B):
Corpus tags are not actually deployed on the target system but are
intended to support deployment procedures and their dependencies at
install-time, such as to verify the installation media.
Paragraph (version B):
Note: In the context of software tagging software patching and
updating differ in an important way.  When installing a patch, a set
of file modifications are made to pre-installed software which do not
alter the version number or the descriptive metadata of an installed
software component.  An update can also make a set of file
modifications, but the version number or the descriptive metadata of
an installed software component are changed.
Paragraph (version A):
This document defines the CoSWID tag format, which is based on CBOR.
CBOR-based CoSWID tags offer a more concise representation of SWID
information as compared to the XML-based SWID tag representation in
ISO-19770-2:2015.  The structure of a CoSWID is described via the
Concise Data Definition Language (CDDL) RFC8610.  The resulting
CoSWID data definition is aligned to the information able to be
expressed with the XML schema definition of ISO-19770-2:2015 SWID.
This alignment allows both SWID and CoSWID tags to represent a common
set of software component information and allows CoSWID tags to
support the same uses as a SWID tag.  To achieve this end, the CDDL
representation includes every SWID tag field and attribute.
Paragraph (version B):
This document defines the CoSWID tag format, which is based on CBOR.
CBOR-based CoSWID tags offer a more concise representation of SWID
information as compared to the XML-based SWID tag representation in
ISO-19770-2:2015.  The structure of a CoSWID is described via the
Concise Data Definition Language (CDDL) RFC8610.  The resulting
CoSWID data definition is aligned to the information able to be
expressed with the XML schema definition of ISO-19770-2:2015 SWID.
This alignment allows both SWID and CoSWID tags to represent a common
set of software component information and allows CoSWID tags to
support the same uses as a SWID tag.
Paragraph (version A):
This section describes the rules by which SWID tag XML is represented
in the CoSWID CDDL structure.  The CamelCase CamelCase notation used
in the XML schema definition is changed to a hyphen-separated
notation KebabCase (e.g.  ResourceCollection is named resource-
collection) in the CoSWID CDDL specification.  This deviation from
the original notation used in the XML representation reduces
ambiguity when referencing certain attributes in corresponding
textual descriptions.  An attribute referred to by its name in
CamelCase notation explicitly relates to XML SWID tags; an attribute
referred to by its name in KebabCase notation explicitly relates to
CBOR CoSWID tags.  This approach simplifies the composition of
further work that reference both XML SWID and CBOR CoSWID documents.
Paragraph (version B):
This section describes the conventions by which a CoSWID is
represented in the CDDL structure.  The CamelCase CamelCase notation
used in the XML schema definition is changed to a hyphen-separated
notation KebabCase (e.g.  ResourceCollection is named resource-
collection) in the CoSWID CDDL specification.  This deviation from
the original notation used in the XML representation reduces
ambiguity when referencing certain attributes in corresponding
textual descriptions.  An attribute referred to by its name in
CamelCase notation explicitly relates to XML SWID tags; an attribute
referred to by its name in KebabCase notation explicitly relates to
CBOR CoSWID tags.  This approach simplifies the composition of
further work that reference both XML SWID and CBOR CoSWID documents.
Paragraph (version A):
In most cases, mapping attribute names between SWID and CoSWID can be
done automatically by converting between CamelCase and KebabCase
attribute names.  However, some CoSWID CDDL attribute names show
greater variation relative to their corresponding SWID XML Schema
attributes.  This is done when the change improves clarity in the
specification.  For example the "name" and "version" SWID fields
corresponds to the "software-name" and "software-version" CoSWID
fields, respectively.  As such, it is not always possible to
mechanically translate between corresponding attribute names in the
two formats.  In such cases, a manual mapping will need to be used.
Paragraph (version B):
In most cases, mapping attribute names between SWID and CoSWID can be
done automatically by converting between CamelCase and KebabCase
attribute names.  However, some CoSWID CDDL attribute names show
greater variation relative to their corresponding SWID XML Schema
attributes.  This is done when the change improves clarity in the
CoSWID specification.  For example the "name" and "version" SWID
fields corresponds to the "software-name" and "software-version"
CoSWID fields, respectively.  As such, it is not always possible to
mechanically translate between corresponding attribute names in the
two formats.  In such cases, a manual mapping will need to be used.
Paragraph (version A):
All names registered with IANA according to requirements in section
iana-value-registries also need to be valid according to the XML
Schema NMToken data type (see W3C.REC-xmlschema-2-20041028 section
these names are used.
Paragraph (version B):
All names registered with IANA according to requirements in Section
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):
A number of SWID/CoSWID value registries are also defined in iana-
value-registries that allow new values to be registered with IANA for
the enumerations above.  This registration mechanism supports the
definition of new well-known index values and names for new
enumeration values used by both SWID and CoSWID.  This registration
mechanism allows new standardized enumerated values to be shared
between both specifications (and implementations) over time, and
references to the IANA registries will be added to the next revision
of SWID.
Paragraph (version B):
A number of CoSWID value registries are also defined in iana-value-
registries that allow new values to be registered with IANA for the
enumerations above.  This registration mechanism supports the
definition of new well-known index values and names for new
enumeration values used by CoSWID, which can also be used by other
software tagging specifications.  This registration mechanism allows
new standardized enumerated values to be shared between multiple
tagging specifications (and associated implementations) over time.
Paragraph (version A):
patch (index 9): A boolean value that indicates if the tag
identifies and describes an installed patch that has made
incremental changes to a software component installed on an
endpoint.  Typically, an installed patch has made a set of file
modifications to pre-installed software and does not alter the
version number or the descriptive metadata of an installed
software component.  If a CoSWID tag is for a patch, the patch
item MUST be set to "true".  If not provided, the default value
MUST be considered "false".
Paragraph (version A):
Note: If the software component's version number is modified, then
the correct course of action would be to replace the previous
primary tag for the component with a new primary tag that
reflected this new version.  In such a case, the new tag would
have a patch item value of "false" or would omit this item
completely.
Paragraph (version B):
patch (index 9): A boolean value that indicates if the tag
identifies and describes an installed patch that has made
incremental changes to a software component installed on an
endpoint.  If a CoSWID tag is for a patch, the patch item MUST be
set to "true".  If not provided, the default value MUST be
considered "false".  A patch item's value MUST NOT be set to
"true" if the installation of the associated software package
changes the version of a software component.
Paragraph (version A):
version-scheme (index 14): An integer or textual value
representing the versioning scheme used for the software-version
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
section iana-private-use).  Integer values in the range 0 to 65535
correspond to registered entries in the IANA "SWID/CoSWID Version
Scheme Value" registry (see section iana-version-scheme.  If a
string value is used it MUST be a private use name as defined in
section iana-private-use.  String values based on a Version Scheme
Name from the IANA "SWID/CoSWID Version Scheme Value" registry
MUST NOT be used, as these values are less concise than their
index value equivalent.
Paragraph (version A):
media (index 10): This text value is a hint to the tag consumer to
understand what target platform this tag applies to.  This item
represents a query as defined by the W3C Media Queries
Recommendation (see W3C.REC-css3-mediaqueries-20120619).
Paragraph (version B):
version-scheme (index 14): An integer or textual value
representing the versioning scheme used for the software-version
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
Section 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 Section iana-version-scheme.  If a
string value is used it MUST be a private use name as defined in
Section iana-private-use.  String values based on a Version Scheme
Name from the IANA "Software Tag Version Scheme Values" registry
MUST NOT be used, as these values are less concise than their
index value equivalent.
Paragraph (version B):
media (index 10): This text value is a hint to the tag consumer to
understand what target platform this tag applies to.  This item
item MUST be formatted as a query as defined by the W3C Media
Queries Recommendation (see W3C.REC-css3-mediaqueries-20120619).
Support for media queries are included here for interoperability
with SWID, which does not provide any further requirements for
media query use.  Thus, this specification does not clarify how a
media query is to be used for a CoSWID.
Paragraph (version A):
entity-name (index 32): The textual name of the organizational
entity claiming the roles specified by the role item for the
CoSWID tag.
Paragraph (version A):
reg-id (index 32): The registration id value is intended to
uniquely identify a naming authority in a given scope (e.g.
global, organization, vendor, customer, administrative domain,
etc.) for the referenced entity.  The value of an registration ID
MUST be a RFC 3986 URI.  The scope SHOULD be the scope of an
organization.  In a given scope, the registration id MUST be used
consistently for CoSWID tag production.
Paragraph (version A):
role (index 33): An integer or textual value 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 section iana-private-use).  Integer values in the range 0 to
255 correspond to registered entries in the IANA "SWID/CoSWID
Entity Role Value" registry (see section iana-entity-role.  If a
string value is used it MUST be a private use name as defined in
section iana-private-use.  String values based on a Role Name from
the IANA "SWID/CoSWID Entity Role Value" registry MUST NOT be
used, as these values are less concise than their index value
equivalent.
Paragraph (version B):
entity-name (index 31): The textual name of the organizational
entity claiming the roles specified by the role item for the
CoSWID tag.
Paragraph (version B):
reg-id (index 32): The registration id value is intended to
uniquely identify a naming authority in a given scope (e.g.
global, organization, vendor, customer, administrative domain,
etc.) for the referenced entity.  The value of a registration ID
MUST be a RFC 3986 URI.  The scope SHOULD be the scope of an
organization.
Paragraph (version B):
role (index 33): An integer or textual value 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 Section 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 Section iana-entity-role.  If a
string value is used it MUST be a private use name as defined in
Section iana-private-use.  String values based on a Role Name from
the IANA "Software Tag Entity Role Values" registry MUST NOT be
used, as these values are less concise than their index value
equivalent.
Paragraph (version A):
If no URI scheme is provided, then the URI is to be interpreted
as being relative to the URI of the CoSWID tag.  For example,
"./folder/supplemental.coswid".
Paragraph (version B):
If no URI scheme is provided, then the URI-reference is a a
relative reference relative to the URI of the CoSWID tag.  For
example, "./folder/supplemental.coswid".
Paragraph (version A):
a URI with "swidpath:" as the scheme, which refers to another
CoSIWD via an XPATH query.  This URI would need to be resolved
in the context of the system entity via software components
that can lookup other CoSWID tags and select the appropriate
tag based on an XPATH query W3C.REC-xpath20-20101214.
Paragraph (version B):
a URI with "swidpath:" as the scheme, which refers to another
software tag via an XPATH query W3C.REC-xpath20-20101214.  This
scheme is provided for compatibility with SWID.  This
specification does not define how to resolve an XPATH query in
the context of CBOR.
Paragraph (version A):
ownership (index 39): An integer or textual value 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 section iana-
private-use).  Integer values in the range 0 to 255 correspond to
registered entries in the IANA "SWID/CoSWID Link Ownership Value"
registry (see section iana-link-ownership.  If a string value is
used it MUST be a private use name as defined in section iana-
private-use.  String values based on a Ownership Type Name from
the IANA "SWID/CoSWID Link Ownership Value" registry MUST NOT be
used, as these values are less concise than their index value
equivalent.
Paragraph (version A):
rel (index 40): An integer or textual value that 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 section iana-private-use).  Integer values in
the range 0 to 65535 correspond to registered entries in the IANA
"SWID/CoSWID Link Relationship Value" registry (see section iana-
link-rel.  If a string value is used it MUST be either a private
use name as defined in section 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 "SWID/CoSWID Link Relationship Value" registry
matches a Relation Name defined in the IANA "Link Relation Types"
registry, the index value in the IANA "SWID/CoSWID Link
Relationship Value" registry MUST be used instead, as this
relationship has a specialized meaning in the context of a SWID/
CoSWID tag.  String values based on a Relationship Type Name from
the IANA "SWID/CoSWID Link Relationship Value" registry MUST NOT
be used, as these values are less concise than their index value
equivalent.
Paragraph (version B):
ownership (index 39): An integer or textual value 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 Section iana-
private-use).  Integer values in the range 0 to 255 correspond to
registered entries in the IANA "Software Tag Link Ownership
Values" registry (see Section iana-link-ownership.  If a string
value is used it MUST be a private use name as defined in Section
iana-private-use.  String values based on a Ownership Type Name
from the IANA "Software Tag Link Ownership Values" registry MUST
NOT be used, as these values are less concise than their index
value equivalent.
Paragraph (version B):
rel (index 40): An integer or textual value that 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 Section 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 Section
iana-link-rel.  If a string value is used it MUST be either a
private use name as defined in Section 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 based on a Relationship Type Name from
the IANA "Software Tag Link Relationship Values" registry MUST NOT
be used, as these values are less concise than their index value
equivalent.
Paragraph (version A):
use (index 42): An integer or textual value used to determine if
the referenced software component has to be installed before
installing the software component identified by the COSWID tag.
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 section iana-
private-use).  Integer values in the range 0 to 255 correspond to
registered entries in the IANA "Link Use Value Value" registry
(see section iana-link-use.  If a string value is used it MUST be
a private use name as defined in section iana-private-use.  String
values based on an Link Use Type Name from the IANA "SWID/CoSWID
Link Use Value" registry MUST NOT be used, as these values are
less concise than their index value equivalent.
Paragraph (version B):
use (index 42): An integer or textual value used to determine if
the referenced software component has to be installed before
installing the software component identified by the COSWID tag.
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 Section iana-
private-use).  Integer values in the range 0 to 255 correspond to
registered entries in the IANA "Link Use Values" registry (see
Section iana-link-use.  If a string value is used it MUST be a
private use name as defined in Section iana-private-use.  String
values based on an Link Use Type Name from the IANA "Software Tag
Link Use Values" registry MUST NOT be used, as these values are
less concise than their index value equivalent.
Paragraph (version A):
channel-type (index 44): A textual value that identfies which
sales, licensing, or marketing channel the software component has
been targeted for (e.g.  Volume, Retail, OEM, Academic, etc).
This attribute is typically used in supplemental tags as it
contains information that might be selected during a specific
install.
Paragraph (version B):
channel-type (index 44): A textual value that identifies which
sales, licensing, or marketing channel the software component has
been targeted for (e.g.  Volume, Retail, OEM, Academic, etc).
This attribute is typically used in supplemental tags as it
contains information that might be selected during a specific
install.
Paragraph (version A):
unspsc-code (index 56): An 8 digit UNSPSC classification code for
the software component.  For more information see
https://www.unspsc.org/.
Paragraph (version B):
unspsc-code (index 56): An 8 digit UNSPSC classification code for
the software component as defined by the United Nations Standard
Products and Services Code (UNSPSC, UNSPSC).
Paragraph (version A):
CoSWID adds explicit support for the representation of hash entries
using algorithms that are registered in the IANA "Named Information
Hash Algorithm Registry" using the hash member (index 7) and the
corresponding hash-entry type.
Paragraph (version A):
The number used as a value for hash-alg-id MUST refer an ID in the
"Named Information Hash Algorithm Registry" (see
https://www.iana.org/assignments/named-information/named-
information.xhtml); other hash algorithms MUST NOT be used.  The
hash-value MUST represent the raw hash value of the hashed resource
generated using the hash algorithm indicated by the hash-alg-id.
Paragraph (version B):
CoSWID adds explicit support for the representation of hash entries
using algorithms that are registered in the IANA "Named Information
Hash Algorithm Registry" using the hash member (index 7) and the
corresponding hash-entry type.  This is the equivalent of the
namespace qualified "hash" attribute in SWID.
Paragraph (version B):
The number used as a value for hash-alg-id MUST refer an ID in the
"Named Information Hash Algorithm Registry" with a Status of
"current" (see https://www.iana.org/assignments/named-information/
named-information.xhtml); other hash algorithms MUST NOT be used.
The hash-value MUST represent the raw hash value of the hashed
resource generated using the hash algorithm indicated by the hash-
alg-id.
Paragraph (version A):
fs-name (index 24): The name of the directory or file without any
path information.
Paragraph (version B):
fs-name (index 24): The name of the directory or file without any
path information.  This aligns with a file "name" in SWID.
Paragraph (version A):
process-name (index 27): The software component's process name as
it will appear in an endpoint's process list.
Paragraph (version B):
process-name (index 27): The software component's process name as
it will appear in an endpoint's process list.  This aligns with a
process "name" in SWID.
Paragraph (version A):
The values above are registered in the IANA "SWID/CoSWID Version
Scheme Value" registry defined in section 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 used.
Paragraph (version B):
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):
"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 used.
Paragraph (version A):
The values above are registered in the IANA "SWID/CoSWID Entity Role
Value" registry defined in section iana-entity-role.  Additional
values will likely be registered over time.  Additionally, the index
values 128 through 255 and the name prefix "x_" have been reserved
for private use.
Paragraph (version B):
The values above are registered in the IANA "Software Tag Entity Role
Values" registry defined in Section iana-entity-role.  Additional
values will likely be registered over time.  Additionally, the index
values 128 through 255 and the name prefix "x_" have been reserved
for private use.
Paragraph (version A):
The values above are registered in the IANA "SWID/CoSWID Link
Ownership Value" registry defined in section iana-link-ownership.
Additional values will likely be registered over time.  Additionally,
the index values 128 through 255 and the name prefix "x_" have been
reserved for private use.
Paragraph (version B):
The values above are registered in the IANA "Software Tag Link
Ownership Values" registry defined in Section iana-link-ownership.
Additional values will likely be registered over time.  Additionally,
the index values 128 through 255 and the name prefix "x_" have been
reserved for private use.
Paragraph (version A):
The values above are registered in the IANA "SWID/CoSWID Link
Relationship Value" registry defined in section iana-link-rel.
Additional values will likely be registered over time.  Additionally,
the index values 32768 through 65535 and the name prefix "x_" have
been reserved for private use.
Paragraph (version B):
The values above are registered in the IANA "Software Tag Link
Relationship Values" registry defined in Section iana-link-rel.
Additional values will likely be registered over time.  Additionally,
the index values 32768 through 65535 and the name prefix "x_" have
been reserved for private use.
Paragraph (version A):
The values above are registered in the IANA "SWID/CoSWID Link Use
Value" registry defined in section iana-link-use.  Additional values
will likely be registered over time.  Additionally, the index values
128 through 255 and the name prefix "x_" have been reserved for
private use.
Paragraph (version B):
The values above are registered in the IANA "Software Tag Link Use
Values" registry defined in Section iana-link-use.  Additional values
will likely be registered over time.  Additionally, the index values
128 through 255 and the name prefix "x_" have been reserved for
private use.
Paragraph (version A):
The following registries allow for the registration of index values
and names.  New registrations will be permitted through either the
Standards Action policy or the Specification Required policy BCP26.
The latter SHOULD be used only for registrations requested by SDOs
outside the IETF.  New index values will be provided on a First Come
First Served as defined by BCP26.
Paragraph (version B):
The following registries allow for the registration of index values
and names.  New registrations will be permitted through either the
Standards Action policy or the Specification Required policy BCP26.
New index values will be provided on a First Come First Served as
defined by BCP26.
Paragraph (version A):
All registered names MUST be valid according to the XML Schema
NMTOKEN data type (see W3C.REC-xmlschema-2-20041028 section
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 "SWID/CoSWID 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 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 A):
Initial registrations for the "SWID/CoSWID Version Scheme Value"
registry are provided below, which are derived from the textual
version scheme names defined in SWID.
Paragraph (version B):
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 A):
Designated experts MUST also ensure that newly requested entries
define a value space for the corresponding version item that is
unique from other previously registered entries.  Note: The inital
registrations violate this requirement, but are included for
backwards compatibility with SWID.  Guidelines on how to deconflict
these value spaces are defined in section indexed-version-scheme.
Paragraph (version A):
This document establishes a new registry titled "SWID/CoSWID 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):
Designated experts MUST also ensure that newly requested entries
define a value space for the corresponding version item that is
unique from other previously registered entries.  Note: The initial
registrations violate this requirement, but are included for
backwards compatibility with SWID.  Guidelines on how to deconflict
these value spaces are defined in Section indexed-version-scheme.
Paragraph (version B):
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 A):
Initial registrations for the "SWID/CoSWID Entity Role Value"
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 "SWID/CoSWID 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):
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):
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 A):
Initial registrations for the "SWID/CoSWID Link Ownership Value"
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 "SWID/CoSWID 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):
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):
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 A):
Initial registrations for the "SWID/CoSWID Link Relationship Value"
registry are provided below, which are derived from the link
relationship values defined in SWID.
Paragraph (version A):
Designated experts MUST also ensure that a newly requested entry
documents the URI schemes allowed to be used in an href associated
with the link relationship and the expected resolution behavior of
these URI schemes.  This will help to ensure that SWID/CoSWID
applications are able to interoperate when resolving resources
referenced by a link of a given type.
Paragraph (version A):
This document establishes a new registry titled "SWID/CoSWID 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 "SWID/CoSWID Link Use Value" registry
are provided below, which are derived from the link relationship
values defined in SWID.
Paragraph (version B):
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):
Designated experts MUST also ensure that a newly requested entry
documents the URI schemes allowed to be used in an href associated
with the link relationship and the expected resolution behavior of
these URI schemes.  This will help to ensure that applications
processing software tags are able to interoperate when resolving
resources referenced by a link of a given type.
Paragraph (version B):
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):
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 A):
Fragment identifier considerations: Fragment identification for
application/swid+cbor is supported by using fragment identifiers as
specified by RFC-7049 section 7.5.
Paragraph (version B):
Fragment identifier considerations: Fragment identification for
application/swid+cbor is supported by using fragment identifiers as
specified by RFC7049 Section 7.5.
Paragraph (version A):
There is a need for a scheme name that can be used in URIs that point
to a specific SWID/CoSWID tag by that tag's tag-id, such as the use
of the link entry as described in section model-link) of this
document.  Since this scheme is used in a standards track document
and an ISO standard, this scheme needs to be used without fear of
conflicts with current or future actual schemes.  The scheme "swid"
is hereby registered as a 'permanent' scheme for that purpose.
Paragraph (version A):
Scheme semantics: URIs in the "swid" scheme are to be used to
reference a SWID or CoSWID tag by its tag-id.  A tag-id referenced in
this way can be used to indentify the tag resource in the context of
where it is referenced from.  For example, when a tag is installed on
a given device, that tag can reference related tags on the same
device using this URI scheme.
Paragraph (version B):
There is a need for a scheme name that can be used in URIs that point
to a specific software tag by that tag's tag-id, such as the use of
the link entry as described in Section model-link) of this document.
Since this scheme is used in a standards track document and an ISO
standard, this scheme needs to be used without fear of conflicts with
current or future actual schemes.  The scheme "swid" is hereby
registered as a 'permanent' scheme for that purpose.
Paragraph (version B):
Scheme semantics: URIs in the "swid" scheme are to be used to
reference a software tag by its tag-id.  A tag-id referenced in this
way can be used to identify the tag resource in the context of where
it is referenced from.  For example, when a tag is installed on a
given device, that tag can reference related tags on the same device
using this URI scheme.
Paragraph (version A):
There is a need for a scheme name that can be used in URIs to
indentify a collection of specific SWID/CoSWID tags with data
elements that match an XPath expression, such as the use of the link
entry as described in section model-link) of this document.  Since
this scheme is used in a standards track document and an ISO
standard, this scheme needs to be used without fear of conflicts with
current or future actual schemes.  The scheme "swidpath" is hereby
registered as a 'permanent' scheme for that purpose.
Paragraph (version A):
Scheme syntax: The scheme speific part consists of 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):
Scheme semantics: URIs in the "swidpath" scheme are to be used
specify the data that must be found in a given SWID/CoSWID tag for
that tag to be considered a matching tag to be included in the
identified tag collection.  Tags to be evaluated include all tags in
the context of where the tag is referenced from.  For example, when a
tag is installed on a given device, that tag can reference related
tags on the same device using this URI scheme.  A tag is matching if
the XPath evaluation result value has an effective boolean value of
"true" according to W3C.REC-xpath20-20101214 section 2.4.3.  rence
related tags on the same device using this URI scheme.
Paragraph (version B):
There is a need for a scheme name that can be used in URIs to
identify a collection of specific software tags with data elements
that match an XPath expression, such as the use of the link entry as
described in Section model-link) of this document.  Since this scheme
is used in a standards track document and an ISO standard, this
scheme needs to be used without fear of conflicts with current or
future actual schemes.  The scheme "swidpath" is hereby registered as
a 'permanent' scheme for that purpose.
Paragraph (version B):
Scheme syntax: The scheme specific part consists of 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 B):
Scheme semantics: URIs in the "swidpath" scheme are to be used
specify the data that must be found in a given software tag for that
tag to be considered a matching tag to be included in the identified
tag collection.  Tags to be evaluated include all tags in the context
of where the tag is referenced from.  For example, when a tag is
installed on a given device, that tag can reference related tags on
the same device using this URI scheme.  A tag is matching if the
XPath evaluation result value has an effective boolean value of
"true" according to W3C.REC-xpath20-20101214 Section 2.4.3.  rence
related tags on the same device using this URI scheme.
Paragraph (version A):
Where TAG_CREATOR_REGID is the reg-id ietm value of the tag's entity
item having the role value of 1 (corresponding to "tag creator"), and
the UNIQUE_ID is the same tag's tag-id item.  If the tag-id item's
value is expressed as a 16 byte binary string, the UNIQUE_ID MUST be
represented using the UUID string representation defined in RFC4122
including the "urn:uuid:" prefix.
Paragraph (version B):
Where TAG_CREATOR_REGID is the reg-id item value of the tag's entity
item having the role value of 1 (corresponding to "tag creator"), and
the UNIQUE_ID is the same tag's tag-id item.  If the tag-id item's
value is expressed as a 16 byte binary string, the UNIQUE_ID MUST be
represented using the UUID string representation defined in RFC4122
including the "urn:uuid:" prefix.
Paragraph (version A):
SWID and CoSWID tags contain public information about software
components and, as such, do not need to be protected against
disclosure on an endpoint.  Similarly, SWID/CoSWID tags are intended
to be easily discoverable by applications and users on an endpoint in
order to make it easy to identify and collect all of an endpoint's
SWID tags.  As such, any security considerations regarding SWID/
CoSWID tags focus on the application of SWID/CoSWID tags to address
security challenges, and the possible disclosure of the results of
those applications.
Paragraph (version A):
A tag is considered "authoritative" if the SWID/CoSWID tag was
created by the software provider.  An authoritative SWID/CoSWID tag
contains information about a software component provided by the
maintainer of the software component, who is expected to be an expert
in their own software.  Thus, authoritative SWID/CoSWID tags can be
trusted to represent authoritative information about the software
component.
Paragraph (version A):
A signed SWID/CoSWID tag (see appendix-cose) whose signature has been
validated can be relied upon to be unchanged since it was signed.  By
contrast, the data contained in unsigned tags cannot be trusted to be
unmodified.
Paragraph (version A):
When an authoritative tag is signed, the software provider can be
authenticated as the originator of the signature.  Having a signed
authoritative SWID/CoSWID tag can be useful when the information in
the tag needs to be trusted, such as when the tag is being used to
convey reference integrity measurements for software components.
Paragraph (version A):
SWID/CoSWID tags are designed to be easily added and removed from an
endpoint along with the installation or removal of software
components.  On endpoints where addition or removal of software
components is tightly controlled, the addition or removal of SWID
tags can be similarly controlled.  On more open systems, where many
users can manage the software inventory, SWID/CoSWID tags can be
easier to add or remove.  On such systems, it can be possible to add
or remove SWID/CoSWID tags in a way that does not reflect the actual
presence or absence of corresponding software components.  Similarly,
not all software products automatically install SWID/CoSWID tags, so
products can be present on an endpoint without providing a
corresponding SWID tag.  As such, any collection of SWID/CoSWID tags
cannot automatically be assumed to represent either a complete or
fully accurate representation of the software inventory of the
endpoint.  However, especially on endpoint devices that more strictly
control the ability to add or remove applications, SWID/CoSWID tags
are an easy way to provide an preliminary understanding of that
endpoint's software inventory.
Paragraph (version A):
Any report of an endpoint's SWID/CoSWID tag collection provides
information about the software inventory of that endpoint.  If such a
report is exposed to an attacker, this can tell them which software
products and versions thereof are present on the endpoint.  By
examining this list, the attacker might learn of the presence of
applications that are vulnerable to certain types of attacks.  As
noted earlier, SWID/CoSWID tags are designed to be easily
discoverable by an endpoint, but this does not present a significant
risk since an attacker would already need to have access to the
endpoint to view that information.  However, when the endpoint
transmits its software inventory to another party, or that inventory
is stored on a server for later analysis, this can potentially expose
this information to attackers who do not yet have access to the
endpoint.  For this reason, it is important to protect the
confidentiality of SWID/CoSWID tag information that has been
collected from an endpoint, not because those tags individually
contain sensitive information, but because the collection of SWID/
CoSWID tags and their association with an endpoint reveals
information about that endpoint's attack surface.
Paragraph (version A):
Finally, both the ISO-19770-2:2015 XML schema SWID definition and the
CoSWID CDDL specification allow for the construction of "infinite"
tags with link item loops or tags that contain malicious content with
the intent of creating non-deterministic states during validation or
processing of those tags.  While software providers are unlikely to
do this, SWID/CoSWID tags can be created by any party and the SWID/
CoSWID tags collected from an endpoint could contain a mixture of
vendor and non-vendor created tags.  For this reason, tools that
consume SWID/CoSWID tags ought to treat the tag contents as
potentially malicious and employ input sanitizing and loop detection
on the tags they ingest.
Paragraph (version B):
CoSWID tags contain public information about software components and,
as such, do not need to be protected against disclosure on an
endpoint.  Similarly, CoSWID tags are intended to be easily
discoverable by applications and users on an endpoint in order to
make it easy to identify and collect all of an endpoint's SWID tags.
As such, any security considerations regarding CoSWID tags focus on
the application of CoSWID tags to address security challenges, and
the possible disclosure of the results of those applications.
Paragraph (version B):
A tag is considered "authoritative" if the CoSWID tag was created by
the software provider.  An authoritative CoSWID tag contains
information about a software component provided by the maintainer of
the software component, who is expected to be an expert in their own
software.  Thus, authoritative CoSWID tags can be trusted to
represent authoritative information about the software component.
Paragraph (version B):
A signed CoSWID tag (see appendix-cose) whose signature has been
validated can be relied upon to be unchanged since it was signed.  By
contrast, the data contained in unsigned tags cannot be trusted to be
unmodified.
Paragraph (version B):
When an authoritative tag is signed, the software provider can be
authenticated as the originator of the signature.  A trustworthy
association between the signature and the originator of the signature
can be established via trust anchors.  A certification path between a
trust anchor and a certificate including a pub-key enabling the
validation of a tag signature can realize the assessment of
trustworthiness of an authoritative tag.  Having a signed
authoritative CoSWID tag can be useful when the information in the
tag needs to be trusted, such as when the tag is being used to convey
reference integrity measurements for software components.
Paragraph (version B):
CoSWID tags are designed to be easily added and removed from an
endpoint along with the installation or removal of software
components.  On endpoints where addition or removal of software
components is tightly controlled, the addition or removal of SWID
tags can be similarly controlled.  On more open systems, where many
users can manage the software inventory, CoSWID tags can be easier to
add or remove.  On such systems, it can be possible to add or remove
CoSWID tags in a way that does not reflect the actual presence or
absence of corresponding software components.  Similarly, not all
software products automatically install CoSWID tags, so products can
be present on an endpoint without providing a corresponding SWID tag.
As such, any collection of CoSWID tags cannot automatically be
assumed to represent either a complete or fully accurate
representation of the software inventory of the endpoint.  However,
especially on endpoint devices that more strictly control the ability
to add or remove applications, CoSWID tags are an easy way to provide
an preliminary understanding of that endpoint's software inventory.
Paragraph (version B):
Any report of an endpoint's CoSWID tag collection provides
information about the software inventory of that endpoint.  If such a
report is exposed to an attacker, this can tell them which software
products and versions thereof are present on the endpoint.  By
examining this list, the attacker might learn of the presence of
applications that are vulnerable to certain types of attacks.  As
noted earlier, CoSWID tags are designed to be easily discoverable by
an endpoint, but this does not present a significant risk since an
attacker would already need to have access to the endpoint to view
that information.  However, when the endpoint transmits its software
inventory to another party, or that inventory is stored on a server
for later analysis, this can potentially expose this information to
attackers who do not yet have access to the endpoint.  For this
reason, it is important to protect the confidentiality of CoSWID tag
information that has been collected from an endpoint in transit and
at rest, not because those tags individually contain sensitive
information, but because the collection of CoSWID tags and their
association with an endpoint reveals information about that
endpoint's attack surface.
Paragraph (version B):
Finally, both the ISO-19770-2:2015 XML schema SWID definition and the
CoSWID CDDL specification allow for the construction of "infinite"
tags with link item loops or tags that contain malicious content with
the intent of creating non-deterministic states during validation or
processing of those tags.  While software providers are unlikely to
do this, CoSWID tags can be created by any party and the CoSWID tags
collected from an endpoint could contain a mixture of vendor and non-
vendor created tags.  For this reason, a CoSWID tag might contain
potentially malicious content.  Input sanitization and loop detection
are two ways that implementations can address this concern.