Draft: draft-ietf-sacm-coswid

Commentary: this is missing an answer to " Can the tag - id be a digest of the source file ? " , which requires a reply to the list
Paragraph (version A):
Supplemental Tag - A SWID or CoSWID tag that allows additional
information to be associated with a referenced SWID tag.  This
allows tools and users to record their own metadata about a
software component without modifying SWID primary or patch tags
created by a software provider.
Paragraph (version B):
Supplemental Tag - A SWID or CoSWID tag that allows additional
information to be associated with a referenced SWID tag.  This
allows tools and users to record their own metadata about a
software component without modifying CoSWID primary or patch tags
created by a software provider.
Paragraph (version A):
tag-id (index 0): A 16 byte binary string or textual identifier
uniquely referencing a software component.  The tag identifier
MUST be globally unique.  If represented as a 16 byte binary
string, the identifier MUST be a valid universally unique
identifier as defined by RFC4122.  There are no strict guidelines
on how this identifier is structured, but examples include a 16
byte GUID (e.g.  class 4 UUID) RFC4122, or a text string appended
to a DNS domain name to ensure uniqueness across organizations.
Paragraph (version B):
tag-id (index 0): A 16 byte binary string or textual identifier
uniquely referencing a software component.  The tag identifier
MUST be globally unique.  Failure to ensure global uniqueness can
create ambiguity in tag use since the tag-id serves as the global
key for matching and lookups.  If represented as a 16 byte binary
string, the identifier MUST be a valid universally unique
identifier as defined by RFC4122.  There are no strict guidelines
on how this identifier is structured, but examples include a 16
byte GUID (e.g.  class 4 UUID) RFC4122, or a text string appended
to a DNS domain name to ensure uniqueness across organizations.
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 a registration ID
MUST be a RFC 3986 URI.  The scope SHOULD be the scope of an
organization.
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 will usually be the scope of an
organization.
Paragraph (version A):
media (index 10): A hint to the consumer of the link to what
target platform the link is applicable to.  This item represents a
query as defined by the W3C Media Queries Recommendation (see
W3C.REC-css3-mediaqueries-20120619).  See also media defined in
model-concise-swid-tag.
Paragraph (version B):
media (index 10): A hint to the consumer of the link to what
target platform the link is applicable to.  This item represents a
query as defined by the W3C Media Queries Recommendation (see
W3C.REC-css3-mediaqueries-20120619).  As highlighted in media
defined in model-concise-swid-tag, 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):
The hash-value byte string 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):
The hash-value MUST represent the raw hash value in byte
representation (in contrast to, e.g., base64 encoded byte
representation) of the byte string that represents the hashed
resource generated using the hash algorithm indicated by the hash-
alg-id.
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.  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 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.  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 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.  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 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.  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 iana-link-use.  Additional values will
likely be registered over time.
Paragraph (version A):
This XPath is evaluated over 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):
This XPath is evaluated over SWID or CoSWID 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):
Loss of control of signing credentials used to sign CoSWID tags would
create doubt about the authenticity and integrity of any CoSWID tags
signed using the compromised keys.  In such cases, the legitimate tag
signer (namely, the software provider for an authoritative CoSWID
tag) can employ uncompromised signing credentials to create a new
signature on the original tag.  The tag version number would not be
incremented since the tag itself was not modified.  Consumers of
CoSWID tags would need to validate the tag using the new credentials
and would also need to revoke certificates associated with the
compromised credentials to avoid validating tags signed with them.
The process for doing this is beyond the scope of this specification.
Paragraph (version A):
CoSWID tags are intended to be easily discoverable by authorized
applications and users on an endpoint in order to make it easy to
determine the tagged software load.  Access to the collection of an
endpoint's SWID tags needs to be appropriately controlled to
authorized applications and users using an appropriate access control
mechanism.
Paragraph (version A):
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):
CoSWID tags are intended to be easily discoverable by authorized
applications and users on an endpoint in order to make it easy to
determine the tagged software load.  Access to the collection of an
endpoint's CoSWID tags needs to be appropriately controlled to
authorized applications and users using an appropriate access control
mechanism.
Paragraph (version B):
Since the tag-id of a CoSWID tag can be used as a global index value,
failure to ensure the tag-id's uniqueness can cause collisions or
ambiguity in CoSWID tags that are retrieved or processed using this
identifier.  CoSWID is designed to not require a registry of
identifiers.  As a result, CoSWID requires the tag creator employ a
method of generating a unique tag identifier.  Specific methods of
generating a unique identifier are beyond the scope of this
specification.  A collision in tag-ids may result in false positives/
negatives in software integrity checks or mis-identification of
installed software, undermining CoSWID use cases such as
vulnerability identification, software inventory, etc.  If such a
collision is detected, then the tag consumer should contact the
maintainer of the CoSWID to have them issue a correction addressing
the collision.
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 CoSWID
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 CoSWID
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
a preliminary understanding of that endpoint's software inventory.
Paragraph (version B):
As noted in sec-sec, collected information about an endpoint's
software load, such as what might be represented by an endpoint's
CoSWID tag collection, could be used to identify vulnerable software
for attack.  Collections of endpoint software information also can
have privacy implications for users.  The set of application a user
installs can give clues to personal matters such as political
affiliation, banking and investments, gender, sexual orientation,
medical concerns, etc.  While the collection of CoSWID tags on an
endpoint wouldn't increase the privacy risk (since a party able to
view those tags could also view the applications themselves), if
those CoSWID tags are gathered and stored in a repository somewhere,
visibility into the repository now also gives visibility into a
user's application collection.  For this reason, repositories of
collected CoSWID tags not only need to be protected against
collection by malicious parties, but even authorized parties will
need to be vetted and made aware of privacy responsibilities
associated with having access to this information.  Likewise, users
should be made aware that their software inventories are being
collected from endpoints.  Furthermore, when collected and stored by
authorized parties or systems, the inventory data needs to be
protected as both security and privacy sensitive information.