Draft: draft-ietf-sacm-coswid

Commentary: This PR addresses a portion of the feedback provided by Roman . This is currently a work in progress and should not be merged while the PR is marked as draft . 
 In the CDDL , is defined as : but the textual description that follows allows negative values ( for testing and use in closed environments ) . So I guess it should instead say : or even 
 Thank you ! ' $    .. / text ' sounds fine . Will be included in the next proposal . 
 I fixed this in PR . 
 There is no description of the entry in the group ( Section 2.9.2 ) . Also the CDDL in the same section does not define the code point . It is probably better to keep all the relevant bits tightly packed . 
 It is described in 2.9.1 just before resource - collection . This includes the " code point " and the definition of index 7 . Is your proposal to merge 2.9.1 into 2.9.2 ? At the moment , I think being next to each other could satisfy the requirement of " relevant bits are tightly packed " . 
 Currently the full information about hash is spread across three different sections - 2.9.1 , 2.9.2 and 2.10 . Yep , and also copy from 2.10 into the " scoped " CDDL . This is by no means a blocker or anything of that sort . It 's just a suggestion to make the document more easily consumable . When I implemented it , I was going through each section and build the encoder / decoder from the description , and it all went great until I hit section 2.9.1 :-) 
 Well ... it 's hard to argue with that :-) It 's now on the list for the next authors meeting ! 
 I consolidated the hash information into the specific section in PR .
Paragraph (version B):
These cases are specifically noted in this and subsequent sections
using an W3C.REC-xpath20-20101214 where a manual mapping is needed.
Paragraph (version A):
software-name (index 1): This textual item provides the software
component's name.  This name is likely the same name that would
appear in a package management tool.
Paragraph (version A):
software-version (index 13): A textual value representing the
specific release or development version of the software component.
Paragraph (version B):
software-name (index 1): This textual item provides the software
component's name.  This name is likely the same name that would
appear in a package management tool.  This item maps to
'/SoftwareIdentity/@name' in SWID.
Paragraph (version B):
software-version (index 13): A textual value representing the
specific release or development version of the software component.
This item maps to '/SoftwareIdentity/@version' in SWID.
Paragraph (version A):
software-meta (index 5): An open-ended map of key/value data
pairs.  A number of predefined keys can be used within this item
providing for common usage and semantics across the industry.  Use
of this map allows any additional attribute to be included in the
tag.  It is expected that industry groups will use a common set of
attribute names to allow for interoperability within their
communities.  Described in model-software-meta.
Paragraph (version B):
software-meta (index 5): An open-ended map of key/value data
pairs.  A number of predefined keys can be used within this item
providing for common usage and semantics across the industry.  Use
of this map allows any additional attribute to be included in the
tag.  It is expected that industry groups will use a common set of
attribute names to allow for interoperability within their
communities.  Described in model-software-meta.  This item maps to
'/SoftwareIdentity/Meta' in SWID.
Paragraph (version A):
evidence-entry (index 3): This item can be used to record the
results of a software discovery process used to identify untagged
software on an endpoint or to represent indicators for why
software is believed to be installed on the endpoint.  In either
case, a CoSWID tag can be created by the tool performing an
analysis of the software components installed on the endpoint.
Described in model-evidence.
Paragraph (version B):
evidence (index 3): This item can be used to record the results of
a software discovery process used to identify untagged software on
an endpoint or to represent indicators for why software is
believed to be installed on the endpoint.  In either case, a
CoSWID tag can be created by the tool performing an analysis of
the software components installed on the endpoint.  Described in
model-evidence.
Paragraph (version A):
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):
entity-name (index 31): The textual name of the organizational
entity claiming the roles specified by the role item for the
CoSWID tag.  This item maps to '/SoftwareIdentity/Entity/@name' in
SWID.
Paragraph (version A):
thumbprint (index 34): The value of the thumbprint item provides
an integer-based hash algorithm identifier (hash-alg-id) and a
byte string value (hash-value) that contains the corresponding
hash value (i.e. the thumbprint) of the signing entity's public
key certificate.  This provides an indicator of which entity
signed the CoSWID tag, which will typically be the tag creator.
If the hash-alg-id is not known, then the integer value "0" MUST
be used.  This ensures parity between the SWID tag specification
SWID, which does not allow an algorithm to be identified for this
field.  See model-hash-entry for more details on the use of the
hash-entry data structure.
Paragraph (version B):
thumbprint (index 34): The value of the thumbprint item provides a
hash (i.e. the thumbprint) of the signing entity's public key
certificate.  This provides an indicator of which entity signed
the CoSWID tag, which will typically be the tag creator.  See
model-hash-entry for more details on the use of the hash-entry
data structure.
Paragraph (version A):
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 B):
If no URI scheme is provided, then the URI-reference is a
relative reference relative to the URI of the CoSWID tag.  For
example, "./folder/supplemental.coswid".
Paragraph (version A):
media-type (index 41): A link can point to arbitrary resources on
the endpoint, local network, or Internet using the href item.  Use
of this item supplies the resource consumer with a hint of what
type of resource to expect.  Media types are identified by
referencing a "Name" from the IANA "Media Types" registry:
http://www.iana.org/assignments/media-types/media-types.xhtml.
Paragraph (version B):
media-type (index 41): A link can point to arbitrary resources on
the endpoint, local network, or Internet using the href item.  Use
of this item supplies the resource consumer with a hint of what
type of resource to expect.  Media types are identified by
referencing a "Name" from the IANA "Media Types" registry:
http://www.iana.org/assignments/media-types/media-types.xhtml.
This item maps to '/SoftwareIdentity/Link/@type' in SWID.
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.  This is the equivalent of the
namespace qualified "hash" attribute in SWID.
Paragraph (version A):
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 B):
CoSWID adds explicit support for the representation of hash entries
using algorithms that are registered in the IANA "Named Information
Hash Algorithm Registry" NIHAR 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 is an integer-based hash
algorithm identifier who's value MUST refer to an ID in the IANA
"Named Information Hash Algorithm Registry" NIHAR with a Status of
"current"; other hash algorithms MUST NOT be used.  If the hash-alg-
id is not known, then the integer value "0" MUST be used.  This
ensures parity between the SWID tag specification SWID, which does
not allow an algorithm to be identified for this field.
Paragraph (version B):
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 A):
file-version (index 21): The file's version as reported by
querying information on the file from the operating system.
Paragraph (version B):
file-version (index 21): The file's version as reported by
querying information on the file from the operating system.  This
item maps to '/SoftwareIdentity/(Payload|Evidence)/File/@version'
in SWID.
Paragraph (version B):
hash (index 7): A hash of the file as described in model-hash-
entry.
Paragraph (version A):
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 B):
fs-name (index 24): The name of the directory or file without any
path information.  This aligns with a file "name" in SWID.  This
item maps to
'/SoftwareIdentity/(Payload|Evidence)/(File|Directory)/@name' in
SWID.
Paragraph (version A):
path-elements (index 26): This group allows a hierarchy of
directory and file items to be defined in payload or evidence
items.
Paragraph (version A):
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 B):
path-elements (index 26): This group allows a hierarchy of
directory and file items to be defined in payload or evidence
items.  This is a construction within the CDDL definition of
CoSWID to support shared syntax and does not appear in SWID.
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.  This item maps to
'/SoftwareIdentity/(Payload|Evidence)/Process/@name' in SWID.
Paragraph (version B):
This specification defines the following URI schemes for use in
CoSWID and to provide interoperability with schemes used in {SWID}.
Paragraph (version B):
Note: These schemes are used in {SWID} without an IANA registration.
This specification ensures that these schemes are properly defined
going forward.
Paragraph (version B):
URIs specifying the "swid" scheme are 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 URIs with
this scheme.
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 Section 2.1.
Paragraph (version B):
URIs specifying the "swidpath" scheme are used to reference 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 a URI with this scheme.
Paragraph (version B):
For URIs that use the "swidpath" scheme, the requirements apply.
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 Section 2.1.
Paragraph (version B):
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):
Applications/protocols that use this scheme name: See section
schemes-swid.
Paragraph (version A):
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 B):
Applications/protocols that use this scheme name: See section
schemes-swidpath.
Paragraph (version A):
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 A):
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):
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):
CoSWID tags are intended to contain public information about software
components and, as such, the contents of a CoSWID tag does not need
to be protected against unintended disclosure on an endpoint.
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 SWID tags needs to be appropriately controlled to
authorized applications and users using an appropriate access control
mechanism.