draft-ietf-sacm-coswid-07.txt   draft-ietf-sacm-coswid-08.txt 
SACM Working Group H. Birkholz SACM Working Group H. Birkholz
Internet-Draft Fraunhofer SIT Internet-Draft Fraunhofer SIT
Intended status: Standards Track J. Fitzgerald-McKay Intended status: Standards Track J. Fitzgerald-McKay
Expires: April 26, 2019 Department of Defense Expires: May 12, 2019 Department of Defense
C. Schmidt C. Schmidt
The MITRE Corporation The MITRE Corporation
D. Waltermire D. Waltermire
NIST NIST
October 23, 2018 November 08, 2018
Concise Software Identifiers Concise Software Identifiers
draft-ietf-sacm-coswid-07 draft-ietf-sacm-coswid-08
Abstract Abstract
This document defines a concise representation of ISO/IEC This document defines a concise representation of ISO/IEC
19770-2:2015 Software Identification (SWID) tags that are 19770-2:2015 Software Identification (SWID) tags that are
interoperable with the XML schema definition of ISO/IEC 19770-2:2015 interoperable with the XML schema definition of ISO/IEC 19770-2:2015
and augmented for application in Constrained-Node Networks. Next to and augmented for application in Constrained-Node Networks. Next to
the inherent capability of SWID tags to express arbitrary context the inherent capability of SWID tags to express arbitrary context
information, Concise SWID (CoSWID) tags support the definition of information, Concise SWID (CoSWID) tags support the definition of
additional semantics via well-defined data definitions incorporated additional semantics via well-defined data definitions incorporated
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2019. This Internet-Draft will expire on May 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The SWID Tag Lifecycle . . . . . . . . . . . . . . . . . 4 1.1. The SWID Tag Lifecycle . . . . . . . . . . . . . . . . . 4
1.2. Concise SWID Extensions . . . . . . . . . . . . . . . . . 6 1.2. Concise SWID Extensions . . . . . . . . . . . . . . . . . 6
1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 7 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 7
2. Concise SWID Data Definition . . . . . . . . . . . . . . . . 7 2. Concise SWID Data Definition . . . . . . . . . . . . . . . . 7
2.1. The concise-software-identity Object . . . . . . . . . . 8 2.1. The concise-software-identity Object . . . . . . . . . . 8
2.1.1. Determining the tag type . . . . . . . . . . . . . . 11 2.1.1. Determining the tag type . . . . . . . . . . . . . . 12
2.1.2. concise-software-identity Co-constraints . . . . . . 12 2.1.2. concise-software-identity Co-constraints . . . . . . 12
2.2. The global-attributes Group . . . . . . . . . . . . . . . 12 2.2. The global-attributes Group . . . . . . . . . . . . . . . 13
2.3. The any-element-map Entry . . . . . . . . . . . . . . . . 13 2.3. The media Object . . . . . . . . . . . . . . . . . . . . 13
2.4. The entity Object . . . . . . . . . . . . . . . . . . . . 13 2.4. The entity Object . . . . . . . . . . . . . . . . . . . . 14
2.5. The link Object . . . . . . . . . . . . . . . . . . . . . 14 2.5. The link Object . . . . . . . . . . . . . . . . . . . . . 15
2.6. The software-meta Object . . . . . . . . . . . . . . . . 16 2.6. The software-meta Object . . . . . . . . . . . . . . . . 17
2.7. The Resource Collection Definition . . . . . . . . . . . 19 2.7. The Resource Collection Definition . . . . . . . . . . . 19
2.7.1. The hash-entry Array . . . . . . . . . . . . . . . . 19 2.7.1. The hash-entry Array . . . . . . . . . . . . . . . . 19
2.7.2. The resource-collection Group . . . . . . . . . . . . 20 2.7.2. The resource-collection Group . . . . . . . . . . . . 20
2.7.3. The payload Object . . . . . . . . . . . . . . . . . 22 2.7.3. The payload Object . . . . . . . . . . . . . . . . . 23
2.7.4. The evidence Object . . . . . . . . . . . . . . . . . 23 2.7.4. The evidence Object . . . . . . . . . . . . . . . . . 23
2.8. Full CDDL Definition . . . . . . . . . . . . . . . . . . 24 2.8. Full CDDL Definition . . . . . . . . . . . . . . . . . . 24
3. CoSWID Indexed Label Values . . . . . . . . . . . . . . . . . 29 3. CoSWID Indexed Label Values . . . . . . . . . . . . . . . . . 29
3.1. Version Scheme . . . . . . . . . . . . . . . . . . . . . 29 3.1. Version Scheme . . . . . . . . . . . . . . . . . . . . . 29
3.2. Entity Role Values . . . . . . . . . . . . . . . . . . . 29 3.2. Entity Role Values . . . . . . . . . . . . . . . . . . . 30
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 3.3. Use Values . . . . . . . . . . . . . . . . . . . . . . . 30
4.1. SWID/CoSWID Version Schema Values Registry . . . . . . . 30 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
4.2. SWID/CoSWID Entity Role Values Registry . . . . . . . . . 31 4.1. SWID/CoSWID Version Schema Values Registry . . . . . . . 31
4.3. Media Type Registration . . . . . . . . . . . . . . . . . 32 4.2. SWID/CoSWID Entity Role Values Registry . . . . . . . . . 32
4.3.1. swid+cbor Media Type Registration . . . . . . . . . . 32 4.3. SWID/CoSWID Link Use Values Registry . . . . . . . . . . 33
4.4. CoAP Content-Format Registration . . . . . . . . . . . . 33 4.4. Media Type Registration . . . . . . . . . . . . . . . . . 34
4.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 34 4.4.1. swid+cbor Media Type Registration . . . . . . . . . . 34
5. Security Considerations . . . . . . . . . . . . . . . . . . . 34 4.5. CoAP Content-Format Registration . . . . . . . . . . . . 35
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 4.6. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 36
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 36 5. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Normative References . . . . . . . . . . . . . . . . . . 39 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41
9.2. Informative References . . . . . . . . . . . . . . . . . 40 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.1. Normative References . . . . . . . . . . . . . . . . . . 41
Appendix A. CoSWID Attributes for Firmware (label 60) . . . . . 41 9.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix B. Signed Concise SWID Tags using COSE . . . . . . . . 44 Appendix A. CoSWID Attributes for Firmware (label 60) . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Appendix B. Signed Concise SWID Tags using COSE . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
SWID tags have several use-applications including but not limited to: SWID tags have several use-applications including but not limited to:
o Software Inventory Management, a part of the Software Asset o Software Inventory Management, a part of a Software Asset
Management [SAM] process, which requires an accurate list of Management [SAM] process, which requires an accurate list of
discernible deployed software components. discernible deployed software components.
o Vulnerability Assessment, which requires a semantic link between o Vulnerability Assessment, which requires a semantic link between
standardized vulnerability descriptions and software components standardized vulnerability descriptions and software components
installed on IT-assets [X.1520]. installed on IT-assets [X.1520].
o Remote Attestation, which requires a link between reference o Remote Attestation, which requires a link between reference
integrity measurements (RIM) and security logs of measured integrity measurements (RIM) and security logs of measured
software components [I-D.birkholz-tuda]. software components [I-D.birkholz-tuda].
skipping to change at page 3, line 44 skipping to change at page 3, line 45
optional fields that support different use scenarios. While a SWID optional fields that support different use scenarios. While a SWID
tag consisting of only required fields might be a few hundred bytes tag consisting of only required fields might be a few hundred bytes
in size, a tag containing many of the optional fields can be many in size, a tag containing many of the optional fields can be many
orders of magnitude larger. Thus, real-world instances of SWID tags orders of magnitude larger. Thus, real-world instances of SWID tags
can be fairly large, and the communication of SWID tags in use- can be fairly large, and the communication of SWID tags in use-
applications such as those described earlier can cause a large amount applications such as those described earlier can cause a large amount
of data to be transported. This can be larger than acceptable for of data to be transported. This can be larger than acceptable for
constrained devices and networks. Concise SWID (CoSWID) tags constrained devices and networks. Concise SWID (CoSWID) tags
significantly reduce the amount of data transported as compared to a significantly reduce the amount of data transported as compared to a
typical SWID tag. This reduction is enabled through the use of CBOR, typical SWID tag. This reduction is enabled through the use of CBOR,
which maps human-readable labels of that content to more concise which maps the human-readable labels of SWID data to more concise
integer labels (indices). The use of CBOR to express SWID integer labels (indices). The use of CBOR to express SWID
information in CoSWID tags allows both CoSWID and SWID tags to be information in CoSWID tags allows both CoSWID and SWID tags to be
part of an enterprise security solution for a wider range of part of an enterprise security solution for a wider range of
endpoints and environments. endpoints and environments.
1.1. The SWID Tag Lifecycle 1.1. The SWID Tag Lifecycle
In addition to defining the format of a SWID tag record, ISO/IEC In addition to defining the format of a SWID tag record, ISO/IEC
19770-2:2015 defines requirements concerning the SWID tag lifecycle. 19770-2:2015 defines requirements concerning the SWID tag lifecycle.
Specifically, when a software component is installed on an endpoint, Specifically, when a software component is installed on an endpoint,
that product's SWID tag is also installed. Likewise, when the that software component's SWID tag is also installed. Likewise, when
product is uninstalled or replaced, the SWID tag is deleted or the software component is uninstalled or replaced, the SWID tag is
replaced, as appropriate. As a result, ISO/IEC 19770-2:2015 deleted or replaced, as appropriate. As a result, ISO/IEC
describes a system wherein there is a correspondence between the set 19770-2:2015 describes a system wherein there is a correspondence
of installed software components on an endpoint, and the presence of between the set of installed software components on an endpoint, and
the correspondingsponding SWID tags for these components on that the presence of the corresponding SWID tags for these components on
endpoint. CoSWIDs share the same lifecycle requirements as a SWID that endpoint. CoSWIDs share the same lifecycle requirements as a
tag. SWID tag.
The following is an excerpt (with some modifications and reordering) The following is an excerpt (with some modifications and reordering)
from NIST Interagency Report (NISTIR) 8060: Guidelines for the from NIST Interagency Report (NISTIR) 8060: Guidelines for the
Creation of Interoperable SWID Tags [SWID-GUIDANCE], which describes Creation of Interoperable SWID Tags [SWID-GUIDANCE], which describes
the tag types used within the lifecycle defined in ISO-19770-2:2015. the tag types used within the lifecycle defined in ISO-19770-2:2015.
This information is included here to provide a concise reference for
the use of CoSWIDs in the software lifecycle.
The SWID specification defines four types of SWID tags: primary, The SWID specification defines four types of SWID tags: primary,
patch, corpus, and supplemental. patch, corpus, and supplemental.
1. Primary Tag - A SWID or CoSWID tag that identifies and describes 1. Primary Tag - A SWID or CoSWID tag that identifies and describes
a software component is installed on a computing device. a software component is installed on a computing device. A
primary tag is intended to be installed on an endpoint along with
the corresponding software component.
2. Patch Tag - A SWID or CoSWID tag that identifies and describes an 2. Patch Tag - A SWID or CoSWID tag that identifies and describes an
installed patch which has made incremental changes to a software installed patch which has made incremental changes to a software
component installed on a computing device. component installed on an endpoint. A patch tag is intended to
be installed on an endpoint along with the corresponding software
component patch.
3. Corpus Tag - A SWID or CoSWID tag that identifies and describes 3. Corpus Tag - A SWID or CoSWID tag that identifies and describes
an installable software component in its pre-installation state. an installable software component in its pre-installation state.
A corpus tag can be used to represent metadata about an A corpus tag can be used to represent metadata about an
installation package or installer for a software component, a installation package or installer for a software component, a
software update, or a patch. software update, or a patch.
4. Supplemental Tag - A SWID or CoSWID tag that allows additional 4. Supplemental Tag - A SWID or CoSWID tag that allows additional
information to be associated with a referenced SWID tag. This information to be associated with a referenced SWID tag. This
helps to ensure that SWID Primary and Patch Tags provided by a helps to ensure that SWID Primary and Patch Tags provided by a
software provider are not modified by software management tools, software provider are not modified by software management tools,
while allowing these tools to provide their own software while allowing these tools to provide their own software
metadata. metadata.
Note: The type of a tag is determined by specific data elements,
which is discussed in Section 2.1.1.
Corpus, primary, and patch tags have similar functions in that Corpus, primary, and patch tags have similar functions in that
they describe the existence and/or presence of different types of they describe the existence and/or presence of different types of
software (e.g., software installers, software installations, software (e.g., software installers, software installations,
software patches), and, potentially, different states of software software patches), and, potentially, different states of software
components. In contrast, supplemental tags furnish additional components. In contrast, supplemental tags furnish additional
information not contained in corpus, primary, or patch tags. All information not contained in corpus, primary, or patch tags. All
four tag types come into play at various points in the software four tag types come into play at various points in the software
lifecycle, and support software management processes that depend lifecycle, and support software management processes that depend
on the ability to accurately determine where each software on the ability to accurately determine where each software
component is in its lifecycle. component is in its lifecycle.
skipping to change at page 6, line 33 skipping to change at page 6, line 42
Each of the different SWID and CoSWID tag types provide different Each of the different SWID and CoSWID tag types provide different
sets of information. For example, a "corpus tag" is used to describe sets of information. For example, a "corpus tag" is used to describe
a software component's installation image on an installation media, a software component's installation image on an installation media,
while a "patch tag" is meant to describe a patch that modifies some while a "patch tag" is meant to describe a patch that modifies some
other software component. other software component.
1.2. Concise SWID Extensions 1.2. Concise SWID Extensions
This document defines the CoSWID format, a more concise This document defines the CoSWID format, a more concise
representation of SWID information in the Concise Binary Object representation of SWID information in the Concise Binary Object
Representation (CBOR) [RFC7049]. This is described via the Concise Representation (CBOR) [RFC7049]. The structure of a CoSWID is
Data Definition Language (CDDL) [I-D.ietf-cbor-cddl]. The resulting described via the Concise Data Definition Language (CDDL)
CoSWID data definition is interoperable with the XML schema [I-D.ietf-cbor-cddl]. The resulting CoSWID data definition is
aligned in the information able to be expressed with the XML schema
definition of ISO-19770-2:2015 [SWID]. The vocabulary, i.e., the definition of ISO-19770-2:2015 [SWID]. The vocabulary, i.e., the
CDDL names of the types and members used in the CoSWID data CDDL names of the types and members used in the CoSWID data
definition, are mapped to more concise labels represented as small definition, are mapped to more concise labels represented as small
integer values. The names used in the CDDL data definition and the integer values. The names used in the CDDL data definition and the
mapping to the CBOR representation using integer labels is based on mapping to the CBOR representation using integer labels is based on
the vocabulary of the XML attribute and element names defined in ISO/ the vocabulary of the XML attribute and element names defined in ISO/
IEC 19770-2:2015. IEC 19770-2:2015.
The corresponding CoSWID data definition includes two kinds of The corresponding CoSWID data definition includes two kinds of
augmentation. augmentation.
o The explicit definition of types for attributes that are typically o The explicit definition of types for attributes that are typically
stored in the "any attribute" of an ISO-19770-2:2015 in XML stored in the "any attribute" of an ISO-19770-2:2015 in XML
representation. These are covered in Section 2.2 and Section 2.3 representation. These are covered in Section 2.2 and [model-any-
of this document. element] of this document.
o The inclusion of extension points in the CoSWID data definition o The inclusion of extension points in the CoSWID data definition
that allow for additional uses of CoSWID tags that go beyond the that allow for additional uses of CoSWID tags that go beyond the
original scope of ISO-19770-2:2015 tags. These are covered in original scope of ISO-19770-2:2015 tags. The following extension
Section 2.7.3 and Section 2.7.4. points are defined in this document:
* CoSWID Extension - Used to add new information structures to a
CoSWID (defined in Section 2.1).
* Entity Extension - Used to add new new information structures
to an entity (defined in Section 2.4).
* Payload Extension - Used to add new new information structures
to a payload, such as new payload resource types (defined in
Section 2.7.3).
* Evidence Extension - Used to add new new information structures
to an evidence, such as new evidence resource types (defined in
Section 2.7.4).
1.3. Requirements Notation 1.3. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119, BCP 14 [RFC2119]. 2119, BCP 14 [RFC2119].
2. Concise SWID Data Definition 2. Concise SWID Data Definition
The following is a CDDL representation for a CoSWID tag. This CDDL The following is a CDDL representation for a CoSWID tag. This CDDL
represetation is intended to be parallel to the XML schema definition representation is intended to be parallel to the XML schema
in the ISO/IEC 19770-2:2015 [SWID] specification, allowing both SWID definition in the ISO/IEC 19770-2:2015 [SWID] specification, allowing
and CoSWID tags to represent a common set of SWID information and to both SWID and CoSWID tags to represent a common set of SWID
support all SWID tag use cases. To achieve this end, the CDDL information and to support all SWID tag use cases. To achieve this
representation includes every SWID tag field and attribute. The end, the CDDL representation includes every SWID tag field and
CamelCase notation used in the XML schema definition is changed to a attribute. The CamelCase notation used in the XML schema definition
hyphen-separated notation (e.g. ResourceCollection is named is changed to a hyphen-separated notation (e.g. ResourceCollection
resource-collection in the CoSWID data definition). This deviation is named resource-collection) in the CoSWID data definition. This
from the original notation used in the XML representation reduces deviation from the original notation used in the XML representation
ambiguity when referencing certain attributes in corresponding reduces ambiguity when referencing certain attributes in
textual descriptions. An attribute referred by its name in CamelCase corresponding textual descriptions. An attribute referred by its
notation explicitly relates to XML SWID tags, an attribute referred name in CamelCase notation explicitly relates to XML SWID tags, an
by its name in hyphen-separated notation explicitly relates to CoSWID attribute referred by its name in hyphen-separated notation
tags. This approach simplifies the composition of further work that explicitly relates to CoSWID tags. This approach simplifies the
reference both XML SWID and CoSWID documents. composition of further work that reference both XML SWID and CoSWID
documents.
Human-readable names of members in the CDDL data definition are Human-readable names of members in the CDDL data definition are
mapped to integer indices via a block of rules at the bottom of the mapped to integer indices via a block of rules at the bottom of the
definition. The 67 character strings of the SWID vocabulary that definition. The 67 character strings of the SWID vocabulary that
would have to be stored or transported in full if using the original would have to be stored or transported in full if using the original
vocabulary are replaced. vocabulary are replaced.
In CBOR, an array is encoded using bytes that identify the array, and In CBOR, an array is encoded using bytes that identify the array, and
the array's length or stop point (see [RFC7049]). To make items that the array's length or stop point (see [RFC7049]). To make items that
support 1 or more values, the following CDDL notion is used. support 1 or more values, the following CDDL notion is used.
_name_ = (_label_: _data_ / [ 2* _data_ ]) _name_ = (_label_: _data_ / [ 2* _data_ ])
The CDDL above allows for a more effecient CBOR encoding of the data The CDDL above allows for a more efficient CBOR encoding of the data
when a single value is used by avoiding the need to first encode the when a single value is used by avoiding the need to first encode the
array. An array is used for two or more values. This modeling array. An array is used for two or more values. This modeling
pattern is used frequently in the CoSWID CDDL data definition in such pattern is used frequently in the CoSWID CDDL data definition in such
cases. cases.
The following subsections describe the different parts of the CoSWID The following subsections describe the different parts of the CoSWID
model. model.
2.1. The concise-software-identity Object 2.1. The concise-software-identity Object
skipping to change at page 8, line 24 skipping to change at page 9, line 17
tag-id, tag-id,
tag-version, tag-version,
? corpus, ? corpus,
? patch, ? patch,
? supplemental, ? supplemental,
swid-name, swid-name,
? software-version, ? software-version,
? version-scheme, ? version-scheme,
? media, ? media,
? software-meta-entry, ? software-meta-entry,
? entity-entry, entity-entry,
? link-entry, ? link-entry,
? ( payload-entry / evidence-entry ), ? ( payload-entry // evidence-entry ),
? any-element-entry, * $$coswid-extension
} }
tag-id = (0: text)
swid-name = (1: text)
entity-entry = (2: entity / [ 2* entity ])
evidence-entry = (3: evidence)
link-entry = (4: link / [ 2* link ])
software-meta-entry = (5: software-meta / [ 2* software-meta ])
payload-entry = (6: payload)
any-element-entry = (7: any-element-map / [ 2* any-element-map ])
corpus = (8: bool)
patch = (9: bool)
media = (10: text)
supplemental = (11: bool)
tag-version = (12: integer)
software-version = (13: text)
version-scheme = (14: text)
The following describes each child item of the concise-software- The following describes each child item of the concise-software-
identity object model. identity object model.
o global-attributes: A list of items including an optional language o global-attributes: A list of items including an optional language
definition to support the processing of text-string values and an definition to support the processing of text-string values and an
unbounded set of any-attribute items. Described in Section 2.2. unbounded set of any-attribute items. Described in Section 2.2.
o tag-id (label 0): An textual identifier uniquely referencing a o tag-id (label 0): An textual identifier uniquely referencing a
(composite) software component. The tag identifier MUST be (composite) software component. The tag identifier MUST be
globally unique. There are no strict guidelines on how this globally unique. There are no strict guidelines on how this
identifier is structured, but examples include a 16 byte GUID identifier is structured, but examples include a 16 byte GUID
(e.g. class 4 UUID) [RFC4122]. (e.g. class 4 UUID) [RFC4122], or a text string appended to a DNS
domain name to ensure uniqueness across organizations.
o tag-version (label 12): An integer value that indicates if a o tag-version (label 12): An integer value that indicates if a
specific release of a software component has more than one tag specific release of a software component has more than one tag
that can represent that specific release. Typically, the initial that can represent that specific release. Typically, the initial
value of this field is set to 0, and the value is monotonically value of this field is set to 0, and the value is monotonically
increased for subsequent tags produced for the same software increased for subsequent tags produced for the same software
component release. This item is used when a CoSWID tag producer component release. This item is used when a CoSWID tag producer
creates and releases an incorrect tag that they subsequently want creates and releases an incorrect tag that they subsequently want
to fix, but no underlying changes have been made to the product to fix, but no underlying changes have been made to the product
the CoSWID tag represents. This could happen if, for example, a the CoSWID tag represents. This could happen if, for example, a
patch is distributed that has a link reference that does not cover patch is distributed that has a link reference that does not cover
all the various software releases it can patch. A newer CoSWID all the various software releases it can patch. A newer CoSWID
tag for that patch can be generated and the tag-version value tag for that patch can be generated and the tag-version value
incremented to indicate that the data is updated. incremented to indicate that the data has been updated.
o corpus (label 8): A boolean value that indicates if the tag o corpus (label 8): A boolean value that indicates if the tag
identifies and describes an installable software component in its identifies and describes an installable software component in its
pre-installation state. Installable software includes a pre-installation state. Installable software includes a
installation package or installer for a software component, a installation package or installer for a software component, a
software update, or a patch. If the CoSWID tag represents software update, or a patch. If the CoSWID tag represents
installable software, the corpus item MUST be set to "true". If installable software, the corpus item MUST be set to "true". If
not provided the default value MUST be considered "false". not provided the default value MUST be considered "false".
o patch (label 9): A boolean value that indicates if the tag o patch (label 9): A boolean value that indicates if the tag
skipping to change at page 9, line 49 skipping to change at page 10, line 26
software component. If a CoSWID tag is for a patch, it MUST software component. If a CoSWID tag is for a patch, it MUST
contain the patch item and its value MUST be set to "true". If contain the patch item and its value MUST be set to "true". If
not provided the default value MUST be considered "false". not provided the default value MUST be considered "false".
o supplemental (label 11): A boolean value that indicates if the tag o supplemental (label 11): A boolean value that indicates if the tag
is providing additional information to be associated with another is providing additional information to be associated with another
referenced SWID or CoSWID tag. Tags using this item help to referenced SWID or CoSWID tag. Tags using this item help to
ensure that primary and patch tags provided by a software provider ensure that primary and patch tags provided by a software provider
are not modified by software management tools, while allowing are not modified by software management tools, while allowing
these tools to provide their own software metadata for a software these tools to provide their own software metadata for a software
component. If a CoSWID tag is a supplemntal tag, it MUST contain component. If a CoSWID tag is a supplemental tag, it MUST contain
the supplemental item and its value MUST be set to "true". If not the supplemental item and its value MUST be set to "true". If not
provided the default value MUST be considered "false". provided the default value MUST be considered "false".
o swid-name (label 1): This textual item provides the software o swid-name (label 1): This textual item provides the software
component name as it would typically be referenced. For example, component name as it would typically be referenced. For example,
what would be seen in the add/remove software dialog in an what would be seen in the add/remove software dialog in an
operating system, or what is specified as the name of a packaged operating system, or what is specified as the name of a packaged
software component or a patch identifier name. software component or a patch identifier name.
o software-version (label 13): A textual value representing the o software-version (label 13): A textual value representing the
skipping to change at page 10, line 25 skipping to change at page 10, line 50
o version-scheme (label 14): An 8-bit integer or textual value o version-scheme (label 14): An 8-bit integer or textual value
representing the versioning scheme used for the software-version representing the versioning scheme used for the software-version
item. If an integer value is used it MUST be a value from the item. If an integer value is used it MUST be a value from the
registry (see section Section 4.1 or a value in the private use registry (see section Section 4.1 or a value in the private use
range: 32768-65,535. range: 32768-65,535.
o media (label 10): This text value is a hint to the tag consumer to o media (label 10): This text value is a hint to the tag consumer to
understand what this tag applies to. This item represents a query understand what this tag applies to. This item represents a query
as defined by the W3C Media Queries Recommendation (see as defined by the W3C Media Queries Recommendation (see
http://www.w3.org/TR/css3-mediaqueries/). A hint to the consumer http://www.w3.org/TR/css3-mediaqueries/). A hint to the consumer
of the link to what the target item is applicable for. of the link to what the target item is applicable for. Described
in Section 2.3.
o software-meta-entry (label 5): An open-ended collection of key/ o software-meta-entry (label 5): An open-ended map of key/value data
value data related to this CoSWID. A number of predefined pairs. A number of predefined keys can be used within this item
attributes can be used within this item providing for common usage providing for common usage and semantics across the industry. The
and semantics across the industry. The data definition of this data definition of this entry allows for any additional attribute
entry allows for any additional attribute to be included, though to be included, though it is recommended that industry norms for
it is recommended that industry norms for new attributes are new attributes are defined and followed to the degree possible.
defined and followed to the degree possible. Described in Described in Section 2.6.
Section 2.6.
o entity-entry (label 2): Specifies the organizations related to the o entity-entry (label 2): Provides information about one or more
software component referenced by this CoSWID tag. Described in organizations related to the software component referenced by this
Section 2.4. CoSWID tag. Described in Section 2.4.
o link-entry (label 4): Provides a means to establish a relationship o link-entry (label 4): Provides a means to establish relationship
arc between the tag and another item. A link can be used to arcs between the tag and another items. A given link can be used
establish relationships between tags and to reference other to establish the relationship between tags or to reference another
resources that are related to the CoSWID tag, e.g. vulnerability resource that is related to the CoSWID tag, e.g. vulnerability
database associations, ROLIE feeds, MUD files, software download database association, ROLIE feed , MUD resource , software
location, etc). This is modeled after the HTML "link" element. download location, etc). This is modeled after the HTML "link"
Described in Section 2.5. element. Described in Section 2.5.
o payload-entry (label 6): The items that may be installed on a o payload-entry (label 6): This item represents the software
system entity when the software component is installed. Note that artifacts that may be installed on an endpoint when the software
payload may be a superset of the items installed and - depending component is installed. Note that the payload may represent a
on optimization mechanisms in respect to that system entity - may superset of the software artifacts installed. Based on user
or may not include every item that could be created or executed on selections at install time, an installation may not include every
the corresponding system entitiy when software components are artifact that could be created or executed on the endpoint when
installed. In general, payload will be used to indicate the files the software component is installed (i.e. if a particular optional
that may be installed with a software component. Therefore sub-component is not installed, the files associated with that
payload will often be a superset of those files (i.e. if a software component may be included in payload, but not installed
particular optional sub-component is not installed, the files in the system entity). Described in Section 2.7.3.
associated with that software component may be included in
payload, but not installed in the system entity). Described in
Section 2.7.3.
o evidence-entry (label 3): This item is used to provide results o evidence-entry (label 3): This item is used to provide results
from a scan of a system where software that does not have a CoSWID from a scan of a system where software that does not have a CoSWID
tag is discovered. This information is not provided by the tag is discovered. In such a case, a CoSWID tag may be created by
software-creator, and is instead created when a system is being the discovery process when the endpoint is scanned. This item
scanned and the evidence for why software is believed to be represents evidence for why software is believed to be installed
installed on the device is provided in the evidence item. on the endpoint. Described in Section 2.7.4.
Described in Section 2.7.4.
o any-element-entry (label 7): A default map that can contain o any-element-entry (label 7): A default map that can contain
arbitrary map members and even nested maps (which would also be arbitrary map members and even nested maps (which would also be
any-elements). In essence, the any-element allows items not any-elements). In essence, the any-element allows items not
defined in this CDDL data definition to be included in a Concise defined in this CDDL data definition to be included in a Concise
Software Identifier. Described in Section 2.3. Software Identifier. Described in [model-any-element].
2.1.1. Determining the tag type 2.1.1. Determining the tag type
The operational model for SWID and CoSWID tags introduced in The operational model for SWID and CoSWID tags was introduced in
Section 1.1. The following rules can be used to determine the type Section 1.1. The following rules can be used to determine the type
of a CoSWID tag. of a CoSWID tag.
o Corpus Tag: A CoSWID tag MUST be considered a corpus tag if the o Corpus Tag: A CoSWID tag MUST be considered a corpus tag if the
corpus item is "true". corpus item is "true".
o Primary Tag: A CoSWID tag MUST be considered a primary tag if the o Primary Tag: A CoSWID tag MUST be considered a primary tag if the
corpus, patch, and supplemental items are "false". corpus, patch, and supplemental items are "false".
o Patch Tag: A CoSWID tag MUST be considered a patch tag if the o Patch Tag: A CoSWID tag MUST be considered a patch tag if the
skipping to change at page 12, line 7 skipping to change at page 12, line 32
A tag that does not match one of the above rules MUST be considered A tag that does not match one of the above rules MUST be considered
an invalid, unsupported tag type. an invalid, unsupported tag type.
If a patch modifies the version number or the descriptive metadata of If a patch modifies the version number or the descriptive metadata of
the software, then a new tag representing these details SHOULD be the software, then a new tag representing these details SHOULD be
installed, and the old tag SHOULD be removed. installed, and the old tag SHOULD be removed.
2.1.2. concise-software-identity Co-constraints 2.1.2. concise-software-identity Co-constraints
o Only one of the corpus, patch, and supplemental items MUST be set o Only one of the patch and supplemental items MUST be set to
to "true", or all of the corpus, patch, and supplemental items "true", or the patch and supplemental items MUST be set to "false"
MUST be set to "false" or be omitted. or be omitted.
o If the patch item is set to "true", the the tag SHOULD contain at o If the patch item is set to "true", the tag SHOULD contain at
least one link with the rel(ation) item value of "patches" and an least one link with the rel(ation) item value of "patches" and an
href item specifying an association with the software that was href item specifying an association with the software that was
patched. patched.
o If the supplemental item is set to "true", the the tag SHOULD o If the supplemental item is set to "true", the tag SHOULD contain
contain at least one link with the rel(ation) item value of at least one link with the rel(ation) item value of "supplements"
"supplements" and an href item specifying an association with the and an href item specifying an association with the software that
software that is supplemented. is supplemented.
o If all of the corpus, patch, and supplemental items are "false", o If all of the corpus, patch, and supplemental items are "false",
or if the corpus item is set to "true", then a software-version or if the corpus item is set to "true", then a software-version
item MUST be included with a value set to the version of the item MUST be included with a value set to the version of the
software component. This ensures that primary and corpus tags software component. This ensures that primary and corpus tags
have an identifiable software version. have an identifiable software version.
2.2. The global-attributes Group 2.2. The global-attributes Group
The global-attributes group provides a list of items including an The global-attributes group provides a list of items including an
skipping to change at page 12, line 48 skipping to change at page 13, line 26
? lang, ? lang,
* any-attribute, * any-attribute,
) )
label = text / int label = text / int
any-attribute = ( any-attribute = (
label => text / int / [ 2* text ] / [ 2* int ] label => text / int / [ 2* text ] / [ 2* int ]
) )
lang = (15: text)
The following describes each child item of this object. The following describes each child item of this object.
o lang (index 15): A language tag or corresponding IANA index o lang (index 15): A textual language tag that conforms with IANA
integer that conforms with IANA Language Subtag Registry Language Subtag Registry [RFC5646].
[RFC5646].
o any-attribute: This sub-group provides a means to include o any-attribute: This sub-group provides a means to include
arbitrary information via label (key) item value pairs where both arbitrary information via label (key) item value pairs where both
keys and values can be either a single integer or text string, or keys and values can be either a single integer or text string, or
an array of integers or text strings. an array of integers or text strings.
2.3. The any-element-map Entry 2.3. The media Object
The CDDL for the any-element-entry object is as follows: The CDDL for the entity object is as follows:
any-element-map = { media = (10: [ + [ media-expression,
global-attributes, ? [ media-operation,
* label => any-element-map / [ 2* any-element-map ], media-expression,
} ]
any-element-entry = (7: any-element-map / [ 2* any-element-map ]) ]
])
media-operation = text
media-expression = media-environment / [ media-prefix,
media-environment,
media-attribute,
media-value,
]
media-prefix = text
media-environment = text
media-attribute = text
media-value = text
The following describes each child item of this object. The following describes each child item of this object.
o global-attributes: The global-attributes group described in o TBD
Section 2.2.
o label: a single or multiple
2.4. The entity Object 2.4. The entity Object
The CDDL for the entity object is as follows: The CDDL for the entity object is as follows:
entity = { entity = {
global-attributes, global-attributes,
entity-name, entity-name,
? reg-id, ? reg-id,
role, role,
? thumbprint, ? thumbprint,
extended-data, * $$entity-extension,
} }
any-uri = text
extended-data = (30: any-element-map / [ 2* any-element-map ])
entity-name = (31: text)
reg-id = (32: any-uri)
role = (33: text / [2* text])
thumbprint = (34: hash-entry)
The following describes each child item of this object. The following describes each child item of this object.
o global-attributes: The global-attributes group described in o global-attributes: The global-attributes group described in
Section 2.2. Section 2.2.
o entity-name (index 32): The text-string name of the organization o entity-name (index 32): The text-string name of the organization
claiming a particular role in the CoSWID tag. claiming a particular role in the CoSWID tag.
o reg-id (index 32): The registration id is intended to uniquely o reg-id (index 32): The registration id is intended to uniquely
identify a naming authority in a given scope (e.g. global, identify a naming authority in a given scope (e.g. global,
organization, vendor, customer, administrative domain, etc.) that organization, vendor, customer, administrative domain, etc.) for
is implied by the referenced naming authority. The value of an the referenced naming authority. The value of an registration ID
registration ID MUST be a RFC 3986 URI. The scope SHOULD be the MUST be a RFC 3986 URI. The scope SHOULD be the scope of an
scope of an organization. In a given scope, the registration id organization. In a given scope, the registration id MUST be used
MUST be used consistently. consistently.
o role (index 33): The relationship(s) between this organization and o role (index 33): The relationship(s) between this organization and
this tag. The role of tag creator is required for every CoSWID this tag. The role of an entity MAY include any role value, but
tag. The role of an entity may include any role value, but the the pre-defined roles include: "aggregator", "distributor",
pre-defined roles include: "aggregator", "distributor",
"licensor", "software-creator", and "tag-creator". These pre- "licensor", "software-creator", and "tag-creator". These pre-
defined role index and text values are defined in Section 3.2. defined role index and text values are defined in Section 3.2.
Use of index values instead of text for these pre-defined roles Use of index values instead of text for these pre-defined roles
allows a CoSWID to be more concise. allows a CoSWID to be more concise.
o thumbprint (index 34): The value of the thmbprint item provides an An entity item MUST be provided with the role of "tag-creator" for
integer-based hash algorithm identifier (hash-alg-id) and a byte every CoSWID tag. This indicates the organization that created
string string value (hash-value) that contains the corresponding the CoSWID tag.
o 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 entities hash value (i.e. the thumbprint) of the signing entities
certificate(s). If the hash-alg-id is not known, then the integer certificate(s). If the hash-alg-id is not known, then the integer
value "0" MUST be used. This ensures parity between the SWID tag value "0" MUST be used. This ensures parity between the SWID tag
specification [SWID], which does not allow an algorithm to be specification [SWID], which does not allow an algorithm to be
identified for this field. See Section 2.7.1 for more details on identified for this field. See Section 2.7.1 for more details on
the use of the hash-entry data structure. the use of the hash-entry data structure.
o extended-data (index 30): An open-ended collection of elements o $$entity-extension: This CDDL socket (see [I-D.ietf-cbor-cddl]
that can be used to attach arbitrary metadata to an entity item. section 3.9) can be used to extend the entity model, allowing
well-formed extensions to be defined in additional CDDL
descriptions.
2.5. The link Object 2.5. The link Object
The CDDL for the link object is as follows: The CDDL for the link object is as follows:
link = { link = {
global-attributes, global-attributes,
? artifact, ? artifact,
href, href,
? media ? media
? ownership, ? ownership,
rel, rel,
? media-type, ? media-type,
? use, ? use,
} }
artifact = (37: text)
href = (38: any-uri)
media = (10: any-uri)
ownership = (39: "shared" / "private" / "abandon")
rel = (40: text)
media-type = (41: text)
use = (42: "optional" / "required" / "recommended")
The following describes each child item of this object. The following describes each child item of this object.
o global-attributes: The global-attributes group described in o global-attributes: The global-attributes group described in
Section 2.2. Section 2.2.
o artifact (index: 37): For installation media (rel="installation- o artifact (index: 37): For installation media (rel="installation-
media"), this item value indicates the path of the installer media"), this item value indicates the path of the installer
executable or script that can be run to launch the referenced executable or script that can be run to launch the referenced
installation. Items with the same artifact name should be installation. Items with the same artifact name should be
skipping to change at page 15, line 43 skipping to change at page 16, line 23
to be downloaded from any of the described sources. to be downloaded from any of the described sources.
o href (index 38): The link to the item being referenced. The o href (index 38): The link to the item being referenced. The
"href" item's value can point to several different things, and can "href" item's value can point to several different things, and can
be any of the following: be any of the following:
* If no URI scheme is provided, then the URI is to be interpreted * 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, as being relative to the URI of the CoSWID tag. For example,
"./folder/supplemental.coswid". "./folder/supplemental.coswid".
* a physical resource location with any system-acceptable URI * a physical resource location with any acceptable URI scheme
scheme (e.g., file:// http:// https:// ftp://) (e.g., file:// http:// https:// ftp://)
* a URI with "coswid:" as the scheme, which refers to another * a URI with "coswid:" as the scheme, which refers to another
CoSWID by tag-id. This URI would need to be resolved in the CoSWID by tag-id. This URI would need to be resolved in the
context of the system by software that can lookup other CoSWID context of the endpoint by software that can lookup other
tags. For example, "coswid:2df9de35-0aff- CoSWID tags. For example, "coswid:2df9de35-0aff-
4a86-ace6-f7dddd1ade4c" references the tag with the tag-id 4a86-ace6-f7dddd1ade4c" references the tag with the tag-id
value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c". value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c".
* a URI with "swidpath:" as the scheme, which refers to another * a URI with "swidpath:" as the scheme, which refers to another
CoSIWD via an XPATH query. This URI would need to be resolved CoSIWD via an XPATH query. This URI would need to be resolved
in the context of the system entity via dedicated software in the context of the system entity via software components
components that can lookup other CoSWID tags and select the that can lookup other CoSWID tags and select the appropriate
appropriate tag based on an XPATH query. Examples include: tag based on an XPATH query. Examples include:
* swidpath://SoftwareIdentity[Entity/@regid='http://contoso.com'] * swidpath://SoftwareIdentity[Entity/@regid='http://contoso.com']
would retrieve all CoSWID tags that include an entity where the would retrieve all CoSWID tags that include an entity where the
regid is "Contoso" or swidpath://SoftwareIdentity[Meta/@persist regid is "Contoso" or swidpath://SoftwareIdentity[Meta/@persist
entId='b0c55172-38e9-4e36-be86-92206ad8eddb'] would match entId='b0c55172-38e9-4e36-be86-92206ad8eddb'] would match
CoSWID tags with the persistent-id value CoSWID tags with the persistent-id value
"b0c55172-38e9-4e36-be86-92206ad8eddb". "b0c55172-38e9-4e36-be86-92206ad8eddb".
* See XPATH query standard : http://www.w3.org/TR/xpath20/ * See XPATH query standard : http://www.w3.org/TR/xpath20/
o media (index 10): See media defined in Section 2.1. o media (index 10): See media defined in Section 2.3.
o ownership (index 39): Determines the relative strength of o ownership (index 39): Determines the relative strength of
ownership of the software components. Valid enumerations are: ownership of the software components. Valid enumerations are:
abandon, private, shared abandon, private, shared
o rel (index 40): The relationship between this CoSWID and the o rel (index 40): The relationship between this CoSWID and the
target file. Relationships can be identified by referencing the target file. Relationships can be identified by referencing the
IANA registration library: https://www.iana.org/assignments/link- IANA registration library: https://www.iana.org/assignments/link-
relations/link-relations.xhtml. relations/link-relations.xhtml.
o media-type (index 41): The IANA MediaType for the target file; o media-type (index 41): The IANA MediaType for the target resource;
this provides the consumer with intelligence of what to expect. this provides the consumer with a hint of what type of resource to
See http://www.iana.org/assignments/media-types/media-types.xhtml expect. See http://www.iana.org/assignments/media-types/media-
for more details on link type. types.xhtml for more details.
o use (index 42): Determines if the target software is a hard o use (index 42): Determines if the target software is a hard
requirement or not. Valid enumerations are: required, requirement or not to be installed before installing the tagged
recommended, optional. software component. Valid enumerations are: required,
recommended, optional, which are defined in Section 3.3.
2.6. The software-meta Object 2.6. The software-meta Object
The CDDL for the software-meta object is as follows: The CDDL for the software-meta object is as follows:
software-meta = { software-meta = {
global-attributes, global-attributes,
? activation-status, ? activation-status,
? channel-type, ? channel-type,
? colloquial-version, ? colloquial-version,
skipping to change at page 17, line 23 skipping to change at page 17, line 42
? entitlement-key, ? entitlement-key,
? generator, ? generator,
? persistent-id, ? persistent-id,
? product, ? product,
? product-family, ? product-family,
? revision, ? revision,
? summary, ? summary,
? unspsc-code, ? unspsc-code,
? unspsc-version, ? unspsc-version,
} }
activation-status = (43: text)
channel-type = (44: text)
colloquial-version = (45: text)
description = (46: text)
edition = (47: text)
entitlement-data-required = (48: bool)
entitlement-key = (49: text)
generator = (50: text)
persistent-id = (51: text)
product = (52: text)
product-family = (53: text)
revision = (54: text)
summary = (55: text)
unspsc-code = (56: text)
unspsc-version = (57: text)
The following describes each child item of this object. The following describes each child item of this object.
o global-attributes: The global-attributes group described in o global-attributes: The global-attributes group described in
Section 2.2. Section 2.2.
o activation-status (index 43): Identification of the activation o activation-status (index 43): Identification of the activation
status of this software title (e.g. Trial, Serialized, Licensed, status of this software title (e.g. Trial, Serialized, Licensed,
Unlicensed, etc). Typically, this is used in supplemental tags. Unlicensed, etc). Typically, this is used in supplemental tags.
o channel-type (index 44): Provides information on which channel o channel-type (index 44): Provides information on which channel
this particular software was targeted for (e.g. Volume, Retail, this particular software was targeted for (e.g. Volume, Retail,
OEM, Academic, etc). Typically used in supplemental tags. OEM, Academic, etc). Typically used in supplemental tags.
o colloquial-version (index 45): The informal or colloquial version o colloquial-version (index 45): The informal or colloquial version
of the product (i.e. 2013). Note that this version may be the of the product (i.e. 2013). Note that this version may be the
same through multiple releases of a software component where the same through multiple releases of a software component where the
version specified in entity is much more specific and will change version specified in entity is much more specific and will change
for each software release. Note that this representation of for each software release.
version is typically used to identify a group of specific software
releases that are part of the same release/support infrastructure Note that this representation of version is typically used to
(i.e. Fabrikam Office 2013). This version is used for string identify a group of specific software releases that are part of
comparisons only and is not compared to be an earlier or later the same release/support infrastructure (i.e. Fabrikam Office
release (that is done via the entity version). 2013). This version is used for string comparisons only and is
not compared to be an earlier or later release (that is done via
the entity version).
o description (index 46): A longer, detailed description of the o description (index 46): A longer, detailed description of the
software. This description can be multiple sentences software. This description can be multiple sentences
(differentiated from summary, which is a very short, one-sentence (differentiated from summary, which is a very short, one-sentence
description). description).
o edition (index 47): The variation of the product (Extended, o edition (index 47): The variation of the product (Extended,
Enterprise, Professional, Standard etc). Enterprise, Professional, Standard, etc).
o entitlement-data-required (index 48): An indicator to determine if o entitlement-data-required (index 48): An indicator to determine if
there should be accompanying proof of entitlement when a software there should be accompanying proof of entitlement when a software
license reconciliation is completed. license reconciliation is completed.
o entitlement-key (index 49): A vendor-specific textual key that can o entitlement-key (index 49): A vendor-specific textual key that can
be used to reconcile the validity of an entitlement. (e.g. serial be used to reconcile the validity of an entitlement. (e.g. serial
number, product or license key). number, product or license key).
o generator (index 50): The name of the software tool that created a o generator (index 50): The name of the software tool that created a
CoSWID tag. This item is typically used if tags are created on CoSWID tag. This item is typically used if tags are created on
the fly or via a catalog-based analysis for data found on a the fly or via a catalog-based analysis for data found on an
computing device. endpoint.
o persistent-id (index 51): A GUID used to represent products o persistent-id (index 51): A GUID used to represent products
installed where the products are related, but may be different installed where the products are related, but may be different
versions. versions.
o product (index 52): The base name of the product (e.g. ). o product (index 52): The base name of the product.
o product-family (index 53): The overall product family this o product-family (index 53): The overall product family this
software belongs to. Product family is not used to identify that software belongs to. Product family is not used to identify that
a product is part of a suite, but is instead used when a set of a product is part of a suite, but is instead used when a set of
products that are all related may be installed on multiple products that are all related may be installed on multiple
different devices. For example, an enterprise backup system may different endpoints. For example, an enterprise backup system may
consist of a backup services, multiple different backup services consist of a backup services, multiple different backup services
that support mail services, databases and ERP systems, as well as that support mail services, databases and ERP systems, as well as
individual software components that backup client system entities. individual software components that backup client system entities.
In such an usage scenario, all software components that are part In such an usage scenario, all software components that are part
of the backup system would have the same product-family name so of the backup system would have the same product-family name so
they can be grouped together in respect to reporting systems. they can be grouped together in respect to reporting systems.
o revision (index 54): The informal or colloquial representation of o revision (index 54): The informal or colloquial representation of
the sub-version of the given product (ie, SP1, R2, RC1, Beta 2, the sub-version of the given product (ie, SP1, R2, RC1, Beta 2,
etc). Note that the version will provide very exact version etc). Note that the version item will provide very exact version
details, the revision is intended for use in environments where details, while the revision is intended for use in environments
reporting on the informal or colloquial representation of the where reporting on the informal or colloquial representation of
software is important (for example, if for a certain business the software is important (for example, if for a certain business
process, an organization recognizes that it must have, for example process, an organization recognizes that it must have, for example
"ServicePack 1" or later of a specific product installed on all "ServicePack 1" or later of a specific product installed on all
devices, they can use the revision data value to quickly identify devices, they can use the revision data value to quickly identify
any devices that do not meet this requirement). Depending on how any devices that do not meet this requirement).
a software organizations distributes revisions, this value could
be specified in a primary (if distributed as an upgrade) or Depending on how a software organizations distributes revisions,
supplemental (if distributed as a patch) CoSWID tag. this value could be specified in a primary (if distributed as an
upgrade) or supplemental (if distributed as a patch) CoSWID tag.
o summary (index 55): A short (one-sentence) description of the o summary (index 55): A short (one-sentence) description of the
software. software.
o unspsc-code (index 56): An 8 digit code that provides UNSPSC o unspsc-code (index 56): An 8 digit code that provides UNSPSC
classification of the software component this SWID tag identifies. classification of the software component this SWID tag identifies.
For more information see, http://www.unspsc.org/. For more information see, http://www.unspsc.org/.
o unspsc-version (index 57): The version of the UNSPSC code used to o unspsc-version (index 57): The version of the UNSPSC code used to
define the UNSPSC code value. For more information see, define the UNSPSC code value. For more information see,
skipping to change at page 21, line 4 skipping to change at page 21, line 42
type, type,
} }
filesystem-item = ( filesystem-item = (
global-attributes, global-attributes,
? key, ? key,
? location, ? location,
fs-name, fs-name,
? root, ? root,
) )
directory-entry = (16: directory / [ 2* directory ])
file-entry = (17: file / [ 2* file ])
process-entry = (18: process / [ 2* process ])
resource-entry = (19: resource / [ 2* resource ])
size = (20: integer)
file-version = (21: text)
key = (22: bool)
location = (23: text)
fs-name = (24: text)
root = (25: text)
path-elements = (26: { * file-entry,
* directory-entry,
}
)
process-name = (27: text)
pid = (28: integer)
type = (29: text)
The following describes each child item or group for these groups. The following describes each child item or group for these groups.
o filesystem-item: A list of items both used in representing the o filesystem-item: A list of items both used in representing the
nodes of a file-system hierarchy, i.e. directory items that allow nodes of a file-system hierarchy, i.e. directory items that allow
one or more directories to be defined in the file structure, and one or more directories to be defined in the file structure, and
file items that allow one or more files to be specified for a file items that allow one or more files to be specified for a
given location. given location.
o global-attributes: The global-attributes group described in o global-attributes: The global-attributes group described in
skipping to change at page 28, line 30 skipping to change at page 28, line 42
installationmedia=3 installationmedia=3
packageinstaller=4 packageinstaller=4
parent=5 parent=5
patches=6 patches=6
requires=7 requires=7
see-also=8 see-also=8
supersedes=9 supersedes=9
rel-supplemental=10 rel-supplemental=10
media-type = (41: text) media-type = (41: text)
use = (42: optional / required / recommended / extended-value ) use = (42: optional / required / recommended / extended-value )
optional=0 optional=1
required=1 required=2
recommended=2 recommended=3
activation-status = (43: text) activation-status = (43: text)
channel-type = (44: text) channel-type = (44: text)
colloquial-version = (45: text) colloquial-version = (45: text)
description = (46: text) description = (46: text)
edition = (47: text) edition = (47: text)
entitlement-data-required = (48: bool) entitlement-data-required = (48: bool)
entitlement-key = (49: text) entitlement-key = (49: text)
generator = (50: text) generator = (50: text)
persistent-id = (51: text) persistent-id = (51: text)
product = (52: text) product = (52: text)
skipping to change at page 29, line 9 skipping to change at page 29, line 21
unspsc-version = (57: text) unspsc-version = (57: text)
hash-entry = (58: [ hash-alg-id: int, hash-entry = (58: [ hash-alg-id: int,
hash-value: bstr, hash-value: bstr,
] ]
) )
3. CoSWID Indexed Label Values 3. CoSWID Indexed Label Values
3.1. Version Scheme 3.1. Version Scheme
The following are an initial set of values for use in the version- The following table contains an initial set of values for use in the
scheme item for the version schemes defined in the ISO/IEC version-scheme item for the version schemes defined in the ISO/IEC
19770-2:2015 [SWID] specification. Index value in parens indicates 19770-2:2015 [SWID] specification. Index value in parens indicates
the index value to use in the version-scheme item. the index value to use in the version-scheme item.
o multipartnumeric (index 1): Numbers separated by dots, where the +-------+-------------------------+---------------------------------+
numbers are interpreted as integers (e.g.,1.2.3, 1.4.5, | Index | Role Name | Definition |
1.2.3.4.5.6.7) +-------+-------------------------+---------------------------------+
| 0 | Reserved | |
o multipartnumeric+suffix (index 2): Numbers separated by dots, | | | |
where the numbers are interpreted as integers with an additional | 1 | multipartnumeric | Numbers separated by dots, |
string suffix(e.g., 1.2.3a) | | | where the numbers are |
| | | interpreted as integers |
o alphanumeric (index 3): Strictly a string, sorting is done | | | (e.g.,1.2.3, 1.4.5, |
alphanumerically | | | 1.2.3.4.5.6.7) |
| | | |
o decimal (index 4): A floating point number (e.g., 1.25 is less | 2 | multipartnumeric+suffix | Numbers separated by dots, |
than 1.3) | | | where the numbers are |
| | | interpreted as integers with an |
o semver (index 16384): Follows the [SEMVER] specification | | | additional string suffix(e.g., |
| | | 1.2.3a) |
| | | |
| 3 | alphanumeric | Strictly a string, sorting is |
| | | done alphanumerically |
| | | |
| 4 | decimal | A floating point number (e.g., |
| | | 1.25 is less than 1.3) |
| | | |
| 16384 | semver | Follows the [SEMVER] |
| | | specification |
+-------+-------------------------+---------------------------------+
The values above are registered in the "SWID/CoSWID Version Schema The values above are registered in the "SWID/CoSWID Version Schema
Values" registry defined in section Section 4.1. Additional valid Values" registry defined in section Section 4.1. Additional valid
values will likely be registered over time in this registry. values will likely be registered over time in this registry.
Additionally, the index values 32768 through 65535 have been reserved
for private use.
3.2. Entity Role Values 3.2. Entity Role Values
The following table indicates the index value to use for the entity The following table indicates the index value to use for the entity
roles defined in the ISO/IEC 19770-2:2015 [SWID] specification. roles defined in the ISO/IEC 19770-2:2015 [SWID] specification.
+-------+-----------------+ | Index | Role Name | Definition |-- | 0 | Reserved | | 1 |
| Index | Role Name | tagCreator | The person or organization that created the containing
+-------+-----------------+ SWID or CoSWID tag | 2 | softwareCreator | From [SAM], "person or
| 0 | Reserved | organization that creates a software product (3.46) or package" | 3 |
| | | aggregator | From {{SWID}, "An organization or system that
| 1 | tagCreator | encapsulates software from their own and/or other organizations into
| | | a different distribution process (as in the case of virtualization),
| 2 | softwareCreator | or as a completed system to accomplish a specific task (as in the
| | | case of a value added reseller)." | 4 | distributor | From [SWID],
| 3 | aggregator | "An entity that furthers the marketing, selling and/or distribution
| | | of software from the original place of manufacture to the ultimate
| 4 | distributor | user without modifying the software, its packaging or its
| | | labelling." | 5 | licensor | From [SAM] as "software licensor",
| 5 | licensor | "person or organization who owns or holds the rights to issue a
+-------+-----------------+ software license for a specific software package"
The values above are registered in the "SWID/CoSWID Entity Role The values above are registered in the "SWID/CoSWID Entity Role
Values" registry defined in section Section 4.2. Additional valid Values" registry defined in section Section 4.2. Additional valid
values will likely be registered over time. Additionally, the index values will likely be registered over time. Additionally, the index
values 226 through 255 have been reserved for private use. values 128 through 255 have been reserved for private use.
3.3. Use Values
The following table indicates the index value to use for the link use
item (see Section 2.5), which is also defined in the ISO/IEC
19770-2:2015 [SWID] specification.
+-------+-------------+---------------------------------------------+
| Index | Use Type | Definition |
+-------+-------------+---------------------------------------------+
| 0 | Reserved | |
| | | |
| 1 | optional | From {{SWID}, "Not absolutely required; the |
| | | [Link]'d software is installed only when |
| | | specified." |
| | | |
| 2 | required | From {{SWID}, "The [Link]'d software is |
| | | absolutely required for an operation |
| | | software installation." |
| | | |
| 3 | recommended | From {{SWID}, "Not absolutely required; the |
| | | [Link]'d software is installed unless |
| | | specified otherwise." |
+-------+-------------+---------------------------------------------+
The values above are registered in the "SWID/CoSWID Link Use Values"
registry defined in section Section 4.3. Additional valid values
will likely be registered over time. Additionally, the index values
128 through 255 have been reserved for private use.
4. IANA Considerations 4. IANA Considerations
This document will include requests to IANA: This document will include requests to IANA:
o Integer indices for SWID content attributes and information o Integer indices for SWID content attributes and information
elements. elements.
o Content-Type for CoAP to be used in COSE. o Content-Type for CoAP to be used in COSE.
skipping to change at page 32, line 33 skipping to change at page 33, line 33
| 1 | tagCreator | See Section 3.2 | | 1 | tagCreator | See Section 3.2 |
| | | | | | | |
| 2 | softwareCreator | See Section 3.2 | | 2 | softwareCreator | See Section 3.2 |
| | | | | | | |
| 3 | aggregator | See Section 3.2 | | 3 | aggregator | See Section 3.2 |
| | | | | | | |
| 4 | distributor | See Section 3.2 | | 4 | distributor | See Section 3.2 |
| | | | | | | |
| 5 | licensor | See Section 3.2 | | 5 | licensor | See Section 3.2 |
| | | | | | | |
| 6-49 | Unassigned | | | 6-31 | Unassigned | |
| | | | | | | |
| 50-225 | Unassigned | | | 32-127 | Unassigned | |
| | | | | | | |
| 225-255 | Reserved for Private Use | | | 128-255 | Reserved for Private Use | |
+---------+--------------------------+-----------------+ +---------+--------------------------+-----------------+
4.3. Media Type Registration 4.3. SWID/CoSWID Link Use Values Registry
4.3.1. swid+cbor Media Type Registration This document uses unsigned 8-bit index values to represent link-use
values. The initial set of Link use values are derived from the
textual names defined in the ISO/IEC 19770-2:2015 specification
[SWID].
This document defines a new a new registry entitled "SWID/CoSWID Link
Use Values". Future registrations for this registry are to be made
based on [RFC8126] as follows:
+---------+--------------------------+
| Range | Registration Procedures |
+---------+--------------------------+
| 0-31 | Standards Action |
| | |
| 32-127 | Specification Required |
| | |
| 128-255 | Reserved for Private Use |
+---------+--------------------------+
Initial registrations for the SWID/CoSWID Entity Role Values registry
are provided below.
+---------+--------------------------+-----------------+
| Index | Role Name | Specification |
+---------+--------------------------+-----------------+
| 0 | Reserved | |
| | | |
| 1 | optional | See Section 3.3 |
| | | |
| 2 | required | See Section 3.3 |
| | | |
| 3 | recommended | See Section 3.3 |
| | | |
| 4-31 | Unassigned | |
| | | |
| 32-127 | Unassigned | |
| | | |
| 128-255 | Reserved for Private Use | |
+---------+--------------------------+-----------------+
4.4. Media Type Registration
4.4.1. swid+cbor Media Type Registration
Type name: application Type name: application
Subtype name: swid+cbor Subtype name: swid+cbor
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Must be encoded as using [RFC7049]. See Encoding considerations: Must be encoded as using [RFC7049]. See
RFC-AAAA for details. RFC-AAAA for details.
Security considerations: See Section 5 of RFC-AAAA. Security considerations: See Section 5 of RFC-AAAA.
Interoperability considerations: Applications MAY ignore any key Interoperability considerations: Applications MAY ignore any key
value pairs that they do not understand. This allows backwards value pairs that they do not understand. This allows backwards
compatible extensions to this specification. compatible extensions to this specification.
Published specification: RFC-AAAA Published specification: RFC-AAAA
skipping to change at page 33, line 45 skipping to change at page 35, line 41
Birkholz <henk.birkholz@sit.fraunhofer.de> Birkholz <henk.birkholz@sit.fraunhofer.de>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author: Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Author: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Change controller: IESG Change controller: IESG
4.4. CoAP Content-Format Registration 4.5. CoAP Content-Format Registration
IANA is requested to assign a CoAP Content-Format ID for the CoSWID IANA is requested to assign a CoAP Content-Format ID for the CoSWID
media type in the "CoAP Content-Formats" sub-registry, from the "IETF media type in the "CoAP Content-Formats" sub-registry, from the "IETF
Review or IESG Approval" space (256..999), within the "CoRE Review or IESG Approval" space (256..999), within the "CoRE
Parameters" registry [RFC7252]: Parameters" registry [RFC7252]:
+-----------------------+----------+-------+-----------+ +-----------------------+----------+-------+-----------+
| Media type | Encoding | ID | Reference | | Media type | Encoding | ID | Reference |
+-----------------------+----------+-------+-----------+ +-----------------------+----------+-------+-----------+
| application/swid+cbor | - | TBDcf | RFC-AAAA | | application/swid+cbor | - | TBDcf | RFC-AAAA |
+-----------------------+----------+-------+-----------+ +-----------------------+----------+-------+-----------+
Table 1: CoAP Content-Format IDs Table 1: CoAP Content-Format IDs
4.5. CBOR Tag Registration 4.6. CBOR Tag Registration
IANA is requested to allocate a tag in the CBOR Tags Registry, IANA is requested to allocate a tag in the CBOR Tags Registry,
preferably with the specific value requested: preferably with the specific value requested:
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
| Tag | Data | Semantics | | Tag | Data | Semantics |
| | Item | | | | Item | |
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
| 1398229316 | map | Concise Software Identifier (CoSWID) | | 1398229316 | map | Concise Software Identifier (CoSWID) |
| | | [RFC-AAAA] | | | | [RFC-AAAA] |
skipping to change at page 36, line 11 skipping to change at page 38, line 11
vendor created tags. For this reason, tools that consume SWID tags vendor created tags. For this reason, tools that consume SWID tags
ought to treat the tag contents as potentially malicious and should ought to treat the tag contents as potentially malicious and should
employ input sanitizing on the tags they ingest. employ input sanitizing on the tags they ingest.
6. Acknowledgments 6. Acknowledgments
7. Change Log 7. Change Log
Changes from version 06 to version 07: Changes from version 06 to version 07:
o Added version-scheme definitions o Added type choices/enumerations based on textual definitions in
19770-2:2015
o Added stubs for additional extension points
o Added value registry request o Added value registry request
o Added media type registration request o Added media type registration request
o Added content format registration request o Added content format registration request
o Added CBOR tag registration request o Added CBOR tag registration request
o Fixed any-element-map
o Removed RIM appedix to be addressed in complementary draft o Removed RIM appedix to be addressed in complementary draft
o Removed CWT appendix o Removed CWT appendix
o Flagged firmware resource colletion appendix for revision o Flagged firmware resource colletion appendix for revision
o Made use of terminology more consistent
o Better defined use of extension points in the CDDL
o Added definitions for indexed values
o Added IANA registry for Link use indexed values
Changes from version 05 to version 06: Changes from version 05 to version 06:
o Improved quantities o Improved quantities
o Included proposals for implicet enumerations that were NMTOKENS o Included proposals for implicet enumerations that were NMTOKENS
o Added extension points o Added extension points
o Improved exemplary firmware-resource extension o Improved exemplary firmware-resource extension
Changes from version 04 to version 05: Changes from version 04 to version 05:
o Clarified language around SWID and CoSWID to make more consistant o Clarified language around SWID and CoSWID to make more consistent
use of these terms. use of these terms.
o Added language describing CBOR optimizations for single vs. arrays o Added language describing CBOR optimizations for single vs. arrays
in the model front matter. in the model front matter.
o Fixed a number of gramatical, spelling, and wording issues. o Fixed a number of grammatical, spelling, and wording issues.
o Documented extension points that use CDDL sockets. o Documented extension points that use CDDL sockets.
o Converted IANA registration tables to markdown tables, reserving o Converted IANA registration tables to markdown tables, reserving
the 0 value for use when a value is not known. the 0 value for use when a value is not known.
o Updated a number of references to their current versions. o Updated a number of references to their current versions.
Changes from version 03 to version 04: Changes from version 03 to version 04:
skipping to change at page 39, line 44 skipping to change at page 41, line 49
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[SAM] "Information technology - Software asset management - Part [SAM] "Information technology - Software asset management - Part
5: Overview and vocabulary", ISO/IEC 19770-5:2013, 5: Overview and vocabulary", ISO/IEC 19770-5:2015,
November 2013. November 2013.
[SEMVER] Preston-Werner, T., "Semantic Versioning 2.0.0", n.d., [SEMVER] Preston-Werner, T., "Semantic Versioning 2.0.0", n.d.,
<https://semver.org/spec/v2.0.0.html>. <https://semver.org/spec/v2.0.0.html>.
[SWID] "Information technology - Software asset management - Part [SWID] "Information technology - Software asset management - Part
2: Software identification tag", ISO/IEC 19770-2:2015, 2: Software identification tag", ISO/IEC 19770-2:2015,
October 2015. October 2015.
[SWID-GUIDANCE] [SWID-GUIDANCE]
skipping to change at page 41, line 12 skipping to change at page 43, line 12
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
Appendix A. CoSWID Attributes for Firmware (label 60) Appendix A. CoSWID Attributes for Firmware (label 60)
NOTE: this appendix is subject to revision based potential NOTE: this appendix is subject to revision or removal based on
convergence of: potential convergence of:
o draft-moran-suit-manifest, and o draft-moran-suit-manifest, and
o draft-birkholz-suit-coswid-manifest o draft-birkholz-suit-coswid-manifest
The ISO-19770-2:2015 specification of SWID tags assumes the existence The ISO-19770-2:2015 specification of SWID tags assumes the existence
of a file system a software component is installed and stored in. In of a file system a software component is installed and stored in. In
the case of constrained-node networks [RFC7228] or network equipment the case of constrained-node networks [RFC7228] or network equipment
this assumption might not apply. Concise software instances in the this assumption might not apply. Concise software instances in the
form of (modular) firmware are often stored directly on a block form of (modular) firmware are often stored directly on a block
 End of changes. 86 change blocks. 
297 lines changed or deleted 361 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/