draft-ietf-sacm-coswid-08.txt   draft-ietf-sacm-coswid-09.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: May 12, 2019 Department of Defense Expires: November 13, 2019 Department of Defense
C. Schmidt C. Schmidt
The MITRE Corporation The MITRE Corporation
D. Waltermire D. Waltermire
NIST NIST
November 08, 2018 May 12, 2019
Concise Software Identifiers Concise Software Identification Tags
draft-ietf-sacm-coswid-08 draft-ietf-sacm-coswid-09
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 Next to the inherent capability of SWID tags to express arbitrary
the inherent capability of SWID tags to express arbitrary context context information, Concise SWID (CoSWID) tags support the
information, Concise SWID (CoSWID) tags support the definition of definition of additional semantics via well-defined data definitions
additional semantics via well-defined data definitions incorporated incorporated by extension points.
by extension points.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 12, 2019. This Internet-Draft will expire on November 13, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 and CoSWID Tag Lifecycle . . . . . . . . . . . . 4
1.2. Concise SWID Extensions . . . . . . . . . . . . . . . . . 6 1.2. Concise SWID Format . . . . . . . . . . . . . . . . . . . 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. Concise SWID Extensions . . . . . . . . . . . . . . . . . 8
2.1.1. Determining the tag type . . . . . . . . . . . . . . 12 2.2. The concise-swid-tag Group . . . . . . . . . . . . . . . 9
2.1.2. concise-software-identity Co-constraints . . . . . . 12 2.3. concise-swid-tag Co-constraints . . . . . . . . . . . . . 13
2.2. The global-attributes Group . . . . . . . . . . . . . . . 13 2.4. The global-attributes Group . . . . . . . . . . . . . . . 14
2.3. The media Object . . . . . . . . . . . . . . . . . . . . 13 2.5. The entity-entry Group . . . . . . . . . . . . . . . . . 14
2.4. The entity Object . . . . . . . . . . . . . . . . . . . . 14 2.6. The link-entry Map . . . . . . . . . . . . . . . . . . . 16
2.5. The link Object . . . . . . . . . . . . . . . . . . . . . 15 2.7. The software-meta-entry Map . . . . . . . . . . . . . . . 19
2.6. The software-meta Object . . . . . . . . . . . . . . . . 17 2.8. The Resource Collection Definition . . . . . . . . . . . 22
2.7. The Resource Collection Definition . . . . . . . . . . . 19 2.8.1. The hash-entry Array . . . . . . . . . . . . . . . . 22
2.7.1. The hash-entry Array . . . . . . . . . . . . . . . . 19 2.8.2. The resource-collection Group . . . . . . . . . . . . 23
2.7.2. The resource-collection Group . . . . . . . . . . . . 20 2.8.3. The payload-entry Group . . . . . . . . . . . . . . . 26
2.7.3. The payload Object . . . . . . . . . . . . . . . . . 23 2.8.4. The evidence-entry Group . . . . . . . . . . . . . . 26
2.7.4. The evidence Object . . . . . . . . . . . . . . . . . 23 2.9. Full CDDL Definition . . . . . . . . . . . . . . . . . . 27
2.8. Full CDDL Definition . . . . . . . . . . . . . . . . . . 24 3. Determining the Type of CoSWID . . . . . . . . . . . . . . . 33
3. CoSWID Indexed Label Values . . . . . . . . . . . . . . . . . 29 4. CoSWID Indexed Label Values . . . . . . . . . . . . . . . . . 33
3.1. Version Scheme . . . . . . . . . . . . . . . . . . . . . 29 4.1. Version Scheme . . . . . . . . . . . . . . . . . . . . . 33
3.2. Entity Role Values . . . . . . . . . . . . . . . . . . . 30 4.2. Entity Role Values . . . . . . . . . . . . . . . . . . . 34
3.3. Use Values . . . . . . . . . . . . . . . . . . . . . . . 30 4.3. Use Values . . . . . . . . . . . . . . . . . . . . . . . 35
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
4.1. SWID/CoSWID Version Schema Values Registry . . . . . . . 31 5.1. CoSWID Items Registry . . . . . . . . . . . . . . . . . . 36
4.2. SWID/CoSWID Entity Role Values Registry . . . . . . . . . 32 5.2. SWID/CoSWID Version Schema Values Registry . . . . . . . 39
4.3. SWID/CoSWID Link Use Values Registry . . . . . . . . . . 33 5.3. SWID/CoSWID Entity Role Values Registry . . . . . . . . . 40
4.4. Media Type Registration . . . . . . . . . . . . . . . . . 34 5.4. SWID/CoSWID Link Use Values Registry . . . . . . . . . . 41
4.4.1. swid+cbor Media Type Registration . . . . . . . . . . 34 5.5. swid+cbor Media Type Registration . . . . . . . . . . . . 42
4.5. CoAP Content-Format Registration . . . . . . . . . . . . 35 5.6. CoAP Content-Format Registration . . . . . . . . . . . . 43
4.6. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 36 5.7. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 44
5. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 44
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 46
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.1. Normative References . . . . . . . . . . . . . . . . . . 41 10.1. Normative References . . . . . . . . . . . . . . . . . . 50
9.2. Informative References . . . . . . . . . . . . . . . . . 42 10.2. Informative References . . . . . . . . . . . . . . . . . 51
Appendix A. CoSWID Attributes for Firmware (label 60) . . . . . 43
Appendix B. Signed Concise SWID Tags using COSE . . . . . . . . 46 Appendix A. Signed Concise SWID Tags using COSE . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
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 a 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-rats-tuda].
SWID tags, as defined in ISO-19770-2:2015 [SWID], provide a SWID tags, as defined in ISO-19770-2:2015 [SWID], provide a
standardized XML-based record format that identifies and describes a standardized XML-based record format that identifies and describes a
specific release of a software component. Different software specific release of a software component. Different software
components, and even different releases of a particular software components, and even different releases of a particular software
component, each have a different SWID tag record associated with component, each have a different SWID tag record associated with
them. SWID tags are meant to be flexible and able to express a broad them. SWID tags are meant to be flexible and able to express a broad
set of metadata about a software component. set of metadata about a software component.
While there are very few required fields in SWID tags, there are many While there are very few required fields in SWID tags, there are many
optional fields that support different use scenarios. While a SWID optional fields that support different use scenarios. A SWID tag
tag consisting of only required fields might be a few hundred bytes consisting of only required fields might be a few hundred bytes in
in size, a tag containing many of the optional fields can be many size; however, a tag containing many of the optional fields can be
orders of magnitude larger. Thus, real-world instances of SWID tags many orders of magnitude larger. Thus, real-world instances of SWID
can be fairly large, and the communication of SWID tags in use- tags 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 the human-readable labels of SWID data to more concise which maps the human-readable labels of SWID data items to more
integer labels (indices). The use of CBOR to express SWID concise 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 and CoSWID 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 software component's SWID tag is also installed. Likewise, when that software component's SWID tag is also installed. Likewise, when
the software component is uninstalled or replaced, the SWID tag is the software component is uninstalled or replaced, the SWID tag is
deleted or replaced, as appropriate. As a result, ISO/IEC deleted or replaced, as appropriate. As a result, ISO/IEC
19770-2:2015 describes a system wherein there is a correspondence 19770-2:2015 describes a system wherein there is a correspondence
between the set of installed software components on an endpoint, and between the set of installed software components on an endpoint, and
the presence of the corresponding SWID tags for these components on the presence of the corresponding SWID tags for these components on
that endpoint. CoSWIDs share the same lifecycle requirements as a that endpoint. CoSWIDs share the same lifecycle requirements as a
SWID tag. SWID tag.
The following is an excerpt (with some modifications and reordering) The SWID specification and supporting guidance provided in NIST
from NIST Interagency Report (NISTIR) 8060: Guidelines for the Internal Report (NISTIR) 8060: Guidelines for the Creation of
Creation of Interoperable SWID Tags [SWID-GUIDANCE], which describes Interoperable SWID Tags [SWID-GUIDANCE] defines four types of SWID
the tag types used within the lifecycle defined in ISO-19770-2:2015. tags: primary, patch, corpus, and supplemental.
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,
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 a software component is installed on a computing device. A
primary tag is intended to be installed on an endpoint along with primary tag is intended to be installed on an endpoint along with
the corresponding software component. 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 an endpoint. A patch tag is intended to component installed on an endpoint. A patch tag is intended to
be installed on an endpoint along with the corresponding software be installed on an endpoint along with the corresponding software
skipping to change at page 5, line 5 skipping to change at page 4, line 48
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, The type of a tag is determined by specific data elements, which is
which is discussed in Section 2.1.1. discussed in Section 3.
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
skipping to change at page 5, line 48 skipping to change at page 5, line 42
installed (i.e., pre-installation), and while the product is installed (i.e., pre-installation), and while the product is
being deployed, a corpus tag provides information about the being deployed, a corpus tag provides information about the
installation files and distribution media (e.g., CD/DVD, installation files and distribution media (e.g., CD/DVD,
distribution package). distribution package).
* Software Installation. A primary tag will be installed with * Software Installation. A primary tag will be installed with
the software component (or subsequently created) to uniquely the software component (or subsequently created) to uniquely
identify and describe the software component. Supplemental identify and describe the software component. Supplemental
tags are created to augment primary tags with additional site- tags are created to augment primary tags with additional site-
specific or extended information. While not illustrated in the specific or extended information. While not illustrated in the
figure, patch tags may also be installed during software figure, patch tags can also be installed during software
installation to provide information about software fixes installation to provide information about software fixes
deployed along with the base software installation. deployed along with the base software installation.
* Software Patching. When a new patch is applied to the software * Software Patching. When a new patch is applied to the software
component, a new patch tag is provided, supplying details about component, a new patch tag is provided, supplying details about
the patch and its dependencies. While not illustrated in the the patch and its dependencies. While not illustrated in the
figure, a corpus tag can also provide information about the figure, a corpus tag can also provide information about the
patch installer, and patching dependencies that need to be patch installer, and patching dependencies that need to be
installed before the patch. installed before the patch.
skipping to change at page 6, line 32 skipping to change at page 6, line 26
* Software Removal. Upon removal of the software component, * Software Removal. Upon removal of the software component,
relevant SWID tags are removed. This removal event can trigger relevant SWID tags are removed. This removal event can trigger
timely updates to software inventory reflecting the removal of timely updates to software inventory reflecting the removal of
the product and any associated patch or supplemental tags. the product and any associated patch or supplemental tags.
Note: While not fully illustrated in the figure, supplemental tags Note: While not fully illustrated in the figure, supplemental tags
can be associated with any corpus, primary, or patch tag to provide can be associated with any corpus, primary, or patch tag to provide
additional metadata about an installer, installed software, or additional metadata about an installer, installed software, or
installed patch respectively. installed patch respectively.
Each of the different SWID and CoSWID tag types provide different Understanding the use of CoSWIDs in the software lifecycle provides a
sets of information. For example, a "corpus tag" is used to describe basis for understanding the information provided in a CoSWID and the
a software component's installation image on an installation media, associated semantics of this information. Each of the different SWID
while a "patch tag" is meant to describe a patch that modifies some and CoSWID tag types provide different sets of information. For
other software component. example, a "corpus tag" is used to describe a software component's
installation image on an installation media, while a "patch tag" is
meant to describe a patch that modifies some other software
component.
1.2. Concise SWID Extensions 1.2. Concise SWID Format
This document defines the CoSWID format, a more concise This document defines the CoSWID tag 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]. The structure of a CoSWID is Representation (CBOR) [RFC7049]. The structure of a CoSWID is
described via the Concise Data Definition Language (CDDL) described via the Concise Data Definition Language (CDDL)
[I-D.ietf-cbor-cddl]. The resulting CoSWID data definition is [I-D.ietf-cbor-cddl]. The resulting CoSWID data definition is
aligned in the information able to be expressed with the XML schema aligned to 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]. This alignment allows both
CDDL names of the types and members used in the CoSWID data SWID and CoSWID tags to represent a common set of SWID information
definition, are mapped to more concise labels represented as small and to support all SWID tag use cases. To achieve this end, the CDDL
integer values. The names used in the CDDL data definition and the representation includes every SWID tag field and attribute.
mapping to the CBOR representation using integer labels is based on
the vocabulary of the XML attribute and element names defined in ISO/
IEC 19770-2:2015.
The corresponding CoSWID data definition includes two kinds of
augmentation.
o The explicit definition of types for attributes that are typically
stored in the "any attribute" of an ISO-19770-2:2015 in XML
representation. These are covered in Section 2.2 and [model-any-
element] of this document.
o The inclusion of extension points in the CoSWID data definition
that allow for additional uses of CoSWID tags that go beyond the
original scope of ISO-19770-2:2015 tags. The following extension
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 The vocabulary, i.e., the CDDL names of the types and members used in
to an evidence, such as new evidence resource types (defined in the CoSWID data definition, are mapped to more concise labels
Section 2.7.4). represented as small integer values. The names used in the CDDL data
definition and the mapping to the CBOR representation using integer
labels is based on the vocabulary of the XML attribute and element
names defined in ISO/IEC 19770-2:2015.
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
2119, BCP 14 [RFC2119]. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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. The
representation is intended to be parallel to the XML schema CamelCase [CamelCase] notation used in the XML schema definition is
definition in the ISO/IEC 19770-2:2015 [SWID] specification, allowing changed to a hyphen-separated notation [KebabCase] (e.g.
both SWID and CoSWID tags to represent a common set of SWID ResourceCollection is named resource-collection) in the CoSWID data
information and to support all SWID tag use cases. To achieve this definition. In essence, [KebabCase] "looks-like-this". This
end, the CDDL representation includes every SWID tag field and
attribute. The CamelCase notation used in the XML schema definition
is changed to a hyphen-separated notation (e.g. ResourceCollection
is named resource-collection) in the CoSWID data definition. This
deviation from the original notation used in the XML representation deviation from the original notation used in the XML representation
reduces ambiguity when referencing certain attributes in reduces ambiguity when referencing certain attributes in
corresponding textual descriptions. An attribute referred by its corresponding textual descriptions. An attribute referred by its
name in CamelCase notation explicitly relates to XML SWID tags, an name in CamelCase notation explicitly relates to XML SWID tags, an
attribute referred by its name in hyphen-separated notation attribute referred by its name in KebabCase notation explicitly
explicitly relates to CoSWID tags. This approach simplifies the relates to CoSWID tags. This approach simplifies the composition of
composition of further work that reference both XML SWID and CoSWID further work that reference both XML SWID and CoSWID documents.
documents.
Human-readable names of members in the CDDL data definition are Human-readable labels of members in CDDL map data definitions 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 57 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 efficient CBOR encoding of the data The CDDL rule above allows for a more efficient CBOR encoding of the
when a single value is used by avoiding the need to first encode the data when a single value is used by avoiding the need to first encode
array. An array is used for two or more values. This modeling the array. Conversely, an array is used for two or more values.
pattern is used frequently in the CoSWID CDDL data definition in such This modeling pattern is used frequently in the CoSWID CDDL data
cases. definition in such 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. Concise SWID Extensions
The CDDL for the main concise-software-identity object is as follows: The corresponding CoSWID data definition includes two kinds of
augmentation.
concise-software-identity = { o The explicit definition of types for attributes that are typically
global-attributes, stored in the "any attribute" of an ISO-19770-2:2015 in XML
tag-id, representation. These are covered in Section 2.4.
tag-version,
? corpus,
? patch,
? supplemental,
swid-name,
? software-version,
? version-scheme,
? media,
? software-meta-entry,
entity-entry,
? link-entry,
? ( payload-entry // evidence-entry ),
* $$coswid-extension
}
The following describes each child item of the concise-software- o The inclusion of extension points in the CoSWID data definition
identity object model. using CDDL sockets (see [I-D.ietf-cbor-cddl] section 3.9). The
use of CDDL sockets allow for well-formed extensions to be defined
in supplementary CDDL descriptions that support additional uses of
CoSWID tags that go beyond the original scope of ISO-19770-2:2015
tags. This extension mechanism can also be used to update the
CoSWID format as revisions to ISO-19770-2 are published.
The following CDDL sockets (extension points) are defined in this
document, which allow the addition of new information structures to
their respective CDDL groups.
+---------------------+-----------------------+---------------+
| Map Name | CDDL Socket | Defined in |
+---------------------+-----------------------+---------------+
| concise-swid-tag | $$coswid-extension | Section 2.2 |
| | | |
| entity-entry | $$entity-extension | Section 2.5 |
| | | |
| link-entry | $$link-extension | Section 2.6 |
| | | |
| software-meta-entry | $$meta-extension | Section 2.7 |
| | | |
| file-entry | $$file-extension | Section 2.8.2 |
| | | |
| directory-entry | $$directory-extension | Section 2.8.2 |
| | | |
| process-entry | $$process-extension | Section 2.8.2 |
| | | |
| resource-entry | $$resource-extension | Section 2.8.2 |
| | | |
| payload-entry | $$payload-extension | Section 2.8.3 |
| | | |
| evidence-entry | $$evidence-extension | Section 2.8.4 |
+---------------------+-----------------------+---------------+
The following CDDL sockets defined in this document allow for adding
new values to corresponding type-choices (i.e. to represent
enumerations) via custom CDDL data definitions.
+------------------+-----------------+-------------+
| Enumeration Name | CDDL Socket | Defined in |
+------------------+-----------------+-------------+
| version-scheme | $version-scheme | Section 4.1 |
| | | |
| role | $role | Section 4.2 |
| | | |
| ownership | $ownership | Section 2.6 |
| | | |
| rel | $rel | Section 4.3 |
| | | |
| use | $use | Section 2.6 |
+------------------+-----------------+-------------+
The CoSWID Items Registry defined in Section 5.1 provides a
registration mechanism allowing new items, and their associated index
values, to be added to the CoSWID model through the use of the CDDL
sockets described above. This registration mechanism will provide
for well-known index values for data items in CoSWID extensions,
allowing these index values to be recognized by implementations
supporting a given extension.
2.2. The concise-swid-tag Group
The CDDL data definition for the root concise-swid-tag map is as
follows and this rule and its constraints MUST be followed when
creating or validating a CoSWID tag:
concise-swid-tag = {
global-attributes,
tag-id => text,
tag-version => integer,
? corpus => bool,
? patch => bool,
? supplemental => bool,
swid-name => text,
? software-version => text,
? version-scheme => $version-scheme,
? media => text,
? software-meta => software-meta-entry / [ 2* software-meta-entry ],
entity => entity-entry / [ 2* entity-entry ],
? link => link-entry / [ 2* link-entry ],
? (( payload => payload-entry ) // ( evidence => evidence-entry )),
* $$coswid-extension
}
tag-id = 0
swid-name = 1
entity = 2
evidence = 3
link = 4
software-meta = 5
payload = 6
corpus = 8
patch = 9
media = 10
supplemental = 11
tag-version = 12
software-version = 13
version-scheme = 14
$version-scheme /= multipartnumeric
$version-scheme /= multipartnumeric-suffix
$version-scheme /= alphanumeric
$version-scheme /= decimal
$version-scheme /= semver
$version-scheme /= uint / text
multipartnumeric = 1
multipartnumeric-suffix = 2
alphanumeric = 3
decimal = 4
semver = 16384
The following describes each member of the concise-swid-tag root map.
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.4.
o tag-id (label 0): An textual identifier uniquely referencing a o tag-id (index 0): A 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], or a text string appended to a DNS (e.g. class 4 UUID) [RFC4122], or a text string appended to a DNS
domain name to ensure uniqueness across organizations. domain name to ensure uniqueness across organizations.
o tag-version (label 12): An integer value that indicates if a o tag-version (index 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 value is changed when a CoSWID tag
creates and releases an incorrect tag that they subsequently want producer creates and releases an incorrect tag that they
to fix, but no underlying changes have been made to the product subsequently want to fix, but no underlying changes have been made
the CoSWID tag represents. This could happen if, for example, a to the product the CoSWID tag represents. This could happen if,
patch is distributed that has a link reference that does not cover for example, a patch is distributed that has a link reference that
all the various software releases it can patch. A newer CoSWID does not cover all the various software releases it can patch. A
tag for that patch can be generated and the tag-version value newer CoSWID tag for that patch can be generated and the tag-
incremented to indicate that the data has been updated. version value incremented to indicate that the data has been
updated.
o corpus (label 8): A boolean value that indicates if the tag o corpus (index 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 (index 9): A boolean value that indicates if the tag
identifies and describes an installed patch which has made identifies and describes an installed patch which has made
incremental changes to a software component installed on a incremental changes to a software component installed on a
computing device. Typically, an installed patch has made a set of computing device. Typically, an installed patch has made a set of
file modifications to pre-installed software, and does not alter file modifications to pre-installed software, and does not alter
the version number or the descriptive metadata of an installed the version number or the descriptive metadata of an installed
software component. If a CoSWID tag is for a patch, it MUST software component. If a CoSWID tag is for a patch, the patch
contain the patch item and its value MUST be set to "true". If item MUST be set to "true". If not provided the default value
not provided the default value MUST be considered "false". MUST be considered "false".
o supplemental (label 11): A boolean value that indicates if the tag o supplemental (index 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 supplemental tag, it MUST contain component. If a CoSWID tag is a supplemental tag, the
the supplemental item and its value MUST be set to "true". If not supplemental item MUST be set to "true". If not provided the
provided the default value MUST be considered "false". default value MUST be considered "false".
o swid-name (label 1): This textual item provides the software o swid-name (index 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 (index 13): A textual value representing the
specific underlying release or development version of the software specific release or development version of the software component.
component.
o version-scheme (label 14): An 8-bit integer or textual value o version-scheme (index 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 SWID/CoSWID Version Schema Values Registry (see section
range: 32768-65,535. Section 5.2 or a value in the private use range: 32768-65535.
o media (label 10): This text value is a hint to the tag consumer to o media (index 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 [W3C.REC-css3-mediaqueries-20120619]).
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 map of key/value data o software-meta (index 5): An open-ended map of key/value data
pairs. A number of predefined keys can be used within this item pairs. A number of predefined keys can be used within this item
providing for common usage and semantics across the industry. The providing for common usage and semantics across the industry. The
data definition of this entry allows for any additional attribute data definition of this entry allows for any additional attribute
to be included, though it is recommended that industry norms for to be included, though it is recommended that industry norms for
new attributes are defined and followed to the degree possible. new attributes are defined and followed to the degree possible.
Described in Section 2.6. Described in Section 2.7.
o entity-entry (label 2): Provides information about one or more o entity (index 2): Provides information about one or more
organizations related to the software component referenced by this organizations related to the CoSWID tag or the software component
CoSWID tag. Described in Section 2.4. referenced by this CoSWID tag. Described in Section 2.5.
o link-entry (label 4): Provides a means to establish relationship o link (index 4): Provides a means to establish relationship arcs
arcs between the tag and another items. A given link can be used between the tag and another items. A given link can be used to
to establish the relationship between tags or to reference another establish the relationship between tags or to reference another
resource that is related to the CoSWID tag, e.g. vulnerability resource that is related to the CoSWID tag, e.g. vulnerability
database association, ROLIE feed , MUD resource , software database association, ROLIE feed [RFC8322], MUD resource
download location, etc). This is modeled after the HTML "link" [RFC8520], software download location, etc). This is modeled
element. Described in Section 2.5. after the HTML "link" element. Described in Section 2.6.
o payload-entry (label 6): This item represents the software o payload (index 6): This item represents the software artifacts
artifacts that may be installed on an endpoint when the software that compose the target software. For example, the files included
component is installed. Note that the payload may represent a with an installer for a corpus tag or installed on an endpoint
superset of the software artifacts installed. Based on user when the software component is installed for a primary or patch
selections at install time, an installation may not include every tag. Note that the payload can represent a superset of the
artifact that could be created or executed on the endpoint when software artifacts installed. Based on user selections at install
the software component is installed (i.e. if a particular optional time, an installation might not include every artifact that could
sub-component is not installed, the files associated with that be created or executed on the endpoint when the software component
software component may be included in payload, but not installed is installed (i.e. if a particular optional sub-component is not
in the system entity). Described in Section 2.7.3. installed, the files associated with that software component might
be included in payload, but not installed on the endpoint).
Described in Section 2.8.3.
o evidence-entry (label 3): This item is used to provide results o evidence (index 3): This item is used to provide results from a
from a scan of a system where software that does not have a CoSWID scan of a system where software that does not have a CoSWID tag is
tag is discovered. In such a case, a CoSWID tag may be created by discovered. In such a case, a CoSWID tag can be created by the
the discovery process when the endpoint is scanned. This item discovery process when the endpoint is scanned. This item
represents evidence for why software is believed to be installed represents evidence for why software is believed to be installed
on the endpoint. Described in Section 2.7.4. on the endpoint. Described in Section 2.8.4.
o any-element-entry (label 7): A default map that can contain
arbitrary map members and even nested maps (which would also be
any-elements). In essence, the any-element allows items not
defined in this CDDL data definition to be included in a Concise
Software Identifier. Described in [model-any-element].
2.1.1. Determining the tag type
The operational model for SWID and CoSWID tags was introduced in
Section 1.1. The following rules can be used to determine the type
of a CoSWID tag.
o Corpus Tag: A CoSWID tag MUST be considered a corpus tag if the
corpus item is "true".
o Primary Tag: A CoSWID tag MUST be considered a primary tag if the
corpus, patch, and supplemental items are "false".
o Patch Tag: A CoSWID tag MUST be considered a patch tag if the
patch item is "true" and the corpus item is "false".
o Supplemental Tag: A CoSWID tag MUST be considered a supplemental
tag if the supplemental item is set to "true".
A tag that does not match one of the above rules MUST be considered o $$coswid-extension: This CDDL socket is used to add new
an invalid, unsupported tag type. information structures to the concise-swid-tag root map. See
Section 2.1.
If a patch modifies the version number or the descriptive metadata of 2.3. concise-swid-tag Co-constraints
the software, then a new tag representing these details SHOULD be
installed, and the old tag SHOULD be removed.
2.1.2. concise-software-identity Co-constraints The following co-constraints apply to the information provided by in
the concise-swid-tag group.
o Only one of the patch and supplemental items MUST be set to o Only one of the patch and supplemental items MUST be set to
"true", or the patch and supplemental items MUST be set to "false" "true", or the patch and supplemental items MUST be set to "false"
or be omitted. or be omitted.
o If the patch item is set to "true", 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 item with the rel(ation) item value of "patches"
href item specifying an association with the software that was and an href item specifying an association with the software that
patched. was patched.
o If the supplemental item is set to "true", the tag SHOULD contain o If the supplemental item is set to "true", the tag SHOULD contain
at least one link with the rel(ation) item value of "supplements" at least one link item with the rel(ation) item value of
and an href item specifying an association with the software that "supplements" and an href item specifying an association with the
is supplemented. software that 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.4. 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
optional language definition to support the processing of text-string optional language definition to support the processing of text-string
values and an unbounded set of any-attribute items allowing for values and an unbounded set of any-attribute items allowing for
additional items to be provided as a general point of extension in additional items to be provided as a general point of extension in
the model. the model.
The CDDL for the global-attributes is as follows: The CDDL for the global-attributes follows:
global-attributes = ( global-attributes = (
? lang, ? lang,
* any-attribute, * any-attribute,
) )
label = text / int
any-attribute = ( any-attribute = (
label => text / int / [ 2* text ] / [ 2* int ] label => text / int / [ 2* text ] / [ 2* int ]
) )
The following describes each child item of this object. label = text / int
The following describes each child item of this group.
o lang (index 15): A textual language tag that conforms with IANA o lang (index 15): A textual language tag that conforms with IANA
Language Subtag Registry [RFC5646]. "Language Subtag Registry" [RFC5646]. The context of the
specified language applies to all sibling and descendant textual
values, unless a descendant object has defined a different
language tag. Thus, a new context is established when a
descendant object redefines a new language tag. All textual
values within a given context MUST be considered expressed in the
specified language.
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") value pairs. Labels can
keys and values can be either a single integer or text string, or be either a single integer or text string. Values can be either a
an array of integers or text strings. single integer or text string, or an array of integers or text
strings.
2.3. The media Object
The CDDL for the entity object is as follows:
media = (10: [ + [ media-expression,
? [ media-operation,
media-expression,
]
]
])
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.
o TBD
2.4. The entity Object 2.5. The entity-entry Group
The CDDL for the entity object is as follows: The CDDL for the entity-entry group follows:
entity = { entity-entry = {
global-attributes, global-attributes,
entity-name, entity-name => text,
? reg-id, ? reg-id => any-uri,
role, role => $role / [ 2* $role ],
? thumbprint, ? thumbprint => hash-entry,
* $$entity-extension, * $$entity-extension,
} }
entity-name = 31
reg-id = 32
role = 33
thumbprint = 34
The following describes each child item of this object. $role /= tag-creator
$role /= software-creator
$role /= aggregator
$role /= distributor
$role /= licensor
$role /= uint / text
tag-creator=1
software-creator=2
aggregator=3
distributor=4
licensor=5
The following describes each child item of this group.
o global-attributes: The global-attributes group described in o global-attributes: The global-attributes group described in
Section 2.2. Section 2.4.
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, specified by the role item, in the
CoSWID tag.
o reg-id (index 32): The registration id is intended to uniquely o reg-id (index 32): The registration id value is intended to
identify a naming authority in a given scope (e.g. global, uniquely identify a naming authority in a given scope (e.g.
organization, vendor, customer, administrative domain, etc.) for global, organization, vendor, customer, administrative domain,
the referenced naming authority. The value of an registration ID etc.) for the referenced entity. The value of an registration ID
MUST be a RFC 3986 URI. The scope SHOULD be the scope of an MUST be a RFC 3986 URI. The scope SHOULD be the scope of an
organization. In a given scope, the registration id MUST be used organization. In a given scope, the registration id MUST be used
consistently. consistently for CoSWID tag production.
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 an entity MAY include any role value, but this tag or the referenced software component. The role of an
the pre-defined roles include: "aggregator", "distributor", entity MAY include any role value, but the pre-defined roles
"licensor", "software-creator", and "tag-creator". These pre- include: "aggregator", "distributor", "licensor", "software-
defined role index and text values are defined in Section 3.2. creator", and "tag-creator". All pre-defined role index and text
Use of index values instead of text for these pre-defined roles values are defined in the IANA "SWID/CoSWID Entity Role Values"
allows a CoSWID to be more concise. registry Section 4.2. Use of index values instead of text for
these pre-defined roles allows a CoSWID to be more concise.
An entity item MUST be provided with the role of "tag-creator" for An entity item MUST be provided with the role of "tag-creator" for
every CoSWID tag. This indicates the organization that created every CoSWID tag. This indicates the organization that created
the CoSWID tag. the CoSWID tag.
An entity item SHOULD be provided with the role of "software-
creator" for every CoSWID tag, if this information is known to the
tag creator. This indicates the organization that created the
referenced software component.
o thumbprint (index 34): The value of the thumbprint item provides o thumbprint (index 34): The value of the thumbprint item provides
an integer-based hash algorithm identifier (hash-alg-id) and a an integer-based hash algorithm identifier (hash-alg-id) and a
byte string value (hash-value) that contains the corresponding 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 entity's public
certificate(s). If the hash-alg-id is not known, then the integer key certificate. This provides an indicator of which entity
value "0" MUST be used. This ensures parity between the SWID tag signed the CoSWID tag, which will typically be the tag creator.
specification [SWID], which does not allow an algorithm to be If the hash-alg-id is not known, then the integer value "0" MUST
identified for this field. See Section 2.7.1 for more details on be used. This ensures parity between the SWID tag specification
the use of the hash-entry data structure. [SWID], which does not allow an algorithm to be identified for
this field. See Section 2.8.1 for more details on the use of the
hash-entry data structure.
o $$entity-extension: This CDDL socket (see [I-D.ietf-cbor-cddl] o $$entity-extension: This CDDL socket can be used to extend the
section 3.9) can be used to extend the entity model, allowing entity-entry group model. See Section 2.1.
well-formed extensions to be defined in additional CDDL
descriptions.
2.5. The link Object 2.6. The link-entry Map
The CDDL for the link object is as follows: The CDDL for the link-entry map follows:
link = { link-entry = {
global-attributes, global-attributes,
? artifact, ? artifact => text,
href, href => any-uri,
? media ? media => text,
? ownership, ? ownership => $ownership,
rel, rel => $rel,
? media-type, ? media-type => text,
? use, ? use => $use,
* $$link-extension,
} }
media = 10
artifact = 37
href = 38
ownership = 39
rel = 40
media-type = 41
use = 42
The following describes each child item of this object. $ownership /= shared
$ownership /= private
$ownership /= abandon
$ownership /= uint / text
shared=1
private=2
abandon=3
$rel /= ancestor
$rel /= component
$rel /= feature
$rel /= installationmedia
$rel /= packageinstaller
$rel /= parent
$rel /= patches
$rel /= requires
$rel /= see-also
$rel /= supersedes
$rel /= rel-supplemental
$rel /= uint / text
ancestor=1
component=2
feature=3
installationmedia=4
packageinstaller=5
parent=6
patches=7
requires=8
see-also=9
supersedes=10
rel-supplemental=11
$use /= optional
$use /= required
$use /= recommended
$use /= uint / text
optional=1
required=2
recommended=3
The following describes each member of this map.
o global-attributes: The global-attributes group described in o global-attributes: The global-attributes group described in
Section 2.2. Section 2.4.
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. Links with the same artifact name SHOULD be
considered mirrors of each other, allowing the installation media considered mirrors of each other, allowing the installation media
to be downloaded from any of the described sources. to be acquired from any of the described sources.
o href (index 38): The link to the item being referenced. The o href (index 38): A URI for the item being referenced. The "href"
"href" item's value can point to several different things, and can item's value can point to several different things, and can be any
be any of the following: 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 acceptable URI scheme * a physical resource location with any acceptable URI 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 endpoint by software that can lookup other context of the endpoint by software that can lookup other
CoSWID 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 software components in the context of the system entity via software components
that can lookup other CoSWID tags and select the appropriate that can lookup other CoSWID tags and select the appropriate
tag based on an XPATH query. Examples include: tag based on an XPATH query [W3C.REC-xpath20-20101214].
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/ o media (index 10): A hint to the consumer of the link to what the
target item is applicable for. This item represents a query as
o media (index 10): See media defined in Section 2.3. defined by the W3C Media Queries Recommendation (see
[W3C.REC-css3-mediaqueries-20120619]). See also media defined in
Section 2.2.
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 between the software component referenced by the COSWID
abandon, private, shared tag and the software component referenced by the link. Valid
enumerations are: abandon, private, shared.
The enumerated values have the following meanings:
+-----------+-------------------------------------------------------+
| ownership | semantics |
+-----------+-------------------------------------------------------+
| abandon | If the software component referenced by the CoSWID |
| | tag is uninstalled, then the referenced software |
| | SHOULD not be uninstalled |
| | |
| private | If the software component referenced by the CoSWID |
| | tag is uninstalled, then the referenced software |
| | SHOULD be uninstalled too. |
| | |
| shared | If the software component referenced by the CoSWID |
| | tag is uninstalled, then the referenced software |
| | SHOULD be uninstalled if no other components sharing |
| | the software. |
+-----------+-------------------------------------------------------+
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 resource as defined by [RFC8288]. Relationships can be
IANA registration library: https://www.iana.org/assignments/link- identified by referencing a "Relation Name" from the IANA "Link
Relation Types" registry: 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 resource; o media-type (index 41): The media type for the target resource.
this provides the consumer with a hint of what type of resource to This provides the consumer with a hint of what type of resource to
expect. See http://www.iana.org/assignments/media-types/media- expect. Media types are identified by referencing a "Name" from
types.xhtml for more details. the IANA "Media Types" registry: http://www.iana.org/assignments/
media-types/media-types.xhtml.
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 to be installed before installing the tagged requirement or not to be installed before installing the tagged
software component. Valid enumerations are: required, software component. Valid enumerations are: required,
recommended, optional, which are defined in Section 3.3. recommended, optional, which are defined in Section 4.3.
2.6. The software-meta Object o $$link-extension: This CDDL socket can be used to extend the link-
entry map model. See Section 2.1.
The CDDL for the software-meta object is as follows: 2.7. The software-meta-entry Map
software-meta = { The CDDL for the software-meta-entry map follows:
software-meta-entry = {
global-attributes, global-attributes,
? activation-status, ? activation-status => text,
? channel-type, ? channel-type => text,
? colloquial-version, ? colloquial-version => text,
? description, ? description => text,
? edition, ? edition => text,
? entitlement-data-required, ? entitlement-data-required => bool,
? entitlement-key, ? entitlement-key => text,
? generator, ? generator => text,
? persistent-id, ? persistent-id => text,
? product, ? product => text,
? product-family, ? product-family => text,
? revision, ? revision => text,
? summary, ? summary => text,
? unspsc-code, ? unspsc-code => text,
? unspsc-version, ? unspsc-version => text,
* $$meta-extension,
} }
activation-status = 43
channel-type = 44
colloquial-version = 45
description = 46
edition = 47
entitlement-data-required = 48
entitlement-key = 49
generator = 50
persistent-id = 51
product = 52
product-family = 53
revision = 54
summary = 55
unspsc-code = 56
unspsc-version = 57
The following describes each child item of this object. The following describes each child item of this group.
o global-attributes: The global-attributes group described in o global-attributes: The global-attributes group described in
Section 2.2. Section 2.4.
o activation-status (index 43): Identification of the activation o activation-status (index 43): A textual value that identifies the
status of this software title (e.g. Trial, Serialized, Licensed, activation status of this software title (e.g. Trial, Serialized,
Unlicensed, etc). Typically, this is used in supplemental tags. Licensed, Unlicensed, etc). Typically, this is used in
supplemental tags.
o channel-type (index 44): Provides information on which channel o channel-type (index 44): A textual value that provides information
this particular software was targeted for (e.g. Volume, Retail, on which channel this particular software was targeted for (e.g.
OEM, Academic, etc). Typically used in supplemental tags.
o colloquial-version (index 45): The informal or colloquial version Volume, Retail, OEM, Academic, etc). Typically used in
of the product (i.e. 2013). Note that this version may be the supplemental tags.
same through multiple releases of a software component where the
version specified in entity is much more specific and will change
for each software release.
Note that this representation of version is typically used to o colloquial-version (index 45): A textual value for an informal or
identify a group of specific software releases that are part of colloquial version of the product (i.e. 2013). Note that this
the same release/support infrastructure (i.e. Fabrikam Office version can be the same through multiple releases of a software
2013). This version is used for string comparisons only and is component, while the software-version specified in the concise-
not compared to be an earlier or later release (that is done via swid-tag group is much more specific and will change for each
the entity version). software release. This representation of version is typically
used to identify a group of specific software releases that are
part of the same release/support infrastructure (i.e. Fabrikam
Office 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 concise-swid-tag group's software-version item).
o description (index 46): A longer, detailed description of the o description (index 46): A longer, detailed textual description of
software. This description can be multiple sentences the 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): A textual value indicating the variation of
Enterprise, Professional, Standard, etc). the product (e.g., Extended, Enterprise, Professional, Standard,
etc).
o entitlement-data-required (index 48): An indicator to determine if o entitlement-data-required (index 48): A boolean indicator to
there should be accompanying proof of entitlement when a software determine if accompanying proof of entitlement is needed when a
license reconciliation is completed. software 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
CoSWID tag. This item is typically used if tags are created on the CoSWID tag.
the fly or via a catalog-based analysis for data found on an
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 can be different
versions. versions.
o product (index 52): The base name of the product. 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): A textual value indicating the overall
software belongs to. Product family is not used to identify that product family this software belongs to. Product family is not
a product is part of a suite, but is instead used when a set of used to identify that a product is part of a suite, but is instead
products that are all related may be installed on multiple used when a set of products that are all related can be installed
different endpoints. For example, an enterprise backup system may on multiple different endpoints. For example, an enterprise
consist of a backup services, multiple different backup services backup system can consist of a backup services, multiple different
that support mail services, databases and ERP systems, as well as backup services that support mail services, databases and ERP
individual software components that backup client system entities. systems, as well as individual software components that backup
In such an usage scenario, all software components that are part client system entities. In such an usage scenario, all software
of the backup system would have the same product-family name so components that are part of the backup system would have the same
they can be grouped together in respect to reporting systems. product-family name so they can be grouped together in respect to
reporting systems.
o revision (index 54): The informal or colloquial representation of o revision (index 54): A textual value indicating the informal or
the sub-version of the given product (ie, SP1, R2, RC1, Beta 2, colloquial representation of the sub-version of the given product
etc). Note that the version item will provide very exact version (ie, SP1, R2, RC1, Beta 2, etc). Note that the software-version
details, while the revision is intended for use in environments specified in the concise-swid-tag group will provide very exact
where reporting on the informal or colloquial representation of version details. Conversely, the revision item is intended for
the software is important (for example, if for a certain business use in environments where reporting on the informal or colloquial
process, an organization recognizes that it must have, for example representation of the software is important. For example, when an
"ServicePack 1" or later of a specific product installed on all organization needs "ServicePack 1" or later of a specific product
devices, they can use the revision data value to quickly identify installed on all devices, they can use the revision data value to
any devices that do not meet this requirement). quickly identify any devices that do not meet this requirement.
Depending on how a software organizations distributes revisions, Depending on how a software organizations distributes revisions, this
this value could be specified in a primary (if distributed as an value could be specified in a primary (if distributed as an upgrade)
upgrade) or supplemental (if distributed as a patch) CoSWID tag. 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,
http://www.unspsc.org/. http://www.unspsc.org/.
2.7. The Resource Collection Definition o $$meta-extension: This CDDL socket can be used to extend the
software-meta-entry group model. See Section 2.1.
2.7.1. The hash-entry Array 2.8. The Resource Collection Definition
CoSWID add explicit support for the representation of hash entries 2.8.1. The hash-entry Array
using algorithms that are registered at the Named Information Hash
Algorithm Registry via the hash-entry member (label 58).
hash-entry = (58: [ hash-alg-id: int, hash-value: bstr ] ) 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-entry member (label 58).
hash-entry = [ hash-alg-id: int, hash-value: bytes, ]
The number used as a value for hash-alg-id MUST refer an ID in the The number used as a value for hash-alg-id MUST refer an ID in the
Named Information Hash Algorithm Registry; other hash algorithms MUST "Named Information Hash Algorithm Registry" (see
NOT be used. The hash-value MUST represent the raw hash value of the https://www.iana.org/assignments/named-information/named-
hashed resource generated using the hash algorithm indicated by the information.xhtml); other hash algorithms MUST NOT be used. The
hash-alg-id. hash-value MUST represent the raw hash value of the hashed resource
generated using the hash algorithm indicated by the hash-alg-id.
2.7.2. The resource-collection Group 2.8.2. The resource-collection Group
A list of items both used in evidence (discovered by an inventory A list of items both used in evidence (created by a software
process) and payload (installed in a system entity) content of a discovery process) and payload (installed in an endpoint) content of
CoSWID tag document to structure and differentiate the content of a CoSWID tag document to structure and differentiate the content of
specific CoSWID tag types. Potential content includes directories, specific CoSWID tag types. Potential content includes directories,
files, processes, resources or firmwares. files, processes, or resources.
The CDDL for the resource-collection group is as follows: The CDDL for the resource-collection group follows:
resource-collection = ( resource-collection = (
? directory-entry, ? directory => directory-entry,
? file-entry, ? file => file-entry,
? process-entry, ? process => process-entry,
? resource-entry ? resource => resource-entry,
) )
directory = { filesystem-item = (
global-attributes,
? key => bool,
? location => text,
fs-name => text,
? root => text,
)
path-elements-entry = [ [ * file-entry ],
[ * directory-entry ],
]
file-entry = {
filesystem-item, filesystem-item,
path-elements, ? size => integer,
? file-version => text,
? hash => hash-entry,
* $$file-extension
} }
file = { directory-entry = {
filesystem-item, filesystem-item,
? size, path-elements => path-elements-entry,
? file-version, * $$directory-extension
? hash-entry,
} }
process = { process-entry = {
global-attributes, global-attributes,
process-name, process-name => text,
? pid, ? pid => integer,
* $$process-extension
} }
resource = { resource-entry = {
global-attributes, global-attributes,
type, type => text,
* $$resource-extension
} }
filesystem-item = ( directory = 16
global-attributes, file = 17
? key, process = 18
? location, resource = 19
fs-name, size = 20
? root, file-version = 21
) key = 22
location = 23
fs-name = 24
root = 25
path-elements = 26
process-name = 27
pid = 28
type = 29
The following describes each child item or group for these groups. The following describes each member of the groups and maps
illustrated above.
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
Section 2.2. Section 2.4.
o directory-entry (index 16): A directory item allows one or more o directory (index 16): A directory item allows one or more
directories to be defined in the file structure. directories to be defined in the file structure.
o file-entry (index 17): A file element that allows one or more o file (index 17): A file item that allows one or more files to be
files to be specified for a given location. specified for a given location.
o process-entry (index 18): Provides process (software component in o process (index 18): Provides process (software component in
execution) information for data that will show up in a devices execution) information for data that will show up in a devices
process table. process list.
o resource-entry (index 19): A set of items that can be used to o resource (index 19): A set of items that can be used to provide
provide arbitrary resource information about an application arbitrary resource information about an application installed on
installed on a system entity, or evidence collected from a system in endpoint, or evidence collected from an endpoint.
entity.
o size (index 20): The file size in bytes of the file. o size (index 20): The size of the file in bytes.
o file-version (index 21): The version of the file. o file-version (index 21): The version of the file.
o key (index 22): Files that are considered important or required o key (index 22): A boolean indicator for when files or directories
for the use of a software component. Typical key files would be are considered important or required for the use of the software
those which, if not available on a system entity, would cause the component referenced by the CoSWID. Typical key files or
software component not to execute or function properly. Key files directories would be those which, if not available on an endpoint,
will typically be used to validate that a software component would cause the software component not to execute or function
referenced by the CoSWID tag document is actually installed on a properly. Key files or directories will typically be used to
specific system entity. validate that the software component referenced by the CoSWID tag
is actually installed on a specific endpoint.
o location (index 23): The directory or location where a file was o location (index 23): The location where a file was found or can
found or can expected to be located. This text-string is intended expected to be located. This text-string is intended to include
to include the filename itself. This SHOULD be the relative path the filename itself. This SHOULD be the relative path from the
from the location represented by the root item. location represented by the root item or if the root item is
omitted be relative to the location of the CoSWID tag.
o fs-name (index 24): The file name or directory name without any o fs-name (index 24): The file name or directory name without any
path characters. path characters.
o root (index 25): A system-specific root folder that the location o root (index 25): A system-specific root folder that the location
item is an offset from. If this is not specified the assumption item is an offset from. If this is not specified the assumption
is the root is the same folder as the location of the CoSWID tag. is the root is the same folder as the location of the CoSWID tag.
The text-string value represents a path expression relative to the The text-string value represents a path expression relative to the
CoSWID tag document location in the (composite) file-system CoSWID tag document location in the (composite) file-system
hierarchy. hierarchy.
o path-elements (index 26): Provides the ability to apply a o path-elements (index 26): This group provides the ability to apply
directory structure to the path expressions for files defined in a a directory structure to the path expressions for files defined in
payload or evidence item. a payload or evidence items.
o process-name (index 27): The process name as it will be found in o process-name (index 27): The process name as it will be found in
the system entity's process table. the endpoint's process table.
o pid (index 28): The process ID for the process in execution that o pid (index 28): The process ID for the process in execution that
can be included in the process item as part of an evidence tag. can be included in the process item as part of an evidence tag.
o type (index 29): The type of resource represented via a text- o type (index 29): The type of resource represented via a text-
string (typically, registry-key, port or root-uri). string (typically, registry-key, port or root-uri).
2.7.3. The payload Object o $$resource-collection-extension: This CDDL socket can be used to
extend the resource-collection group model. This can be used to
add new specialized types of resources. See Section 2.1.
The CDDL for the payload object is as follows: o $$file-extension: This CDDL socket can be used to extend the file-
entry group model. See Section 2.1.
payload = { o $$directory-extension: This CDDL socket can be used to extend the
directory-entry group model. See Section 2.1.
o $$process-extension: This CDDL socket can be used to extend the
process-entry group model. See Section 2.1.
o $$resource-extension: This CDDL socket can be used to extend the
group model. See Section 2.1.
o $$-extension: This CDDL socket can be used to extend the resource-
entry group model. See Section 2.1.
2.8.3. The payload-entry Group
The CDDL for the payload-entry group follows:
payload-entry = {
global-attributes, global-attributes,
resource-collection, resource-collection,
* $$payload-extension * $$payload-extension
} }
The following describes each child item of this object. The following describes each child item of this group.
o global-attributes: The global-attributes group described in o global-attributes: The global-attributes group described in
Section 2.2. Section 2.4.
o resource-collection: The resource-collection group described in o resource-collection: The resource-collection group described in
Section 2.7.2. Section 2.8.2.
o $$payload-extension: This CDDL socket (see [I-D.ietf-cbor-cddl] o $$payload-extension: This CDDL socket can be used to extend the
section 3.9) can be used to extend the payload model, allowing payload-entry group model. See Section 2.1.
well-formed extensions to be defined in additional CDDL
descriptions.
2.7.4. The evidence Object 2.8.4. The evidence-entry Group
The CDDL for the evidence object is as follows: The CDDL for the evidence-entry group follows:
evidence = { evidence-entry = {
global-attributes, global-attributes,
resource-collection, resource-collection,
? date, ? date => time,
? device-id, ? device-id => text,
* $$evidence-extension * $$evidence-extension
} }
date = (35: time) date = 35
device-id = (36: text) device-id = 36
The following describes each child item of this object. The following describes each child item of this group.
o global-attributes: The global-attributes group described in o global-attributes: The global-attributes group described in
Section 2.2. Section 2.4.
o resource-collection: The resource-collection group described in o resource-collection: The resource-collection group described in
Section 2.7.2. Section 2.8.2.
o date (index 35): The date and time evidence represented by an o date (index 35): The date and time evidence represented by an
evidence item was gathered. evidence item was gathered.
o device-id (index 36): A text-string identifier for a device o device-id (index 36): A textual identifier for a device evidence
evidence was gathered from. was gathered from.
o $$evidence-extension: This CDDL socket (see [I-D.ietf-cbor-cddl] o $$evidence-extension: This CDDL socket can be used to extend the
section 3.9) can be used to extend the evidence model, allowing evidence-entry group model. See Section 2.1.
well-formed extensions to be defined in additional CDDL
descriptions.
2.8. Full CDDL Definition 2.9. Full CDDL Definition
In order to create a valid CoSWID document the structure of the In order to create a valid CoSWID document the structure of the
corresponding CBOR message MUST adhere to the following CDDL data corresponding CBOR message MUST adhere to the following CDDL data
definition. definition.
concise-software-identity = { concise-swid-tag = {
global-attributes, global-attributes,
tag-id, tag-id => text,
tag-version, tag-version => integer,
? corpus, ? corpus => bool,
? patch, ? patch => bool,
? supplemental, ? supplemental => bool,
swid-name, swid-name => text,
? software-version, ? software-version => text,
? version-scheme, ? version-scheme => $version-scheme,
? media, ? media => text,
? software-meta-entry, ? software-meta => software-meta-entry / [ 2* software-meta-entry ],
entity-entry, entity => entity-entry / [ 2* entity-entry ],
? link-entry, ? link => link-entry / [ 2* link-entry ],
? ( payload-entry // evidence-entry ), ? (( payload => payload-entry ) // ( evidence => evidence-entry )),
* $$coswid-extension * $$coswid-extension
} }
any-uri = text
label = text / int
any-attribute = ( any-uri = text
label => text / int / [ 2* text ] / [ 2* int ] label = text / int
)
global-attributes = ( $version-scheme /= multipartnumeric
? lang, $version-scheme /= multipartnumeric-suffix
* any-attribute, $version-scheme /= alphanumeric
$version-scheme /= decimal
$version-scheme /= semver
$version-scheme /= uint / text
) any-attribute = (
label => text / int / [ 2* text ] / [ 2* int ]
)
resource-collection = ( global-attributes = (
? directory-entry, ? lang => text,
? file-entry, * any-attribute,
? process-entry, )
? resource-entry
)
file = { hash-entry = [ hash-alg-id: int,
filesystem-item, hash-value: bytes,
? size, ]
? file-version,
? hash-entry,
}
filesystem-item = ( entity-entry = {
global-attributes, global-attributes,
? key, entity-name => text,
? location, ? reg-id => any-uri,
fs-name, role => $role / [ 2* $role ],
? root, ? thumbprint => hash-entry,
) * $$entity-extension,
}
directory = { $role /= tag-creator
filesystem-item, $role /= software-creator
path-elements, $role /= aggregator
} $role /= distributor
$role /= licensor
$role /= uint / text
process = { link-entry = {
global-attributes, global-attributes,
process-name, ? artifact => text,
? pid, href => any-uri,
} ? media => text,
? ownership => $ownership,
rel => $rel,
? media-type => text,
? use => $use,
* $$link-extension
}
resource = { $ownership /= shared
global-attributes, $ownership /= private
type, $ownership /= abandon
} $ownership /= uint / text
entity = { $rel /= ancestor
global-attributes, $rel /= component
entity-name, $rel /= feature
? reg-id, $rel /= installationmedia
role, $rel /= packageinstaller
? thumbprint, $rel /= parent
* $$entity-extension, $rel /= patches
} $rel /= requires
evidence = { $rel /= see-also
global-attributes, $rel /= supersedes
resource-collection, $rel /= rel-supplemental
? date, $rel /= uint / text
? device-id,
* $$evidence-extension
}
link = { $use /= optional
global-attributes, $use /= required
? artifact, $use /= recommended
href, $use /= uint / text
? media
? ownership,
rel,
? media-type,
? use,
}
software-meta = { software-meta-entry = {
global-attributes, global-attributes,
? activation-status, ? activation-status => text,
? channel-type, ? channel-type => text,
? colloquial-version, ? colloquial-version => text,
? description, ? description => text,
? edition, ? edition => text,
? entitlement-data-required, ? entitlement-data-required => bool,
? entitlement-key, ? entitlement-key => text,
? generator, ? generator => text,
? persistent-id, ? persistent-id => text,
? product, ? product => text,
? product-family, ? product-family => text,
? revision, ? revision => text,
? summary, ? summary => text,
? unspsc-code, ? unspsc-code => text,
? unspsc-version, ? unspsc-version => text,
} * $$meta-extension,
}
resource-collection = (
? directory => directory-entry,
? file => file-entry,
? process => process-entry,
? resource => resource-entry,
* $$resource-collection-extension
)
payload = { file-entry = {
global-attributes, filesystem-item,
resource-collection, ? size => integer,
* $$payload-extension ? file-version => text,
} ? hash => hash-entry,
* $$file-extension
}
tag-id = (0: text) path-elements-entry = [ [ * file-entry ],
swid-name = (1: text) [ * directory-entry ],
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)
corpus = (8: bool)
patch = (9: bool)
media = (10: [ + [ media-expression,
? [ media-operation,
media-expression,
] ]
]
])
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
supplemental = (11: bool)
tag-version = (12: integer)
software-version = (13: text)
version-scheme = (14: version-schemes / extended-value)
version-schemes = multipartnumeric / multipartnumeric-suffix / alphanumeric / decimal / semver
multipartnumeric = 1
multipartnumeric-suffix = 2
alphanumeric = 3
decimal = 4
semver = 16384
lang = (15: text)
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)
entity-name = (31: text)
reg-id = (32: any-uri)
role = (33: roles / extended-value / [ 2* roles / extended-value ] )
extended-value = text / uint
roles= aggregator / distributor / licensor / software-creator / tag-creator
aggregator=0
distributor=1
licensor=2
software-creator=3
tag-creator=4
thumbprint = (34: [ hash-alg-id: int,
hash-value: bstr,
]
)
date = (35: time)
device-id = (36: text)
artifact = (37: text)
href = (38: any-uri)
ownership = (39: shared / private / abandon / extended-value )
shared=0
private=1
abandon=2
rel = (40: rels / extended-value )
rels = ancestor / component / feature / installationmedia / packageinstaller / parent / patches / requires / see-also / supersedes / rel-supplemental
ancestor=0
component=1
feature=2
installationmedia=3
packageinstaller=4
parent=5
patches=6
requires=7
see-also=8
supersedes=9
rel-supplemental=10
media-type = (41: text)
use = (42: optional / required / recommended / extended-value )
optional=1
required=2
recommended=3
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)
hash-entry = (58: [ hash-alg-id: int,
hash-value: bstr,
]
)
3. CoSWID Indexed Label Values directory-entry = {
filesystem-item,
path-elements => path-elements-entry,
* $$directory-extension
}
3.1. Version Scheme process-entry = {
global-attributes,
process-name => text,
? pid => integer,
* $$process-extension
}
The following table contains an initial set of values for use in the resource-entry = {
version-scheme item for the version schemes defined in the ISO/IEC global-attributes,
19770-2:2015 [SWID] specification. Index value in parens indicates type => text,
the index value to use in the version-scheme item. * $$resource-extension
}
filesystem-item = (
global-attributes,
? key => bool,
? location => text,
fs-name => text,
? root => text,
)
payload-entry = {
global-attributes,
resource-collection,
* $$payload-extension
}
evidence-entry = {
global-attributes,
resource-collection,
? date => time,
? device-id => text,
* $$evidence-extension
}
; "global map member" integer indexes
tag-id = 0
swid-name = 1
entity = 2
evidence = 3
link = 4
software-meta = 5
payload = 6
hash = 7
corpus = 8
patch = 9
media = 10
supplemental = 11
tag-version = 12
software-version = 13
version-scheme = 14
lang = 15
directory = 16
file = 17
process = 18
resource = 19
size = 20
file-version = 21
key = 22
location = 23
fs-name = 24
root = 25
path-elements = 26
process-name = 27
pid = 28
type = 29
entity-name = 31
reg-id = 32
role = 33
thumbprint = 34
date = 35
device-id = 36
artifact = 37
href = 38
ownership = 39
rel = 40
media-type = 41
use = 42
activation-status = 43
channel-type = 44
colloquial-version = 45
description = 46
edition = 47
entitlement-data-required = 48
entitlement-key = 49
generator = 50
persistent-id = 51
product = 52
product-family = 53
revision = 54
summary = 55
unspsc-code = 56
unspsc-version = 57
; "version-scheme" integer indexes
multipartnumeric = 1
multipartnumeric-suffix = 2
alphanumeric = 3
decimal = 4
semver = 16384
; "role" integer indexes
tag-creator=1
software-creator=2
aggregator=3
distributor=4
licensor=5
; ownership integer indexes
shared=1
private=2
abandon=3
; "rel" integer indexes
ancestor=1
component=2
feature=3
installationmedia=4
packageinstaller=5
parent=6
patches=7
requires=8
see-also=9
supersedes=10
rel-supplemental=11
; "use" integer indexes
optional=1
required=2
recommended=3
3. Determining the Type of CoSWID
The operational model for SWID and CoSWID tags was introduced in
Section 1.1, which described four different CoSWID tag types. The
following additional rules apply to the use of CoSWID tags to ensure
that created tags properly identify the tag type.
The first matching rule MUST determine the type of the CoSWID tag.
1. Primary Tag: A CoSWID tag MUST be considered a primary tag if the
corpus, patch, and supplemental items are "false".
2. Supplemental Tag: A CoSWID tag MUST be considered a supplemental
tag if the supplemental item is set to "true".
3. Corpus Tag: A CoSWID tag MUST be considered a corpus tag if the
corpus item is "true".
4. Patch Tag: A CoSWID tag MUST be considered a patch tag if the
patch item is "true".
4. CoSWID Indexed Label Values
4.1. Version Scheme
The following table contains a set of values for use in the concise-
swid-tag group's version-scheme item. These values match the version
schemes defined in the ISO/IEC 19770-2:2015 [SWID] specification.
Index value indicates the value to use as the version-scheme item's
value. The Version Scheme Name provides human-readable text for the
value. The Definition describes the syntax of allowed values for
each entry.
+-------+-------------------------+---------------------------------+ +-------+-------------------------+---------------------------------+
| Index | Role Name | Definition | | Index | Version Scheme Name | Definition |
+-------+-------------------------+---------------------------------+ +-------+-------------------------+---------------------------------+
| 0 | Reserved | |
| | | |
| 1 | multipartnumeric | Numbers separated by dots, | | 1 | multipartnumeric | Numbers separated by dots, |
| | | where the numbers are | | | | where the numbers are |
| | | interpreted as integers | | | | interpreted as integers |
| | | (e.g.,1.2.3, 1.4.5, | | | | (e.g.,1.2.3, 1.4.5, |
| | | 1.2.3.4.5.6.7) | | | | 1.2.3.4.5.6.7) |
| | | | | | | |
| 2 | multipartnumeric+suffix | Numbers separated by dots, | | 2 | multipartnumeric+suffix | Numbers separated by dots, |
| | | where the numbers are | | | | where the numbers are |
| | | interpreted as integers with an | | | | interpreted as integers with an |
| | | additional string suffix(e.g., | | | | additional textual suffix |
| | | 1.2.3a) | | | | (e.g., 1.2.3a) |
| | | | | | | |
| 3 | alphanumeric | Strictly a string, sorting is | | 3 | alphanumeric | Strictly a string, sorting is |
| | | done alphanumerically | | | | done alphanumerically |
| | | | | | | |
| 4 | decimal | A floating point number (e.g., | | 4 | decimal | A floating point number (e.g., |
| | | 1.25 is less than 1.3) | | | | 1.25 is less than 1.3) |
| | | | | | | |
| 16384 | semver | Follows the [SEMVER] | | 16384 | semver | Follows the [SEMVER] |
| | | specification | | | | specification |
+-------+-------------------------+---------------------------------+ +-------+-------------------------+---------------------------------+
The values above are registered in the "SWID/CoSWID Version Schema
Values" registry defined in section Section 4.1. Additional valid The values above are registered in the IANA "SWID/CoSWID Version
values will likely be registered over time in this registry. Schema Values" registry defined in section Section 5.2. Additional
entires will likely be registered over time in this registry.
Additionally, the index values 32768 through 65535 have been reserved Additionally, the index values 32768 through 65535 have been reserved
for private use. for private use.
3.2. Entity Role Values 4.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. entry group's role item (see Section 2.5). These values match the
entity roles defined in the ISO/IEC 19770-2:2015 [SWID]
specification. Index value indicates the value to use as the role
item's value. The Role Name provides human-readable text for the
value. The Definition describes the semantic meaning of each entry.
| Index | Role Name | Definition |-- | 0 | Reserved | | 1 | +-------+-----------------+-----------------------------------------+
tagCreator | The person or organization that created the containing | Index | Role Name | Definition |
SWID or CoSWID tag | 2 | softwareCreator | From [SAM], "person or +-------+-----------------+-----------------------------------------+
organization that creates a software product (3.46) or package" | 3 | | 1 | tagCreator | The person or organization that created |
aggregator | From {{SWID}, "An organization or system that | | | the containing SWID or CoSWID tag |
encapsulates software from their own and/or other organizations into | | | |
a different distribution process (as in the case of virtualization), | 2 | softwareCreator | From [SAM], "person or organization |
or as a completed system to accomplish a specific task (as in the | | | that creates a software product (3.46) |
case of a value added reseller)." | 4 | distributor | From [SWID], | | | or package" |
"An entity that furthers the marketing, selling and/or distribution | | | |
of software from the original place of manufacture to the ultimate | 3 | aggregator | From {{SWID}, "An organization or |
user without modifying the software, its packaging or its | | | system that encapsulates software from |
labelling." | 5 | licensor | From [SAM] as "software licensor", | | | their own and/or other organizations |
"person or organization who owns or holds the rights to issue a | | | into a different distribution process |
software license for a specific software package" | | | (as in the case of virtualization), or |
| | | as a completed system to accomplish a |
| | | specific task (as in the case of a |
| | | value added reseller)." |
| | | |
| 4 | distributor | From [SWID], "An entity that furthers |
| | | the marketing, selling and/or |
| | | distribution of software from the |
| | | original place of manufacture to the |
| | | ultimate user without modifying the |
| | | software, its packaging or its |
| | | labelling." |
| | | |
| 5 | licensor | From [SAM] as "software licensor", a |
| | | "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 IANA "SWID/CoSWID Entity Role
Values" registry defined in section Section 4.2. Additional valid Values" registry defined in section Section 5.3. Additional valid
values will likely be registered over time. Additionally, the index values will likely be registered over time. Additionally, the index
values 128 through 255 have been reserved for private use. values 128 through 255 have been reserved for private use.
3.3. Use Values 4.3. Use Values
The following table indicates the index value to use for the link use The following table indicates the index value to use for the link-
item (see Section 2.5), which is also defined in the ISO/IEC entry group's use item (see Section 2.6). These values match the
19770-2:2015 [SWID] specification. link use values defined in the ISO/IEC 19770-2:2015 [SWID]
specification. Index value indicates the value to use as the link-
entry group use item's value. The Use Type provides human-readable
text for the value. The Definition describes the semantic meaning of
each entry.
+-------+-------------+---------------------------------------------+ +-------+-------------+---------------------------------------------+
| Index | Use Type | Definition | | Index | Use Type | Definition |
+-------+-------------+---------------------------------------------+ +-------+-------------+---------------------------------------------+
| 0 | Reserved | | | 1 | optional | From [SWID], "Not absolutely required; the |
| | | |
| 1 | optional | From {{SWID}, "Not absolutely required; the |
| | | [Link]'d software is installed only when | | | | [Link]'d software is installed only when |
| | | specified." | | | | specified." |
| | | | | | | |
| 2 | required | From {{SWID}, "The [Link]'d software is | | 2 | required | From [SWID], "The [Link]'d software is |
| | | absolutely required for an operation | | | | absolutely required for an operation |
| | | software installation." | | | | software installation." |
| | | | | | | |
| 3 | recommended | From {{SWID}, "Not absolutely required; the | | 3 | recommended | From [SWID], "Not absolutely required; the |
| | | [Link]'d software is installed unless | | | | [Link]'d software is installed unless |
| | | specified otherwise." | | | | specified otherwise." |
+-------+-------------+---------------------------------------------+ +-------+-------------+---------------------------------------------+
The values above are registered in the "SWID/CoSWID Link Use Values" The values above are registered in the IANA "SWID/CoSWID Link Use
registry defined in section Section 4.3. Additional valid values Values" registry defined in section Section 5.4. Additional valid
will likely be registered over time. Additionally, the index values values will likely be registered over time. Additionally, the index
128 through 255 have been reserved for private use. values 128 through 255 have been reserved for private use.
4. IANA Considerations 5. IANA Considerations
This document will include requests to IANA: This document has a number of IANA considerations, as described in
the following subsections.
o Integer indices for SWID content attributes and information 5.1. CoSWID Items Registry
elements.
o Content-Type for CoAP to be used in COSE. This document uses integer values as index values in CBOR maps.
This document has a number of IANA considerations, as described in This document defines a new a new registry titled "CoSWID Items".
the following subsections. Future registrations for this registry are to be made based on
[RFC8126] as follows:
4.1. SWID/CoSWID Version Schema Values Registry +------------------+-------------------------+
| Range | Registration Procedures |
+------------------+-------------------------+
| 0-32767 | Standards Action |
| | |
| 32768-4294967295 | Specification Required |
+------------------+-------------------------+
All negative values are reserved for Private Use.
Initial registrations for the "CoSWID Items" registry are provided
below. Assignments consist of an integer index value, the item name,
and a reference to the defining specification.
+---------------+---------------------------+---------------+
| Index | Item Name | Specification |
+---------------+---------------------------+---------------+
| 0 | tag-id | RFC-AAAA |
| | | |
| 1 | swid-name | RFC-AAAA |
| | | |
| 2 | entity | RFC-AAAA |
| | | |
| 3 | evidence | RFC-AAAA |
| | | |
| 4 | link | RFC-AAAA |
| | | |
| 5 | software-meta | RFC-AAAA |
| | | |
| 6 | payload | RFC-AAAA |
| | | |
| 7 | hash | RFC-AAAA |
| | | |
| 8 | corpus | RFC-AAAA |
| | | |
| 9 | patch | RFC-AAAA |
| | | |
| 10 | media | RFC-AAAA |
| | | |
| 11 | supplemental | RFC-AAAA |
| | | |
| 12 | tag-version | RFC-AAAA |
| | | |
| 13 | software-version | RFC-AAAA |
| | | |
| 14 | version-scheme | RFC-AAAA |
| | | |
| 15 | lang | RFC-AAAA |
| | | |
| 16 | directory | RFC-AAAA |
| | | |
| 17 | file | RFC-AAAA |
| | | |
| 18 | process | RFC-AAAA |
| | | |
| 19 | resource | RFC-AAAA |
| | | |
| 20 | size | RFC-AAAA |
| | | |
| 21 | file-version | RFC-AAAA |
| | | |
| 22 | key | RFC-AAAA |
| | | |
| 23 | location | RFC-AAAA |
| | | |
| 24 | fs-name | RFC-AAAA |
| | | |
| 25 | root | RFC-AAAA |
| | | |
| 26 | path-elements | RFC-AAAA |
| | | |
| 27 | process-name | RFC-AAAA |
| | | |
| 28 | pid | RFC-AAAA |
| | | |
| 29 | type | RFC-AAAA |
| | | |
| 31 | entity-name | RFC-AAAA |
| | | |
| 32 | reg-id | RFC-AAAA |
| | | |
| 33 | role | RFC-AAAA |
| | | |
| 34 | thumbprint | RFC-AAAA |
| | | |
| 35 | date | RFC-AAAA |
| | | |
| 36 | device-id | RFC-AAAA |
| | | |
| 37 | artifact | RFC-AAAA |
| | | |
| 38 | href | RFC-AAAA |
| | | |
| 39 | ownership | RFC-AAAA |
| | | |
| 40 | rel | RFC-AAAA |
| | | |
| 41 | media-type | RFC-AAAA |
| | | |
| 42 | use | RFC-AAAA |
| | | |
| 43 | activation-status | RFC-AAAA |
| | | |
| 44 | channel-type | RFC-AAAA |
| | | |
| 45 | colloquial-version | RFC-AAAA |
| | | |
| 46 | description | RFC-AAAA |
| | | |
| 47 | edition | RFC-AAAA |
| | | |
| 48 | entitlement-data-required | RFC-AAAA |
| | | |
| 49 | entitlement-key | RFC-AAAA |
| | | |
| 50 | generator | RFC-AAAA |
| | | |
| 51 | persistent-id | RFC-AAAA |
| | | |
| 52 | product | RFC-AAAA |
| | | |
| 53 | product-family | RFC-AAAA |
| | | |
| 54 | revision | RFC-AAAA |
| | | |
| 55 | summary | RFC-AAAA |
| | | |
| 56 | unspsc-code | RFC-AAAA |
| | | |
| 57 | unspsc-version | RFC-AAAA |
| | | |
| 58-4294967295 | Unassigned | |
+---------------+---------------------------+---------------+
5.2. SWID/CoSWID Version Schema Values Registry
This document uses unsigned 16-bit index values to version-scheme This document uses unsigned 16-bit index values to version-scheme
item values. The initial set of version-scheme values are derived item values. The initial set of version-scheme values are derived
from the textual version scheme names defined in the ISO/IEC from the textual version scheme names defined in the ISO/IEC
19770-2:2015 specification [SWID]. 19770-2:2015 specification [SWID].
This document defines a new a new registry entitled "SWID/CoSWID This document defines a new a new registry titled "SWID/CoSWID
Version Schema Values". Future registrations for this registry are Version Schema Values". Future registrations for this registry are
to be made based on [RFC8126] as follows: to be made based on [RFC8126] as follows:
[TO BE REMOVED: This registration should take place at the following
location: https://www.iana.org/assignments/swid]
+-------------+--------------------------+ +-------------+--------------------------+
| Range | Registration Procedures | | Range | Registration Procedures |
+-------------+--------------------------+ +-------------+--------------------------+
| 0-16383 | Standards Action | | 0-16383 | Standards Action |
| | | | | |
| 16384-32767 | Specification Required | | 16384-32767 | Specification Required |
| | | | | |
| 32768-65535 | Reserved for Private Use | | 32768-65535 | Reserved for Private Use |
+-------------+--------------------------+ +-------------+--------------------------+
Initial registrations for the SWID/CoSWID Version Schema Values Initial registrations for the "SWID/CoSWID Version Schema Values"
registry are provided below. registry are provided below. Assignments consist of an integer index
value, the version scheme name, and a reference to the defining
specification.
+-------------+--------------------------+-----------------+ +-------------+--------------------------+-----------------+
| Index | Role Name | Specification | | Index | Version Scheme Name | Specification |
+-------------+--------------------------+-----------------+ +-------------+--------------------------+-----------------+
| 0 | Reserved | | | 0 | Reserved | |
| | | | | | | |
| 1 | multipartnumeric | See Section 3.1 | | 1 | multipartnumeric | See Section 4.1 |
| | | | | | | |
| 2 | multipartnumeric+suffix | See Section 3.1 | | 2 | multipartnumeric+suffix | See Section 4.1 |
| | | | | | | |
| 3 | alphanumeric | See Section 3.1 | | 3 | alphanumeric | See Section 4.1 |
| | | | | | | |
| 4 | decimal | See Section 3.1 | | 4 | decimal | See Section 4.1 |
| | | | | | | |
| 5-16383 | Unassigned | | | 5-16383 | Unassigned | |
| | | | | | | |
| 16384 | semver | [SEMVER] | | 16384 | semver | [SEMVER] |
| | | | | | | |
| 16385-32767 | Unassigned | | | 16385-32767 | Unassigned | |
| | | | | | | |
| 32768-65535 | Reserved for Private Use | | | 32768-65535 | Reserved for Private Use | |
+-------------+--------------------------+-----------------+ +-------------+--------------------------+-----------------+
4.2. SWID/CoSWID Entity Role Values Registry 5.3. SWID/CoSWID Entity Role Values Registry
This document uses unsigned 8-bit index values to represent entity- This document uses unsigned 8-bit index values to represent entity-
role values. The initial set of Entity roles are derived from the role values. The initial set of Entity roles are derived from the
textual role names defined in the ISO/IEC 19770-2:2015 specification textual role names defined in the ISO/IEC 19770-2:2015 specification
[SWID]. [SWID].
This document defines a new a new registry entitled "SWID/CoSWID This document defines a new a new registry titled "SWID/CoSWID Entity
Entity Role Values". Future registrations for this registry are to Role Values". Future registrations for this registry are to be made
be made based on [RFC8126] as follows: based on [RFC8126] as follows:
[TO BE REMOVED: This registration should take place at the following
location: https://www.iana.org/assignments/swid]
+---------+--------------------------+ +---------+--------------------------+
| Range | Registration Procedures | | Range | Registration Procedures |
+---------+--------------------------+ +---------+--------------------------+
| 0-31 | Standards Action | | 0-31 | Standards Action |
| | | | | |
| 32-127 | Specification Required | | 32-127 | Specification Required |
| | | | | |
| 128-255 | Reserved for Private Use | | 128-255 | Reserved for Private Use |
+---------+--------------------------+ +---------+--------------------------+
Initial registrations for the SWID/CoSWID Entity Role Values registry Initial registrations for the "SWID/CoSWID Entity Role Values"
are provided below. registry are provided below. Assignments consist of an integer index
value, a role name, and a reference to the defining specification.
+---------+--------------------------+-----------------+ +---------+--------------------------+-----------------+
| Index | Role Name | Specification | | Index | Role Name | Specification |
+---------+--------------------------+-----------------+ +---------+--------------------------+-----------------+
| 0 | Reserved | | | 0 | Reserved | |
| | | | | | | |
| 1 | tagCreator | See Section 3.2 | | 1 | tagCreator | See Section 4.2 |
| | | | | | | |
| 2 | softwareCreator | See Section 3.2 | | 2 | softwareCreator | See Section 4.2 |
| | | | | | | |
| 3 | aggregator | See Section 3.2 | | 3 | aggregator | See Section 4.2 |
| | | | | | | |
| 4 | distributor | See Section 3.2 | | 4 | distributor | See Section 4.2 |
| | | | | | | |
| 5 | licensor | See Section 3.2 | | 5 | licensor | See Section 4.2 |
| | | | | | | |
| 6-31 | Unassigned | | | 6-31 | Unassigned | |
| | | | | | | |
| 32-127 | Unassigned | | | 32-127 | Unassigned | |
| | | | | | | |
| 128-255 | Reserved for Private Use | | | 128-255 | Reserved for Private Use | |
+---------+--------------------------+-----------------+ +---------+--------------------------+-----------------+
4.3. SWID/CoSWID Link Use Values Registry 5.4. SWID/CoSWID Link Use Values Registry
This document uses unsigned 8-bit index values to represent link-use This document uses unsigned 8-bit index values to represent link-use
values. The initial set of Link use values are derived from the values. The initial set of Link use values are derived from the
textual names defined in the ISO/IEC 19770-2:2015 specification textual names defined in the ISO/IEC 19770-2:2015 specification
[SWID]. [SWID].
This document defines a new a new registry entitled "SWID/CoSWID Link This document defines a new a new registry titled "SWID/CoSWID Link
Use Values". Future registrations for this registry are to be made Use Values". Future registrations for this registry are to be made
based on [RFC8126] as follows: based on [RFC8126] as follows:
[TO BE REMOVED: This registration should take place at the following
location: https://www.iana.org/assignments/swid]
+---------+--------------------------+ +---------+--------------------------+
| Range | Registration Procedures | | Range | Registration Procedures |
+---------+--------------------------+ +---------+--------------------------+
| 0-31 | Standards Action | | 0-31 | Standards Action |
| | | | | |
| 32-127 | Specification Required | | 32-127 | Specification Required |
| | | | | |
| 128-255 | Reserved for Private Use | | 128-255 | Reserved for Private Use |
+---------+--------------------------+ +---------+--------------------------+
Initial registrations for the SWID/CoSWID Entity Role Values registry Initial registrations for the "SWID/CoSWID Entity Role Values"
are provided below. registry are provided below. Assignments consist of an integer index
value, the link use name, and a reference to the defining
specification.
+---------+--------------------------+-----------------+ +---------+--------------------------+-----------------+
| Index | Role Name | Specification | | Index | Link Use Name | Specification |
+---------+--------------------------+-----------------+ +---------+--------------------------+-----------------+
| 0 | Reserved | | | 0 | Reserved | |
| | | | | | | |
| 1 | optional | See Section 3.3 | | 1 | optional | See Section 4.3 |
| | | | | | | |
| 2 | required | See Section 3.3 | | 2 | required | See Section 4.3 |
| | | | | | | |
| 3 | recommended | See Section 3.3 | | 3 | recommended | See Section 4.3 |
| | | | | | | |
| 4-31 | Unassigned | | | 4-31 | Unassigned | |
| | | | | | | |
| 32-127 | Unassigned | | | 32-127 | Unassigned | |
| | | | | | | |
| 128-255 | Reserved for Private Use | | | 128-255 | Reserved for Private Use | |
+---------+--------------------------+-----------------+ +---------+--------------------------+-----------------+
4.4. Media Type Registration 5.5. swid+cbor Media Type Registration
4.4.1. swid+cbor Media Type Registration IANA is requested add the following to the IANA "Media Types"
registry.
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 6 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
Applications that use this media type: The type is used by Software Applications that use this media type: The type is used by Software
asset management systems, Vulnerability assessment systems, and in asset management systems, Vulnerability assessment systems, and in
applications that use remote integrity verification. applications that use remote integrity verification.
skipping to change at page 35, line 41 skipping to change at page 43, line 45
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.5. CoAP Content-Format Registration 5.6. 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 | - | TBD1 | RFC-AAAA |
+-----------------------+----------+-------+-----------+ +-----------------------+----------+------+-----------+
Table 1: CoAP Content-Format IDs Table 1: CoAP Content-Format IDs
4.6. CBOR Tag Registration 5.7. 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] |
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
5. Security Considerations 6. Security Considerations
SWID and CoSWID tags contain public information about software SWID and CoSWID tags contain public information about software
components and, as such, do not need to be protected against components and, as such, do not need to be protected against
disclosure on an endpoint. Similarly, SWID tags are intended to be disclosure on an endpoint. Similarly, SWID tags are intended to be
easily discoverable by applications and users on an endpoint in order 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 to make it easy to identify and collect all of an endpoint's SWID
tags. As such, any security considerations regarding SWID tags focus tags. As such, any security considerations regarding SWID tags focus
on the application of SWID tags to address security challenges, and on the application of SWID tags to address security challenges, and
the possible disclosure of the results of those applications. the possible disclosure of the results of those applications.
skipping to change at page 37, line 10 skipping to change at page 45, line 10
information in the tag needs to be trusted, such as when the tag is information in the tag needs to be trusted, such as when the tag is
being used to convey reference integrity measurements for software being used to convey reference integrity measurements for software
components. By contrast, the data contained in unsigned tags cannot components. By contrast, the data contained in unsigned tags cannot
be trusted to be unmodified. be trusted to be unmodified.
SWID tags are designed to be easily added and removed from an SWID tags are designed to be easily added and removed from an
endpoint along with the installation or removal of software endpoint along with the installation or removal of software
components. On endpoints where addition or removal of software components. On endpoints where addition or removal of software
components is tightly controlled, the addition or removal of SWID components is tightly controlled, the addition or removal of SWID
tags can be similarly controlled. On more open systems, where many tags can be similarly controlled. On more open systems, where many
users can manage the software inventory, SWID tags may be easier to users can manage the software inventory, SWID tags can be easier to
add or remove. On such systems, it may be possible to add or remove add or remove. On such systems, it can be possible to add or remove
SWID tags in a way that does not reflect the actual presence or SWID tags in a way that does not reflect the actual presence or
absence of corresponding software components. Similarly, not all absence of corresponding software components. Similarly, not all
software products automatically install SWID tags, so products may be software products automatically install SWID tags, so products can be
present on an endpoint without providing a corresponding SWID tag. present on an endpoint without providing a corresponding SWID tag.
As such, any collection of SWID tags cannot automatically be assumed As such, any collection of SWID tags cannot automatically be assumed
to represent either a complete or fully accurate representation of to represent either a complete or fully accurate representation of
the software inventory of the endpoint. However, especially on the software inventory of the endpoint. However, especially on
devices that more strictly control the ability to add or remove devices that more strictly control the ability to add or remove
applications, SWID tags are an easy way to provide an preliminary applications, SWID tags are an easy way to provide an preliminary
understanding of that endpoint's software inventory. understanding of that endpoint's software inventory.
Any report of an endpoint's SWID tag collection provides information Any report of an endpoint's SWID tag collection provides information
about the software inventory of that endpoint. If such a report is about the software inventory of that endpoint. If such a report is
skipping to change at page 37, line 50 skipping to change at page 45, line 50
that endpoint's attack surface. that endpoint's attack surface.
Finally, both the ISO-19770-2:2015 XML schema definition and the Finally, both the ISO-19770-2:2015 XML schema definition and the
Concise SWID data definition allow for the construction of "infinite" Concise SWID data definition allow for the construction of "infinite"
SWID tags or SWID tags that contain malicious content with the intent SWID tags or SWID tags that contain malicious content with the intent
if creating non-deterministic states during validation or processing if creating non-deterministic states during validation or processing
of SWID tags. While software product vendors are unlikely to do of SWID tags. While software product vendors are unlikely to do
this, SWID tags can be created by any party and the SWID tags this, SWID tags can be created by any party and the SWID tags
collected from an endpoint could contain a mixture of vendor and non- collected from an endpoint could contain a mixture of vendor and non-
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 employ
employ input sanitizing on the tags they ingest. input sanitizing on the tags they ingest.
6. Acknowledgments 7. Acknowledgments
7. Change Log TBD
8. Change Log
Changes from version 03 to version 09:
o Reduced representation complexity of the media-entry type and
removed the section describing the older data structure.
o Added more signature schemes from COSE
o Included a minimal required set of normative language
o Reordering of attribute name to integer label by priority
according to semantics.
o Added an IANA registry for CoSWID items supporting future
extension.
o Cleaned up IANA registrations, fixing some inconsistencies in the
table labels.
o Added additional CDDL sockets for resource collection entries
providing for additional extension points to address future SWID/
CoSWID extensions.
o Updated section on extension points to address new CDDL sockets
and to reference the new IANA registry for items.
o Removed unused references and added new references to address
placeholder comments.
o Added table with semantics for the link ownership item.
o Clarified language, made term use more consistent, fixed
references, and replacing lowercase RFC2119 keywords.
o Added enumeration table
o Moved CBOR specific indexes to the end of the CDDL data definition
o Updated Examples
Changes from version 02 to version 03:
o Updated core CDDL including the CDDL design pattern according to
RFC 8428.
Changes from version 01 to version 02:
o Enforced a more strict separation between the core CoSWID
definition and additional usage by moving content to corresponding
appendices.
o Removed artifacts inherited from the reference schema provided by
ISO (e.g. NMTOKEN(S))
o Simplified the core data definition by removing group and type
choices where possible
o Minor reordering of map members
o Added a first extension point to address requested flexibility for
extensions beyond the any-element
Changes from version 00 to version 01:
o Ambiguity between evidence and payload eliminated by introducing
explicit members (while still
o allowing for "empty" SWID tags)
o Added a relatively restrictive COSE envelope using cose_sign1 to
define signed CoSWID (single signer only, at the moment)
o Added a definition how to encode hashes that can be stored in the
any-member using existing IANA tables to reference hash-algorithms
Changes since adopted as a WG I-D -00:
o Removed redundant any-attributes originating from the ISO-
19770-2:2015 XML schema definition
o Fixed broken multi-map members
o Introduced a more restrictive item (any-element-map) to represent
custom maps, increased restriction on types for the any-attribute,
accordingly
o Fixed X.1520 reference
o Minor type changes of some attributes (e.g. NMTOKENS)
o Added semantic differentiation of various name types (e,g. fs-
name)
Changes from version 06 to version 07: Changes from version 06 to version 07:
o Added type choices/enumerations based on textual definitions in o Added type choices/enumerations based on textual definitions in
19770-2:2015 19770-2:2015
o Added value registry request o Added value registry request
o Added media type registration request o Added media type registration request
skipping to change at page 39, line 51 skipping to change at page 50, line 5
Tokens Tokens
Changes from version 00 to version 01: Changes from version 00 to version 01:
o Added CWT usage for absolute SWID paths on a device o Added CWT usage for absolute SWID paths on a device
o Fixed cardinality of type-choices including arrays o Fixed cardinality of type-choices including arrays
o Included first iteration of firmware resource-collection o Included first iteration of firmware resource-collection
Changes since adopted as a WG I-D -00: 9. Contributors
o Removed redundant any-attributes originating from the ISO-
19770-2:2015 XML schema definition
o Fixed broken multi-map members
o Introduced a more restrictive item (any-element-map) to represent
custom maps, increased restriction on types for the any-attribute,
accordingly
o Fixed X.1520 reference
o Minor type changes of some attributes (e.g. NMTOKENS)
o Added semantic differentiation of various name types (e,g. fs-
name)
Changes from version 00 to version 01:
o Ambiguity between evidence and payload eliminated by introducing
explicit members (while still
o allowing for "empty" SWID tags)
o Added a relatively restrictive COSE envelope using cose_sign1 to
define signed CoSWID (single signer only, at the moment)
o Added a definition how to encode hashes that can be stored in the
any-member using existing IANA tables to reference hash-algorithms
Changes from version 01 to version 02:
o Enforced a more strict separation between the core CoSWID
definition and additional usage by moving content to corresponding
appendices.
o Removed artifacts inherited from the reference schema provided by
ISO (e.g. NMTOKEN(S))
o Simplified the core data definition by removing group and type
choices where possible
o Minor reordering of map members
o Added a first extension point to address requested flexibility for
extensions beyond the any-element
8. Contributors
9. References
9.1. Normative References 10. References
[I-D.ietf-ace-cbor-web-token] 10.1. Normative References
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15
(work in progress), March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages", RFC 4108,
DOI 10.17487/RFC4108, August 2005,
<https://www.rfc-editor.org/info/rfc4108>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
skipping to change at page 41, line 48 skipping to change at page 50, line 38
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[SAM] "Information technology - Software asset management - Part [SAM] "Information technology - Software asset management - Part
5: Overview and vocabulary", ISO/IEC 19770-5:2015, 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]
Waltermire, D., Cheikes, B., Feldman, L., and G. Witte, Waltermire, D., Cheikes, B., Feldman, L., and G. Witte,
"Guidelines for the Creation of Interoperable Software "Guidelines for the Creation of Interoperable Software
Identification (SWID) Tags", NISTIR 8060, April 2016, Identification (SWID) Tags", NISTIR 8060, April 2016,
<https://doi.org/10.6028/NIST.IR.8060>. <https://doi.org/10.6028/NIST.IR.8060>.
[W3C.REC-css3-mediaqueries-20120619]
Rivoal, F., "Media Queries", World Wide Web Consortium
Recommendation REC-css3-mediaqueries-20120619, June 2012,
<http://www.w3.org/TR/2012/
REC-css3-mediaqueries-20120619>.
[W3C.REC-xpath20-20101214]
Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.,
Kay, M., Robie, J., and J. Simeon, "XML Path Language
(XPath) 2.0 (Second Edition)", World Wide Web Consortium
Recommendation REC-xpath20-20101214, December 2010,
<http://www.w3.org/TR/2010/REC-xpath20-20101214>.
[X.1520] "Recommendation ITU-T X.1520 (2014), Common [X.1520] "Recommendation ITU-T X.1520 (2014), Common
vulnerabilities and exposures", April 2011. vulnerabilities and exposures", April 2011.
9.2. Informative References 10.2. Informative References
[I-D.birkholz-tuda] [CamelCase]
"UpperCamelCase", August 2014,
<http://wiki.c2.com/?CamelCase>.
[I-D.birkholz-rats-tuda]
Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
"Time-Based Uni-Directional Attestation", draft-birkholz- "Time-Based Uni-Directional Attestation", draft-birkholz-
tuda-04 (work in progress), March 2017. rats-tuda-00 (work in progress), March 2019.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor- express CBOR and JSON data structures", draft-ietf-cbor-
cddl-05 (work in progress), August 2018. cddl-08 (work in progress), March 2019.
[I-D.ietf-sacm-rolie-softwaredescriptor]
Banghart, S. and D. Waltermire, "Definition of the ROLIE
Software Descriptor Extension", draft-ietf-sacm-rolie-
softwaredescriptor-03 (work in progress), July 2018.
[I-D.ietf-sacm-terminology] [KebabCase]
Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and "KebabCase", December 2014,
A. Montville, "Security Automation and Continuous <http://wiki.c2.com/?KebabCase>.
Monitoring (SACM) Terminology", draft-ietf-sacm-
terminology-15 (work in progress), June 2018.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource-
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, Oriented Lightweight Information Exchange (ROLIE)",
<https://www.rfc-editor.org/info/rfc4949>. RFC 8322, DOI 10.17487/RFC8322, February 2018,
<https://www.rfc-editor.org/info/rfc8322>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
Appendix A. CoSWID Attributes for Firmware (label 60)
NOTE: this appendix is subject to revision or removal based on
potential convergence of:
o draft-moran-suit-manifest, and
o draft-birkholz-suit-coswid-manifest
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
the case of constrained-node networks [RFC7228] or network equipment
this assumption might not apply. Concise software instances in the
form of (modular) firmware are often stored directly on a block
device that is a hardware component of the constrained-node or
network equipment. Multiple differentiable block devices or
segmented block devices that contain parts of modular firmware
components (potentially each with their own instance version) are
already common at the time of this writing.
The optional attributes that annotate a firmware package address
specific characteristics of pieces of firmware stored directly on a
block-device in contrast to software deployed in a file-system. In
essence, trees of relative path-elements expressed by the directory
and file structure in CoSWID tags are typically unable to represent
the location of a firmware on a constrained-node (small thing). The
composite nature of firmware and also the actual composition of small
things require a set of attributes to address the identification of
the correct component in a composite thing for each individual piece
of firmware. A single component also potentially requires a number
of distinct firmware parts that might depend on each other
(versions). These dependencies can be limited to the scope of the
component itself or extend to the scope of a larger composite device.
In addition, it might not be possible (or feasible) to store a CoSWID
tag document (permanently) on a small thing along with the
corresponding piece of firmware.
To address the specific characteristics of firmware, the extension
points "$$payload-extension" and "$$evidence-extension" are used to
allow for an additional type of resource description--firmware-
entry--thereby increasing the self-descriptiveness and flexibility of
CoSWID. The optional use of the extension points "$$payload-
extension" and "$$evidence-extension" in respect to firmware MUST
adhere to the following CDDL data definition.
<CODE BEGINS>
$$payload-extension //= (suit.manifest-entry,)
$$evidence-extension //= (suit.manifest-entry,)
suit-manifest = {
suit.manifest-version,
suit.digest-info,
suit.text-reference,
suit.nonce,
suit.sequence-number,
? suit.pre-condition,
? suit.post-condition,
? suit.directives,
? suit.resources,
? suit.processors,
? suit.targets,
? suit.extensions,
}
suit.manifest-entry = (59: suit-manifest / [ 2* suit-manifest ] )
suit.manifest-version = (60: 1)
suit.digest-info = (61: [ suit.digest-algorithm,
? suit.digest-parameters,
]
)
suit.digest-algorithm = uint
suit.digest-parameters = bytes
suit.text-reference = (62: bytes)
suit.nonce = (63: bytes)
suit.sequence-number = (64: uint)
suit.pre-condition = (suit.id-condition // suit.time-condition // suit.image-condition // suit.custom-condition)
suit.post-condition = (suit.image-condition // suit.custom-condition)
suit.id-condition = (65: [ + [ suit.vendor / suit.class / suit.device,
suit.uuid,
]
]
)
suit.vendor = 0
suit.class = 1
suit.device = 2
suit.uuid = bstr .size 16
suit.time-condition = (66: [ + [ suit.install-after / suit.best-before,
suit.timestamp,
]
]
)
suit.install-after = 0
suit.best-before = 1
suit.timestamp = uint .size 8
suit.image-condition = (67: [ + [ suit.current-content / suit.not-current-content,
suit.storage-identifier,
? suit.digest,
]
]
)
suit.current-content = 0
suit.not-current-content = 1
suit.digest = bytes
suit.storage-identifier = bytes
suit.custom-condition = (68: [ nint,
suit.condition-parameters,
]
)
suit.condition-parameters = bytes
suit.directives = (69: { + int => bytes } )
suit.resources = (70: [ + [ suit.resource-type,
suit.uri-list,
suit.digest,
suit.onode,
? suit.size,
]
]
)
suit.resource-type = suit.payload / suit.dependency / suit.key / suit.alias
suit.payload = 0
suit.dependency = 1
suit.key = 2
suit.alias = 3
suit.uri-list = { + int => text }
suit.size = uint
suit.onode = bytes
suit.processors = (71: [ + [ suit.decrypt / suit.decompress / suit.undiff / suit.relocate / suit.unrelocate,
suit.parameters,
suit.inode,
suit.onode,
]
]
)
suit.decrypt = 0
suit.decompress = 1
suit.undiff = 2
suit.relocate = 3
suit.unrelocate = 4
suit.parameters = bytes
suit.inode = bytes
suit.targets = (72: [ + [ suit.component-id,
suit.storage-identifier,
suit.inode,
? suit.encoding,
]
]
)
suit.component-id = [ + bytes ]
suit.encoding = bytes
suit.extensions = (73: { + int => bytes } )
<CODE ENDS>
The members of the firmware group that constitutes the content of the
firmware-entry is based on the metadata about firmware Described in
[RFC4108]. As with every semantic differentiation that is supported
by the resource-collection type, the use of firmware-entry is
optional. It is REQUIRED not to instantiate more than one firmware-
entry, as the firmware group is used in a map and therefore only
allows for unique labels.
The optional cms-firmware-package member allows to include the actual [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
firmware in the CoSWID tag that also expresses its metadata as a Description Specification", RFC 8520,
byte-string. This option enables a CoSWID tag to be used as a DOI 10.17487/RFC8520, March 2019,
container or wrapper that composes both firmware and its metadata in <https://www.rfc-editor.org/info/rfc8520>.
a single document (which again can be signed, encrypted and/or
compressed). In consequence, a CoSWID tag about firmware can be
conveyed as an identifying document across endpoints or used as a
reference integrity measurement as usual. Alternatively, it can also
convey an actual piece of firmware, serve its intended purpose as a
SWID tag and then - due to the lack of a location to store it - be
discarded.
Appendix B. Signed Concise SWID Tags using COSE Appendix A. Signed Concise SWID Tags using COSE
SWID tags, as defined in the ISO-19770-2:2015 XML schema, can include SWID tags, as defined in the ISO-19770-2:2015 XML schema, can include
cryptographic signatures to protect the integrity of the SWID tag. cryptographic signatures to protect the integrity of the SWID tag.
In general, tags are signed by the tag creator (typically, although In general, tags are signed by the tag creator (typically, although
not exclusively, the vendor of the software component that the SWID not exclusively, the vendor of the software component that the SWID
tag identifies). Cryptographic signatures can make any modification tag identifies). Cryptographic signatures can make any modification
of the tag detectable, which is especially important if the integrity of the tag detectable, which is especially important if the integrity
of the tag is important, such as when the tag is providing reference of the tag is important, such as when the tag is providing reference
integrity measurements for files. integrity measurements for files.
The ISO-19770-2:2015 XML schema uses XML DSIG to support The ISO-19770-2:2015 XML schema uses XML DSIG to support
cryptographic signatures. CoSWID tags require a different signature cryptographic signatures. CoSWID tags require a different signature
scheme than this. COSE (CBOR Object Signing and Encryption) provides scheme than this. COSE (CBOR Object Signing and Encryption) provides
the required mechanism [RFC8152]. Concise SWID can be wrapped in a the required mechanism [RFC8152]. Concise SWID can be wrapped in a
COSE Single Signer Data Object (cose-sign1) that contains a single COSE Single Signer Data Object (COSE_Sign1) that contains a single
signature. The following CDDL defines a more restrictive subset of signature. The following CDDL defines a more restrictive subset of
header attributes allowed by COSE tailored to suit the requirements header attributes allowed by COSE tailored to suit the requirements
of Concise SWID. of Concise SWID tags.
<CODE BEGINS> <CODE BEGINS>
signed-coswid = #6.997(COSE-Sign1-coswid) ; see TBS7 in current COSE I-D signed-coswid = #6.18(COSE-Sign1-coswid)
label = int / tstr ; see COSE I-D 1.4. cose-label = int / tstr
values = any ; see COSE I-D 1.4. cose-values = any
unprotected-signed-coswid-header = { protected-signed-coswid-header = {
1 => int, ; algorithm identifier 1 => int, ; algorithm identifier
3 => "application/coswid", ; request for CoAP IANA registry to become an int 3 => "application/swid+cbor",
* label => values, * cose-label => cose-values,
} }
protected-signed-coswid-header = { unprotected-signed-coswid-header = {
4 => bstr, ; key identifier 4 => bstr, ; key identifier
* label => values, * cose-label => cose-values,
} }
COSE-Sign1-coswid = [ COSE-Sign1-coswid = [
protected: bstr .cbor protected-signed-coswid-header, protected: bstr .cbor protected-signed-coswid-header,
unprotected: unprotected-signed-coswid-header, unprotected: unprotected-signed-coswid-header,
payload: bstr .cbor concise-software-identity, payload: bstr .cbor concise-swid-tag,
signature: bstr, signature: bstr,
] ]
<CODE ENDS> <CODE ENDS>
Optionally, the COSE_Sign structure that allows for more than one
signature to be applied to a CoSWID tag MAY be used. The
corresponding usage scenarios are domain-specific and require well-
defined application guidance. Representation of the corresponding
guidance is out-of-scope of this document.
Additionally, the COSE Header counter signature MAY be used as an
attribute in the unprotected header map of the COSE envelope of a
CoSWID. The application of counter signing enables second parties to
provide a signature on a signature allowing for a proof that a
signature existed at a given time (i.e., a timestamp).
Authors' Addresses Authors' Addresses
Henk Birkholz Henk Birkholz
Fraunhofer SIT Fraunhofer SIT
Rheinstrasse 75 Rheinstrasse 75
Darmstadt 64295 Darmstadt 64295
Germany Germany
Email: henk.birkholz@sit.fraunhofer.de Email: henk.birkholz@sit.fraunhofer.de
 End of changes. 264 change blocks. 
1110 lines changed or deleted 1420 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/