idnits 2.17.1 draft-ietf-sacm-coswid-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 781 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Link' is mentioned on line 2088, but not defined == Missing Reference: 'RFC-AAAA' is mentioned on line 2779, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-cose-countersign-05 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-countersign' -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEMVER' -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNSPSC' == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-15 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Standards Track J. Fitzgerald-McKay 5 Expires: 8 September 2022 National Security Agency 6 C. Schmidt 7 The MITRE Corporation 8 D. Waltermire 9 NIST 10 7 March 2022 12 Concise Software Identification Tags 13 draft-ietf-sacm-coswid-21 15 Abstract 17 ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an 18 extensible XML-based structure to identify and describe individual 19 software components, patches, and installation bundles. SWID tag 20 representations can be too large for devices with network and storage 21 constraints. This document defines a concise representation of SWID 22 tags: Concise SWID (CoSWID) tags. CoSWID supports a similar set of 23 semantics and features as SWID tags, as well as new semantics that 24 allow CoSWIDs to describe additional types of information, all in a 25 more memory efficient format. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 8 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. The SWID and CoSWID Tag Lifecycle . . . . . . . . . . . . 4 62 1.2. Concise SWID Format . . . . . . . . . . . . . . . . . . . 8 63 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 8 64 2. Concise SWID Data Definition . . . . . . . . . . . . . . . . 8 65 2.1. Character Encoding . . . . . . . . . . . . . . . . . . . 10 66 2.2. Concise SWID Extensions . . . . . . . . . . . . . . . . . 10 67 2.3. The concise-swid-tag Map . . . . . . . . . . . . . . . . 13 68 2.4. concise-swid-tag Co-Constraints . . . . . . . . . . . . . 18 69 2.5. The global-attributes Group . . . . . . . . . . . . . . . 18 70 2.6. The entity-entry Map . . . . . . . . . . . . . . . . . . 19 71 2.7. The link-entry Map . . . . . . . . . . . . . . . . . . . 21 72 2.8. The software-meta-entry Map . . . . . . . . . . . . . . . 25 73 2.9. The Resource Collection Definition . . . . . . . . . . . 28 74 2.9.1. The hash-entry Array . . . . . . . . . . . . . . . . 28 75 2.9.2. The resource-collection Group . . . . . . . . . . . . 28 76 2.9.3. The payload-entry Map . . . . . . . . . . . . . . . . 32 77 2.9.4. The evidence-entry Map . . . . . . . . . . . . . . . 32 78 2.10. Full CDDL Specification . . . . . . . . . . . . . . . . . 33 79 3. Determining the Type of CoSWID . . . . . . . . . . . . . . . 39 80 4. CoSWID Indexed Label Values . . . . . . . . . . . . . . . . . 40 81 4.1. Version Scheme . . . . . . . . . . . . . . . . . . . . . 40 82 4.2. Entity Role Values . . . . . . . . . . . . . . . . . . . 42 83 4.3. Link Ownership Values . . . . . . . . . . . . . . . . . . 44 84 4.4. Link Rel Values . . . . . . . . . . . . . . . . . . . . . 44 85 4.5. Link Use Values . . . . . . . . . . . . . . . . . . . . . 46 86 5. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 47 87 5.1. "swid" URI Scheme . . . . . . . . . . . . . . . . . . . . 47 88 5.2. "swidpath" URI Scheme . . . . . . . . . . . . . . . . . . 48 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 90 6.1. CoSWID Items Registry . . . . . . . . . . . . . . . . . . 49 91 6.2. Software Tag Values Registries . . . . . . . . . . . . . 52 92 6.2.1. Registration Procedures . . . . . . . . . . . . . . . 52 93 6.2.2. Private Use of Index and Name Values . . . . . . . . 52 94 6.2.3. Expert Review Criteria . . . . . . . . . . . . . . . 53 95 6.2.4. Software Tag Version Scheme Values Registry . . . . . 53 96 6.2.5. Software Tag Entity Role Values Registry . . . . . . 55 97 6.2.6. Software Tag Link Ownership Values Registry . . . . . 56 98 6.2.7. Software Tag Link Relationship Values Registry . . . 57 99 6.2.8. Software Tag Link Use Values Registry . . . . . . . . 60 100 6.3. swid+cbor Media Type Registration . . . . . . . . . . . . 61 101 6.4. CoAP Content-Format Registration . . . . . . . . . . . . 62 102 6.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 62 103 6.6. URI Scheme Registrations . . . . . . . . . . . . . . . . 62 104 6.6.1. URI-scheme swid . . . . . . . . . . . . . . . . . . . 63 105 6.6.2. URI-scheme swidpath . . . . . . . . . . . . . . . . . 63 106 6.7. CoSWID Model for use in SWIMA Registration . . . . . . . 64 107 7. Signed CoSWID Tags . . . . . . . . . . . . . . . . . . . . . 64 108 8. CBOR-Tagged CoSWID Tags . . . . . . . . . . . . . . . . . . . 67 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 67 110 10. Privacy Consideration . . . . . . . . . . . . . . . . . . . . 71 111 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 72 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 77 114 12.2. Informative References . . . . . . . . . . . . . . . . . 80 115 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 81 116 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 81 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 119 1. Introduction 121 SWID tags, as defined in ISO-19770-2:2015 [SWID], provide a 122 standardized XML-based record format that identifies and describes a 123 specific release of software, a patch, or an installation bundle, 124 which are referred to as software components in this document. 125 Different software components, and even different releases of a 126 particular software component, each have a different SWID tag record 127 associated with them. SWID tags are meant to be flexible and able to 128 express a broad set of metadata about a software component. 130 SWID tags are used to support a number of processes including but not 131 limited to: 133 * Software Inventory Management, a part of a Software Asset 134 Management [SAM] process, which requires an accurate list of 135 discernible deployed software components. 137 * Vulnerability Assessment, which requires a semantic link between 138 standardized vulnerability descriptions and software components 139 installed on IT-assets [X.1520]. 141 * Remote Attestation, which requires a link between reference 142 integrity measurements (RIM) and Attester-produced event logs that 143 complement attestation Evidence [I-D.ietf-rats-architecture]. 145 While there are very few required fields in SWID tags, there are many 146 optional fields that support different uses. A SWID tag consisting 147 of only required fields might be a few hundred bytes in size; 148 however, a tag containing many of the optional fields can be many 149 orders of magnitude larger. Thus, real-world instances of SWID tags 150 can be fairly large, and the communication of SWID tags in usage 151 scenarios, such as those described earlier, can cause a large amount 152 of data to be transported. This can be larger than acceptable for 153 constrained devices and networks. Concise SWID (CoSWID) tags 154 significantly reduce the amount of data transported as compared to a 155 typical SWID tag through the use of the Concise Binary Object 156 Representation (CBOR) [RFC8949]. 158 Size comparisons between XML SWID and CoSWID mainly depend on domain- 159 specific applications and the complexity of attributes used in 160 instances. While the values stored in CoSWID are often unchanged and 161 therefore not reduced in size compared to an XML SWID, the 162 scaffolding that the CoSWID encoding represents is significantly 163 smaller by taking up 10 percent or less in size. This effect is 164 visible in representation sizes, which in early experiments benefited 165 from a 50 percent to 85 percent reduction in generic usage scenarios. 166 Additional size reduction is enabled with respect to the memory 167 footprint of XML parsing/validation. 169 In a CoSWID, the human-readable labels of SWID data items are 170 replaced with more concise integer labels (indices). This approach 171 allows SWID and CoSWID to share a common implicit information model, 172 with CoSWID providing an alternate data model [RFC3444]. While SWID 173 and CoSWID are intended to share the same implicit information model, 174 this specification does not define this information model, or a 175 mapping between the two data formats. While an attempt to align SWID 176 and CoSWID tags has been made here, future revisions of ISO/IEC 177 19770-2:2015 or this specification might cause this implicit 178 information model to diverge, since these specifications are 179 maintained by different standards groups. 181 The use of CBOR to express SWID information in CoSWID tags allows 182 both CoSWID and SWID tags to be part of an enterprise security 183 solution for a wider range of endpoints and environments. 185 1.1. The SWID and CoSWID Tag Lifecycle 187 In addition to defining the format of a SWID tag record, ISO/IEC 188 19770-2:2015 defines requirements concerning the SWID tag lifecycle. 189 Specifically, when a software component is installed on an endpoint, 190 that software component's SWID tag is also installed. Likewise, when 191 the software component is uninstalled or replaced, the SWID tag is 192 deleted or replaced, as appropriate. As a result, ISO/IEC 193 19770-2:2015 describes a system wherein there is a correspondence 194 between the set of installed software components on an endpoint, and 195 the presence of the corresponding SWID tags for these components on 196 that endpoint. CoSWIDs share the same lifecycle requirements as a 197 SWID tag. 199 The SWID specification and supporting guidance provided in NIST 200 Internal Report (NISTIR) 8060: Guidelines for the Creation of 201 Interoperable SWID Tags [SWID-GUIDANCE] defines four types of SWID 202 tags: primary, patch, corpus, and supplemental. The following text 203 is paraphrased from these sources. 205 1. Primary Tag - A SWID or CoSWID tag that identifies and describes 206 an installed software component on an endpoint. A primary tag is 207 intended to be installed on an endpoint along with the 208 corresponding software component. 210 2. Patch Tag - A SWID or CoSWID tag that identifies and describes an 211 installed patch that has made incremental changes to a software 212 component installed on an endpoint. A patch tag is intended to 213 be installed on an endpoint along with the corresponding software 214 component patch. 216 3. Corpus Tag - A SWID or CoSWID tag that identifies and describes 217 an installable software component in its pre-installation state. 218 A corpus tag can be used to represent metadata about an 219 installation package or installer for a software component, a 220 software update, or a patch. 222 4. Supplemental Tag - A SWID or CoSWID tag that allows additional 223 information to be associated with a referenced SWID tag. This 224 allows tools and users to record their own metadata about a 225 software component without modifying CoSWID primary or patch tags 226 created by a software provider. 228 The type of a tag is determined by specific data elements, which are 229 discussed in Section 3, which also provides normative language for 230 CoSWID semantics that implement this lifecycle. The following 231 information helps to explain how these semantics apply to use of a 232 CoSWID tag. 234 Corpus, primary, and patch tags have similar functions in that 235 they describe the existence and/or presence of different types of 236 software components (e.g., software installers, software 237 installations, software patches), and, potentially, different 238 states of these software components. Supplemental tags have the 239 same structure as other tags, but are used to provide information 240 not contained in the referenced corpus, primary, and patch tags. 242 All four tag types come into play at various points in the 243 software lifecycle and support software management processes that 244 depend on the ability to accurately determine where each software 245 component is in its lifecycle. 247 +------------+ 248 v | 249 Software Software Software Software Software 250 Deployment -> Installation -> Patching -> Upgrading -> Removal 252 Corpus Primary Primary xPrimary xPrimary 253 Supplemental Supplemental Supplemental xSupplemental xSupplemental 254 Patch xPatch 255 Primary 256 Supplemental 258 Figure 1: Use of Tag Types in the Software Lifecycle 260 Figure 1 illustrates the steps in the software lifecycle and the 261 relationships among those lifecycle events supported by the four 262 types of SWID and CoSWID tags. A detailed description of the four 263 tags types is provided in Section 2.3. The figure identifies the 264 types of tags that are used in each lifecycle event. 266 There are many ways in which software tags might be managed for the 267 host the software is installed on. For example, software tags could 268 be made available on the host or to an external software manager when 269 storage is limited on the host. 271 In these cases the host or external software manager is responsible 272 for management of the tags, including deployment and removal of the 273 tags as indicated by the above lifecycle. Tags are deployed and 274 previously deployed tags that are typically removed (indicated by an 275 "x" prefix) at each lifecycle stage, as follows: 277 - Software Deployment. Before the software component is 278 installed (i.e., pre-installation), and while the product is 279 being deployed, a corpus tag provides information about the 280 installation files and distribution media (e.g., CD/DVD, 281 distribution package). 283 Corpus tags are not actually deployed on the target system but are 284 intended to support deployment procedures and their dependencies at 285 install-time, such as to verify the installation media. 287 - Software Installation. A primary tag will be installed with 288 the software component (or subsequently created) to uniquely 289 identify and describe the software component. Supplemental 290 tags are created to augment primary tags with additional site- 291 specific or extended information. While not illustrated in the 292 figure, patch tags can also be installed during software 293 installation to provide information about software fixes 294 deployed along with the base software installation. 296 - Software Patching. A new patch tag is provided, when a patch 297 is applied to the software component, supplying details about 298 the patch and its dependencies. While not illustrated in the 299 figure, a corpus tag can also provide information about the 300 patch installer and patching dependencies that need to be 301 installed before the patch. 303 - Software Upgrading. As a software component is upgraded to a 304 new version, new primary and supplemental tags replace existing 305 tags, enabling timely and accurate tracking of updates to 306 software inventory. While not illustrated in the figure, a 307 corpus tag can also provide information about the upgrade 308 installer and dependencies that need to be installed before the 309 upgrade. 311 Note: In the context of software tagging software patching and 312 updating differ in an important way. When installing a patch, a set 313 of file modifications are made to pre-installed software which do not 314 alter the version number or the descriptive metadata of an installed 315 software component. An update can also make a set of file 316 modifications, but the version number or the descriptive metadata of 317 an installed software component are changed. 319 - Software Removal. Upon removal of the software component, 320 relevant SWID tags are removed. This removal event can trigger 321 timely updates to software inventory reflecting the removal of 322 the product and any associated patch or supplemental tags. 324 As illustrated in the figure, supplemental tags can be associated 325 with any corpus, primary, or patch tag to provide additional metadata 326 about an installer, installed software, or installed patch 327 respectively. 329 Understanding the use of CoSWIDs in the software lifecycle provides a 330 basis for understanding the information provided in a CoSWID and the 331 associated semantics of this information. Each of the different SWID 332 and CoSWID tag types provide different sets of information. For 333 example, a "corpus tag" is used to describe a software component's 334 installation image on an installation media, while a "patch tag" is 335 meant to describe a patch that modifies some other software 336 component. 338 1.2. Concise SWID Format 340 This document defines the CoSWID tag format, which is based on CBOR. 341 CBOR-based CoSWID tags offer a more concise representation of SWID 342 information as compared to the XML-based SWID tag representation in 343 ISO-19770-2:2015. The structure of a CoSWID is described via the 344 Concise Data Definition Language (CDDL) [RFC8610]. The resulting 345 CoSWID data definition is aligned to the information able to be 346 expressed with the XML schema definition of ISO-19770-2:2015 [SWID]. 347 This alignment allows both SWID and CoSWID tags to represent a common 348 set of software component information and allows CoSWID tags to 349 support the same uses as a SWID tag. 351 The vocabulary, i.e., the CDDL names of the types and members used in 352 the CoSWID CDDL specification, are mapped to more concise labels 353 represented as small integer values (indices). The names used in the 354 CDDL specification and the mapping to the CBOR representation using 355 integer indices is based on the vocabulary of the XML attribute and 356 element names defined in ISO/IEC 19770-2:2015. 358 1.3. Requirements Notation 360 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 361 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 362 "OPTIONAL" in this document are to be interpreted as described in 363 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 364 capitals, as shown here. 366 2. Concise SWID Data Definition 368 The following describes the general rules and processes for encoding 369 data using CDDL representation. Prior familiarity with CBOR and CDDL 370 concepts will be helpful in understanding this CoSWID specification. 372 This section describes the conventions by which a CoSWID is 373 represented in the CDDL structure. The CamelCase [CamelCase] 374 notation used in the XML schema definition is changed to a hyphen- 375 separated notation [KebabCase] (e.g., ResourceCollection is named 376 resource-collection) in the CoSWID CDDL specification. This 377 deviation from the original notation used in the XML representation 378 reduces ambiguity when referencing certain attributes in 379 corresponding textual descriptions. An attribute referred to by its 380 name in CamelCase notation explicitly relates to XML SWID tags; an 381 attribute referred to by its name in KebabCase notation explicitly 382 relates to CBOR CoSWID tags. This approach simplifies the 383 composition of further work that reference both XML SWID and CBOR 384 CoSWID documents. 386 In most cases, mapping attribute names between SWID and CoSWID can be 387 done automatically by converting between CamelCase and KebabCase 388 attribute names. However, some CoSWID CDDL attribute names show 389 greater variation relative to their corresponding SWID XML Schema 390 attributes. This is done when the change improves clarity in the 391 CoSWID specification. For example, the "name" and "version" SWID 392 fields corresponds to the "software-name" and "software-version" 393 CoSWID fields, respectively. As such, it is not always possible to 394 mechanically translate between corresponding attribute names in the 395 two formats. In such cases, a manual mapping will need to be used. 396 XPath expressions [W3C.REC-xpath20-20101214] need to use SWID names, 397 see Section 5.2. 399 The 57 human-readable text labels of the CDDL-based CoSWID vocabulary 400 are mapped to integer indices via a block of rules at the bottom of 401 the definition. This allows a more concise integer-based form to be 402 stored or transported, as compared to the less efficient text-based 403 form of the original vocabulary. 405 Through use of CDDL-based integer labels, CoSWID allows for future 406 expansion in subsequent revisions of this specification and through 407 extensions (see Section 2.2). New constructs can be associated with 408 a new integer index. A deprecated construct can be replaced by a new 409 construct with a new integer index. An implementation can use these 410 integer indexes to identify the construct to parse. The CoSWID Items 411 registry, defined in Section 6.1, is used to ensure that new 412 constructs are assigned a unique index value. This approach avoids 413 the need to have an explicit CoSWID version. 415 In a number of places, the value encoding admits both integer values 416 and text strings. The integer values are defined in a registry 417 specific to the kind of value; the text values are not intended for 418 interchange and exclusively meant for private use as defined in 419 Section 6.2.2. Encoders SHOULD NOT use string values based on the 420 names registered in the registry, as these values are less concise 421 than their index value equivalent; a decoder MUST however be prepared 422 to accept text strings that are not specified in this document (and 423 ignore the construct if that string is unknown). In the rest of the 424 document, we call this an "integer label with text escape". 426 The root of the CDDL specification provided by this document is the 427 rule coswid (as defined in Section 8): 429 start = coswid 431 In CBOR, an array is encoded using bytes that identify the array, and 432 the array's length or stop point (see [RFC8949]). To make items that 433 support 1 or more values, the following CDDL notation is used. 435 _name_ = (_label_ => _data_ / [ 2* _data_ ]) 437 The CDDL rule above allows either a single data item or an array of 2 438 or more data values to be provided. When a singleton data value is 439 provided, the CBOR markers for the array, array length, and stop 440 point are not needed, saving bytes. When two or more data values are 441 provided, these values are encoded as an array. This modeling 442 pattern is used frequently in the CoSWID CDDL specification to allow 443 for more efficient encoding of singleton values. 445 Usage of this construct can be simplified using 447 one-or-more = T / [ 2* T ] 449 simplifying the above example to 451 _name_ = (_label_ => one-or-more<_data_>) 453 The following subsections describe the different parts of the CoSWID 454 model. 456 2.1. Character Encoding 458 The CDDL "text" type is represented in CBOR as a major type 3, which 459 represents "a string of Unicode characters that [are] encoded as 460 UTF-8 [RFC3629]" (see Section 3.1 of [RFC8949]). Thus both SWID and 461 CoSWID use UTF-8 for the encoding of characters in text strings. 463 To ensure that UTF-8 character strings are able to be encoded/decoded 464 and exchanged interoperably, text strings in CoSWID MUST be encoded 465 consistent with the Net-Unicode definition defined in [RFC5198]. 467 All names registered with IANA according to requirements in 468 Section 6.2 also MUST be valid according to the XML Schema NMTOKEN 469 data type (see [W3C.REC-xmlschema-2-20041028] Section 3.3.4) to 470 ensure compatibility with the SWID specification where these names 471 are used. 473 2.2. Concise SWID Extensions 475 The CoSWID specification contains two features that are not included 476 in the SWID specification on which it is based. These features are: 478 * The explicit definition of types for some attributes in the ISO- 479 19770-2:2015 XML representation that are typically represented by 480 the "any attribute" in the SWID model. These are covered in 481 Section 2.4, Paragraph 2. 483 * The inclusion of extension points in the CoSWID specification 484 using CDDL sockets (see [RFC8610] Section 3.9). The use of CDDL 485 sockets allow for well-formed extensions to be defined in 486 supplementary CDDL descriptions that support additional uses of 487 CoSWID tags that go beyond the original scope of ISO-19770-2:2015 488 tags. This extension mechanism can also be used to update the 489 CoSWID format as revisions to ISO-19770-2 are published. 491 The following CDDL sockets (extension points) are defined in this 492 document, which allow the addition of new information structures to 493 their respective CDDL groups. 495 +=====================+=================================+=========+ 496 | Map Name | CDDL Socket | Defined | 497 | | | in | 498 +=====================+=================================+=========+ 499 | concise-swid-tag | $$coswid-extension | Section | 500 | | | 2.3 | 501 +---------------------+---------------------------------+---------+ 502 | entity-entry | $$entity-extension | Section | 503 | | | 2.6 | 504 +---------------------+---------------------------------+---------+ 505 | link-entry | $$link-extension | Section | 506 | | | 2.7 | 507 +---------------------+---------------------------------+---------+ 508 | software-meta-entry | $$software-meta-extension | Section | 509 | | | 2.8 | 510 +---------------------+---------------------------------+---------+ 511 | resource-collection | $$resource-collection-extension | Section | 512 | | | 2.9.2 | 513 +---------------------+---------------------------------+---------+ 514 | file-entry | $$file-extension | Section | 515 | | | 2.9.2 | 516 +---------------------+---------------------------------+---------+ 517 | directory-entry | $$directory-extension | Section | 518 | | | 2.9.2 | 519 +---------------------+---------------------------------+---------+ 520 | process-entry | $$process-extension | Section | 521 | | | 2.9.2 | 522 +---------------------+---------------------------------+---------+ 523 | resource-entry | $$resource-extension | Section | 524 | | | 2.9.2 | 525 +---------------------+---------------------------------+---------+ 526 | payload-entry | $$payload-extension | Section | 527 | | | 2.9.3 | 528 +---------------------+---------------------------------+---------+ 529 | evidence-entry | $$evidence-extension | Section | 530 | | | 2.9.4 | 531 +---------------------+---------------------------------+---------+ 533 Table 1: CoSWID CDDL Group Extension Points 535 The CoSWID Items Registry defined in Section 6.1 provides a 536 registration mechanism allowing new items, and their associated index 537 values, to be added to the CoSWID model through the use of the CDDL 538 sockets described in the table above. This registration mechanism 539 provides for well-known index values for data items in CoSWID 540 extensions, allowing these index values to be recognized by 541 implementations supporting a given extension. 543 The following additional CDDL sockets are defined in this document to 544 allow for adding new values to corresponding type-choices (i.e. to 545 represent enumerations) via custom CDDL specifications. 547 +==================+=================+=============+ 548 | Enumeration Name | CDDL Socket | Defined in | 549 +==================+=================+=============+ 550 | version-scheme | $version-scheme | Section 4.1 | 551 +------------------+-----------------+-------------+ 552 | role | $role | Section 4.2 | 553 +------------------+-----------------+-------------+ 554 | ownership | $ownership | Section 4.3 | 555 +------------------+-----------------+-------------+ 556 | rel | $rel | Section 4.4 | 557 +------------------+-----------------+-------------+ 558 | use | $use | Section 4.5 | 559 +------------------+-----------------+-------------+ 561 Table 2: CoSWID CDDL Enumeration Extension Points 563 A number of CoSWID value registries are also defined in Section 6.2 564 that allow new values to be registered with IANA for the enumerations 565 above. This registration mechanism supports the definition of new 566 well-known index values and names for new enumeration values used by 567 CoSWID, which can also be used by other software tagging 568 specifications. This registration mechanism allows new standardized 569 enumerated values to be shared between multiple tagging 570 specifications (and associated implementations) over time. 572 2.3. The concise-swid-tag Map 574 The CDDL specification for the root concise-swid-tag map is as 575 follows and this rule and its constraints MUST be followed when 576 creating or validating a CoSWID tag: 578 concise-swid-tag = { 579 tag-id => text / bstr .size 16, 580 tag-version => integer, 581 ? corpus => bool, 582 ? patch => bool, 583 ? supplemental => bool, 584 software-name => text, 585 ? software-version => text, 586 ? version-scheme => $version-scheme, 587 ? media => text, 588 ? software-meta => one-or-more, 589 entity => one-or-more, 590 ? link => one-or-more, 591 ? payload-or-evidence, 592 * $$coswid-extension, 593 global-attributes, 594 } 596 payload-or-evidence //= ( payload => payload-entry ) 597 payload-or-evidence //= ( evidence => evidence-entry ) 599 tag-id = 0 600 software-name = 1 601 entity = 2 602 evidence = 3 603 link = 4 604 software-meta = 5 605 payload = 6 606 corpus = 8 607 patch = 9 608 media = 10 609 supplemental = 11 610 tag-version = 12 611 software-version = 13 612 version-scheme = 14 614 $version-scheme /= multipartnumeric 615 $version-scheme /= multipartnumeric-suffix 616 $version-scheme /= alphanumeric 617 $version-scheme /= decimal 618 $version-scheme /= semver 619 $version-scheme /= int / text 620 multipartnumeric = 1 621 multipartnumeric-suffix = 2 622 alphanumeric = 3 623 decimal = 4 624 semver = 16384 625 The following describes each member of the concise-swid-tag root map. 627 * global-attributes: A list of items including an optional language 628 definition to support the processing of text-string values and an 629 unbounded set of any-attribute items. Described in Section 2.4, 630 Paragraph 2. 632 * tag-id (index 0): A 16-byte binary string, or a textual 633 identifier, uniquely referencing a software component. The tag 634 identifier MUST be globally unique. Failure to ensure global 635 uniqueness can create ambiguity in tag use since the tag-id serves 636 as the global key for matching and lookups. If represented as a 637 16-byte binary string, the identifier MUST be a valid universally 638 unique identifier as defined by [RFC4122]. There are no strict 639 guidelines on how the identifier is structured, but examples 640 include a 16-byte GUID (e.g., class 4 UUID) [RFC4122], or a DNS 641 domain name followed by a "/" and a text string, where the domain 642 name serves to ensure uniqueness across organizations. A textual 643 tag-id MUST NOT contain a sequence of two underscores ("__", see 644 Section 6.7). 646 * tag-version (index 12): An integer value that indicate the 647 specific release revision of the tag. Typically, the initial 648 value of this field is set to 0 and the value is increased for 649 subsequent tags produced for the same software component release. 650 This value allows a CoSWID tag producer to correct an incorrect 651 tag previously released without indicating a change to the 652 underlying software component the tag represents. For example, 653 the tag version could be changed to add new metadata, to correct a 654 broken link, to add a missing payload entry, etc. When producing 655 a revised tag, the new tag-version value MUST be greater than the 656 old tag-version value. 658 * corpus (index 8): A boolean value that indicates if the tag 659 identifies and describes an installable software component in its 660 pre-installation state. Installable software includes an 661 installation package or installer for a software component, a 662 software update, or a patch. If the CoSWID tag represents 663 installable software, the corpus item MUST be set to "true". If 664 not provided, the default value MUST be considered "false". 666 * patch (index 9): A boolean value that indicates if the tag 667 identifies and describes an installed patch that has made 668 incremental changes to a software component installed on an 669 endpoint. If a CoSWID tag is for a patch, the patch item MUST be 670 set to "true". If not provided, the default value MUST be 671 considered "false". A patch item's value MUST NOT be set to 672 "true" if the installation of the associated software package 673 changes the version of a software component. 675 * supplemental (index 11): A boolean value that indicates if the tag 676 is providing additional information to be associated with another 677 referenced SWID or CoSWID tag. This allows tools and users to 678 record their own metadata about a software component without 679 modifying SWID primary or patch tags created by a software 680 provider. If a CoSWID tag is a supplemental tag, the supplemental 681 item MUST be set to "true". If not provided, the default value 682 MUST be considered "false". 684 * software-name (index 1): This textual item provides the software 685 component's name. This name is likely the same name that would 686 appear in a package management tool. This item maps to 687 '/SoftwareIdentity/@name' in [SWID]. 689 * software-version (index 13): A textual value representing the 690 specific release or development version of the software component. 691 This item maps to '/SoftwareIdentity/@version' in [SWID]. 693 * version-scheme (index 14): An integer or textual value 694 representing the versioning scheme used for the software-version 695 item, as an integer label with text escape (Section 2, for the 696 "Version Scheme" registry Section 4.1. . If an integer value is 697 used it MUST be an index value in the range -256 to 65535. 698 Integer values in the range -256 to -1 are reserved for testing 699 and use in closed environments (see Section 6.2.2). Integer 700 values in the range 0 to 65535 correspond to registered entries in 701 the IANA "Software Tag Version Scheme Values" registry (see 702 Section 6.2.4. 704 * media (index 10): This text value is a hint to the tag consumer to 705 understand what target platform this tag applies to. This item 706 MUST be formatted as a query as defined by the W3C Media Queries 707 Recommendation (see [W3C.REC-css3-mediaqueries-20120619]). 708 Support for media queries are included here for interoperability 709 with [SWID], which does not provide any further requirements for 710 media query use. Thus, this specification does not clarify how a 711 media query is to be used for a CoSWID. 713 * software-meta (index 5): An open-ended map of key/value data 714 pairs. A number of predefined keys can be used within this item 715 providing for common usage and semantics across the industry. Use 716 of this map allows any additional attribute to be included in the 717 tag. It is expected that industry groups will use a common set of 718 attribute names to allow for interoperability within their 719 communities. Described in Section 2.8. This item maps to 720 '/SoftwareIdentity/Meta' in [SWID]. 722 * entity (index 2): Provides information about one or more 723 organizations responsible for producing the CoSWID tag, and 724 producing or releasing the software component referenced by this 725 CoSWID tag. Described in Section 2.6. 727 * link (index 4): Provides a means to establish relationship arcs 728 between the tag and another items. A given link can be used to 729 establish the relationship between tags or to reference another 730 resource that is related to the CoSWID tag, e.g., vulnerability 731 database association, ROLIE feed [RFC8322], MUD resource 732 [RFC8520], software download location, etc). This is modeled 733 after the HTML "link" element. Described in Section 2.7. 735 * payload (index 6): This item represents a collection of software 736 artifacts (described by child items) that compose the target 737 software. For example, these artifacts could be the files 738 included with an installer for a corpus tag or installed on an 739 endpoint when the software component is installed for a primary or 740 patch tag. The artifacts listed in a payload may be a superset of 741 the software artifacts that are actually installed. Based on user 742 selections at install time, an installation might not include 743 every artifact that could be created or executed on the endpoint 744 when the software component is installed or run. This item is 745 mutually exclusive to evidence, as payload can only be provided by 746 an external entity. Described in Section 2.9.3. 748 * evidence (index 3): This item can be used to record the results of 749 a software discovery process used to identify untagged software on 750 an endpoint or to represent indicators for why software is 751 believed to be installed on the endpoint. In either case, a 752 CoSWID tag can be created by the tool performing an analysis of 753 the software components installed on the endpoint. This item is 754 mutually exclusive to payload, as evidence is always generated on 755 the target device ad-hoc. Described in Section 2.9.4. 757 * $$coswid-extension: This CDDL socket is used to add new 758 information structures to the concise-swid-tag root map. See 759 Section 2.2. 761 2.4. concise-swid-tag Co-Constraints 763 The following co-constraints apply to the information provided in the 764 concise-swid-tag group. If any of these constraints is not met, a 765 signed tag cannot be used anymore as a signed statement. 767 * The patch and supplemental items MUST NOT both be set to "true". 769 * If the patch item is set to "true", the tag SHOULD contain at 770 least one link item (see Section 2.7) with both the rel item value 771 of "patches" and an href item specifying an association with the 772 software that was patched. Without at least one link item the 773 target of the patch cannot be identified and the patch tag cannot 774 be applied without external context. 776 * If the supplemental item is set to "true", the tag SHOULD contain 777 at least one link item with both the rel item value of 778 "supplemental" and an href item specifying an association with the 779 software that is supplemented. Without at least one link item the 780 target of supplement tag cannot be identified and the patch tag 781 cannot be applied without external context. 783 * If all of the corpus, patch, and supplemental items are "false", 784 or if the corpus item is set to "true", then a software-version 785 item MUST be included with a value set to the version of the 786 software component. This ensures that primary and corpus tags 787 have an identifiable software version. 789 2.5. The global-attributes Group 791 The global-attributes group provides a list of items, including an 792 optional language definition to support the processing of text-string 793 values, and an unbounded set of any-attribute items allowing for 794 additional items to be provided as a general point of extension in 795 the model. 797 The CDDL for the global-attributes follows: 799 global-attributes = ( 800 ? lang => text, 801 * any-attribute, 802 ) 804 any-attribute = ( 805 label => one-or-more / one-or-more 806 ) 808 label = text / int 809 The following describes each child item of this group. 811 * lang (index 15): A textual language tag that conforms with IANA 812 "Language Subtag Registry" [RFC5646]. The context of the 813 specified language applies to all sibling and descendant textual 814 values, unless a descendant object has defined a different 815 language tag. Thus, a new context is established when a 816 descendant object redefines a new language tag. All textual 817 values within a given context MUST be considered expressed in the 818 specified language. 820 * any-attribute: This sub-group provides a means to include 821 arbitrary information via label/index ("key") value pairs. Labels 822 can be either a single integer or text string. Values can be a 823 single integer, a text string, or an array of integers or text 824 strings. 826 2.6. The entity-entry Map 828 The CDDL for the entity-entry map follows: 830 entity-entry = { 831 entity-name => text, 832 ? reg-id => any-uri, 833 role => one-or-more<$role>, 834 ? thumbprint => hash-entry, 835 * $$entity-extension, 836 global-attributes, 837 } 839 entity-name = 31 840 reg-id = 32 841 role = 33 842 thumbprint = 34 844 $role /= tag-creator 845 $role /= software-creator 846 $role /= aggregator 847 $role /= distributor 848 $role /= licensor 849 $role /= maintainer 850 $role /= int / text 851 tag-creator=1 852 software-creator=2 853 aggregator=3 854 distributor=4 855 licensor=5 856 maintainer=6 857 The following describes each child item of this group. 859 * global-attributes: The global-attributes group described in 860 Section 2.4, Paragraph 2. 862 * entity-name (index 31): The textual name of the organizational 863 entity claiming the roles specified by the role item for the 864 CoSWID tag. This item maps to '/SoftwareIdentity/Entity/@name' in 865 [SWID]. 867 * reg-id (index 32): The registration id value is intended to 868 uniquely identify a naming authority in a given scope (e.g., 869 global, organization, vendor, customer, administrative domain, 870 etc.) for the referenced entity. The value of a registration ID 871 MUST be a RFC 3986 URI; it is not intended to be dereferenced. 872 The scope will usually be the scope of an organization. 874 * role (index 33): An integer or textual value (integer label with 875 text escape, see Section 2) representing the relationship(s) 876 between the entity, and this tag or the referenced software 877 component. If an integer value is used it MUST be an index value 878 in the range -256 to 255. Integer values in the range -256 to -1 879 are reserved for testing and use in closed environments (see 880 Section 6.2.2). Integer values in the range 0 to 255 correspond 881 to registered entries in the IANA "Software Tag Entity Role 882 Values" registry (see Section 6.2.5. 884 The following additional requirements exist for the use of the 885 "role" item: 887 - An entity item MUST be provided with the role of "tag-creator" 888 for every CoSWID tag. This indicates the organization that 889 created the CoSWID tag. 891 - An entity item SHOULD be provided with the role of "software- 892 creator" for every CoSWID tag, if this information is known to 893 the tag creator. This indicates the organization that created 894 the referenced software component. 896 * thumbprint (index 34): The value of the thumbprint item provides a 897 hash (i.e. the thumbprint) of the signing entity's public key 898 certificate. This provides an indicator of which entity signed 899 the CoSWID tag, which will typically be the tag creator. See 900 Section 2.9.1 for more details on the use of the hash-entry data 901 structure. 903 * $$entity-extension: This CDDL socket can be used to extend the 904 entity-entry group model. See Section 2.2. 906 2.7. The link-entry Map 908 The CDDL for the link-entry map follows: 910 link-entry = { 911 ? artifact => text, 912 href => any-uri, 913 ? media => text, 914 ? ownership => $ownership, 915 rel => $rel, 916 ? media-type => text, 917 ? use => $use, 918 * $$link-extension, 919 global-attributes, 920 } 922 media = 10 923 artifact = 37 924 href = 38 925 ownership = 39 926 rel = 40 927 media-type = 41 928 use = 42 930 $ownership /= shared 931 $ownership /= private 932 $ownership /= abandon 933 $ownership /= int / text 934 abandon=1 935 private=2 936 shared=3 938 $rel /= ancestor 939 $rel /= component 940 $rel /= feature 941 $rel /= installationmedia 942 $rel /= packageinstaller 943 $rel /= parent 944 $rel /= patches 945 $rel /= requires 946 $rel /= see-also 947 $rel /= supersedes 948 $rel /= supplemental 949 $rel /= -356..65536 / text 950 ancestor=1 951 component=2 952 feature=3 953 installationmedia=4 954 packageinstaller=5 955 parent=6 956 patches=7 957 requires=8 958 see-also=9 959 supersedes=10 960 supplemental=11 962 $use /= optional 963 $use /= required 964 $use /= recommended 965 $use /= int / text 966 optional=1 967 required=2 968 recommended=3 970 The following describes each member of this map. 972 * global-attributes: The global-attributes group described in 973 Section 2.4, Paragraph 2. 975 * artifact (index 37): To be used with rel="installation-media", 976 this item's value provides the absolute filesystem path to the 977 installer executable or script that can be run to launch the 978 referenced installation. Links with the same artifact name MUST 979 be considered mirrors of each other, allowing the installation 980 media to be acquired from any of the described sources. 982 * href (index 38): A URI-reference [RFC3986] for the referenced 983 resource. The "href" item's value can be, but is not limited to, 984 the following (which is a slightly modified excerpt from [SWID]): 986 - If no URI scheme is provided, then the URI-reference is a 987 relative reference relative to the base URI of the CoSWID tag, 988 i.e., the URI under which the CoSWID tag was provided. For 989 example, "./folder/supplemental.coswid". 991 - a physical resource location with any acceptable URI scheme 992 (e.g., file:// http:// https:// ftp://) 994 - a URI with "swid:" as the scheme refers to another SWID or 995 CoSWID by the referenced tag's tag-id. This URI needs to be 996 resolved in the context of the endpoint by software that can 997 lookup other SWID or CoSWID tags. For example, "swid:2df9de35- 998 0aff-4a86-ace6-f7dddd1ade4c" references the tag with the tag-id 999 value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c". 1001 - a URI with "swidpath:" as the scheme, which refers to another 1002 software tag via an XPATH query [W3C.REC-xpath20-20101214] that 1003 matches items in that tag (Section 5.2). This scheme is 1004 provided for compatibility with [SWID]. This specification 1005 does not define how to resolve an XPATH query in the context of 1006 CBOR, see Section 5.2. 1008 * media (index 10): A hint to the consumer of the link to what 1009 target platform the link is applicable to. This item represents a 1010 query as defined by the W3C Media Queries Recommendation (see 1011 [W3C.REC-css3-mediaqueries-20120619]). As highlighted in media 1012 defined in Section 2.3, support for media queries are included 1013 here for interoperability with [SWID], which does not provide any 1014 further requirements for media query use. Thus, this 1015 specification does not clarify how a media query is to be used for 1016 a CoSWID. 1018 * ownership (index 39): An integer or textual value (integer label 1019 with text escape, see Section 2, for the "Software Tag Link 1020 Ownership Values" registry Section 4.3) used when the "href" item 1021 references another software component to indicate the degree of 1022 ownership between the software component referenced by the CoSWID 1023 tag and the software component referenced by the link. If an 1024 integer value is used it MUST be an index value in the range -256 1025 to 255. Integer values in the range -256 to -1 are reserved for 1026 testing and use in closed environments (see Section 6.2.2). 1027 Integer values in the range 0 to 255 correspond to registered 1028 entries in the "Software Tag Link Ownership Values" registry. 1030 * rel (index 40): An integer or textual value that (integer label 1031 with text escape, see Section 2, for the "Software Tag Link Link 1032 Relationship Values" registry Section 4.3) identifies the 1033 relationship between this CoSWID and the target resource 1034 identified by the "href" item. If an integer value is used it 1035 MUST be an index value in the range -256 to 65535. Integer values 1036 in the range -256 to -1 are reserved for testing and use in closed 1037 environments (see Section 6.2.2). Integer values in the range 0 1038 to 65535 correspond to registered entries in the IANA "Software 1039 Tag Link Relationship Values" registry (see Section 6.2.7. If a 1040 string value is used it MUST be either a private use name as 1041 defined in Section 6.2.2 or a "Relation Name" from the IANA "Link 1042 Relation Types" registry: https://www.iana.org/assignments/link- 1043 relations/link-relations.xhtml as defined by [RFC8288]. When a 1044 string value defined in the IANA "Software Tag Link Relationship 1045 Values" registry matches a Relation Name defined in the IANA "Link 1046 Relation Types" registry, the index value in the IANA "Software 1047 Tag Link Relationship Values" registry MUST be used instead, as 1048 this relationship has a specialized meaning in the context of a 1049 CoSWID tag. String values correspond to registered entries in the 1050 "Software Tag Link Relationship Values" registry. 1052 * media-type (index 41): A link can point to arbitrary resources on 1053 the endpoint, local network, or Internet using the href item. Use 1054 of this item supplies the resource consumer with a hint of what 1055 type of resource to expect. (This is a _hint_: There is no 1056 obligation for the server hosting the target of the URI to use the 1057 indicated media type when the URI is dereferenced.) Media types 1058 are identified by referencing a "Name" from the IANA "Media Types" 1059 registry: http://www.iana.org/assignments/media-types/media- 1060 types.xhtml. This item maps to '/SoftwareIdentity/Link/@type' in 1061 [SWID]. 1063 * use (index 42): An integer or textual value (integer label with 1064 text escape, see Section 2, for the "Software Tag Link Link 1065 Relationship Values" registry Section 4.3) used to determine if 1066 the referenced software component has to be installed before 1067 installing the software component identified by the COSWID tag. 1068 If an integer value is used it MUST be an index value in the range 1069 -256 to 255. Integer values in the range -256 to -1 are reserved 1070 for testing and use in closed environments (see Section 6.2.2). 1071 Integer values in the range 0 to 255 correspond to registered 1072 entries in the IANA "Link Use Values" registry (see Section 6.2.8. 1073 If a string value is used it MUST be a private use name as defined 1074 in Section 6.2.2. String values correspond to registered entries 1075 in the "Software Tag Link Use Values" registry. 1077 * $$link-extension: This CDDL socket can be used to extend the link- 1078 entry map model. See Section 2.2. 1080 2.8. The software-meta-entry Map 1082 The CDDL for the software-meta-entry map follows: 1084 software-meta-entry = { 1085 ? activation-status => text, 1086 ? channel-type => text, 1087 ? colloquial-version => text, 1088 ? description => text, 1089 ? edition => text, 1090 ? entitlement-data-required => bool, 1091 ? entitlement-key => text, 1092 ? generator => text / bstr .size 16, 1093 ? persistent-id => text, 1094 ? product => text, 1095 ? product-family => text, 1096 ? revision => text, 1097 ? summary => text, 1098 ? unspsc-code => text, 1099 ? unspsc-version => text, 1100 * $$software-meta-extension, 1101 global-attributes, 1102 } 1104 activation-status = 43 1105 channel-type = 44 1106 colloquial-version = 45 1107 description = 46 1108 edition = 47 1109 entitlement-data-required = 48 1110 entitlement-key = 49 1111 generator = 50 1112 persistent-id = 51 1113 product = 52 1114 product-family = 53 1115 revision = 54 1116 summary = 55 1117 unspsc-code = 56 1118 unspsc-version = 57 1120 The following describes each child item of this group. 1122 * global-attributes: The global-attributes group described in 1123 Section 2.4, Paragraph 2. 1125 * activation-status (index 43): A textual value that identifies how 1126 the software component has been activated, which might relate to 1127 specific terms and conditions for its use (e.g., Trial, 1128 Serialized, Licensed, Unlicensed, etc) and relate to an 1129 entitlement. This attribute is typically used in supplemental 1130 tags as it contains information that might be selected during a 1131 specific install. 1133 * channel-type (index 44): A textual value that identifies which 1134 sales, licensing, or marketing channel the software component has 1135 been targeted for (e.g., Volume, Retail, OEM, Academic, etc). 1136 This attribute is typically used in supplemental tags as it 1137 contains information that might be selected during a specific 1138 install. 1140 * colloquial-version (index 45): A textual value for the software 1141 component's informal or colloquial version. Examples may include 1142 a year value, a major version number, or similar value that are 1143 used to identify a group of specific software component releases 1144 that are part of the same release/support cycle. This version can 1145 be the same through multiple releases of a software component, 1146 while the software-version specified in the concise-swid-tag group 1147 is much more specific and will change for each software component 1148 release. This version is intended to be used for string 1149 comparison (byte-by-byte) only and is not intended to be used to 1150 determine if a specific value is earlier or later in a sequence. 1152 * description (index 46): A textual value that provides a detailed 1153 description of the software component. This value MAY be multiple 1154 paragraphs separated by CR LF characters as described by 1155 [RFC5198]. 1157 * edition (index 47): A textual value indicating that the software 1158 component represents a functional variation of the code base used 1159 to support multiple software components. For example, this item 1160 can be used to differentiate enterprise, standard, or professional 1161 variants of a software component. 1163 * entitlement-data-required (index 48): A boolean value that can be 1164 used to determine if accompanying proof of entitlement is needed 1165 when a software license reconciliation process is performed. 1167 * entitlement-key (index 49): A vendor-specific textual key that can 1168 be used to identify and establish a relationship to an 1169 entitlement. Examples of an entitlement-key might include a 1170 serial number, product key, or license key. For values that 1171 relate to a given software component install (i.e., license key), 1172 a supplemental tag will typically contain this information. In 1173 other cases, where a general-purpose key can be provided that 1174 applies to all possible installs of the software component on 1175 different endpoints, a primary tag will typically contain this 1176 information. Since CoSWID tags are not intended to contain 1177 confidential information, tag authors are advised not to record 1178 unprotected, private software license keys in this field. 1180 * generator (index 50): The name (or tag-id) of the software 1181 component that created the CoSWID tag. If the generating software 1182 component has a SWID or CoSWID tag, then the tag-id for the 1183 generating software component SHOULD be provided. 1185 * persistent-id (index 51): A globally unique identifier used to 1186 identify a set of software components that are related. Software 1187 components sharing the same persistent-id can be different 1188 versions. This item can be used to relate software components, 1189 released at different points in time or through different release 1190 channels, that may not be able to be related through use of the 1191 link item. 1193 * product (index 52): A basic name for the software component that 1194 can be common across multiple tagged software components (e.g., 1195 Apache HTTPD). 1197 * product-family (index 53): A textual value indicating the software 1198 components overall product family. This should be used when 1199 multiple related software components form a larger capability that 1200 is installed on multiple different endpoints. For example, some 1201 software families may consist of server, client, and shared 1202 service components that are part of a larger capability. Email 1203 systems, enterprise applications, backup services, web 1204 conferencing, and similar capabilities are examples of families. 1205 Use of this item is not intended to represent groups of software 1206 that are bundled or installed together. The persistent-id or link 1207 items SHOULD be used to relate bundled software components. 1209 * revision (index 54): A string value indicating an informal or 1210 colloquial release version of the software. This value can 1211 provide a different version value as compared to the software- 1212 version specified in the concise-swid-tag group. This is useful 1213 when one or more releases need to have an informal version label 1214 that differs from the specific exact version value specified by 1215 software-version. Examples can include SP1, RC1, Beta, etc. 1217 * summary (index 55): A short description of the software component. 1218 This MUST be a single sentence suitable for display in a user 1219 interface. 1221 * unspsc-code (index 56): An 8 digit UNSPSC classification code for 1222 the software component as defined by the United Nations Standard 1223 Products and Services Code (UNSPSC, [UNSPSC]). 1225 * unspsc-version (index 57): The version of UNSPSC used to define 1226 the unspsc-code value. 1228 * $$meta-extension: This CDDL socket can be used to extend the 1229 software-meta-entry group model. See Section 2.2. 1231 2.9. The Resource Collection Definition 1233 2.9.1. The hash-entry Array 1235 CoSWID adds explicit support for the representation of hash entries 1236 using algorithms that are registered in the IANA "Named Information 1237 Hash Algorithm Registry" [IANA.named-information] using the hash 1238 member (index 7) and the corresponding hash-entry type. This is the 1239 equivalent of the namespace qualified "hash" attribute in [SWID]. 1241 hash-entry = [ 1242 hash-alg-id: int, 1243 hash-value: bytes, 1244 ] 1246 The number used as a value for hash-alg-id is an integer-based hash 1247 algorithm identifier who's value MUST refer to an ID in the IANA 1248 "Named Information Hash Algorithm Registry" [IANA.named-information] 1249 with a Status of "current" (at the time the generator software was 1250 built or later); other hash algorithms MUST NOT be used. If the 1251 hash-alg-id is not known, then the integer value "0" MUST be used. 1252 This allows for conversion from ISO SWID tags [SWID], which do not 1253 allow an algorithm to be identified for this field. 1255 The hash-value MUST represent the raw hash value as a byte string (as 1256 opposed to, e.g., base64 encoded) generated from the representation 1257 of the resource using the hash algorithm indicated by hash-alg-id. 1259 2.9.2. The resource-collection Group 1261 A list of items both used in evidence (created by a software 1262 discovery process) and payload (installed in an endpoint) content of 1263 a CoSWID tag document to structure and differentiate the content of 1264 specific CoSWID tag types. Potential content includes directories, 1265 files, processes, or resources. 1267 The CDDL for the resource-collection group follows: 1269 path-elements-group = ( ? directory => one-or-more, 1270 ? file => one-or-more, 1271 ) 1273 resource-collection = ( 1274 path-elements-group, 1275 ? process => one-or-more, 1276 ? resource => one-or-more, 1277 * $$resource-collection-extension, 1278 ) 1280 filesystem-item = ( 1281 ? key => bool, 1282 ? location => text, 1283 fs-name => text, 1284 ? root => text, 1285 ) 1287 file-entry = { 1288 filesystem-item, 1289 ? size => uint, 1290 ? file-version => text, 1291 ? hash => hash-entry, 1292 * $$file-extension, 1293 global-attributes, 1294 } 1296 directory-entry = { 1297 filesystem-item, 1298 ? path-elements => { path-elements-group }, 1299 * $$directory-extension, 1300 global-attributes, 1301 } 1303 process-entry = { 1304 process-name => text, 1305 ? pid => integer, 1306 * $$process-extension, 1307 global-attributes, 1308 } 1310 resource-entry = { 1311 type => text, 1312 * $$resource-extension, 1313 global-attributes, 1314 } 1316 directory = 16 1317 file = 17 1318 process = 18 1319 resource = 19 1320 size = 20 1321 file-version = 21 1322 key = 22 1323 location = 23 1324 fs-name = 24 1325 root = 25 1326 path-elements = 26 1327 process-name = 27 1328 pid = 28 1329 type = 29 1331 The following describes each member of the groups and maps 1332 illustrated above. 1334 * filesystem-item: A list of common items used for representing the 1335 filesystem root, relative location, name, and significance of a 1336 file or directory item. 1338 * global-attributes: The global-attributes group described in 1339 Section 2.4, Paragraph 2. 1341 * directory (index 16): A directory item allows child directory and 1342 file items to be defined within a directory hierarchy for the 1343 software component. 1345 * file (index 17): A file item allows details about a file to be 1346 provided for the software component. 1348 * process (index 18): A process item allows details to be provided 1349 about the runtime behavior of the software component, such as 1350 information that will appear in a process listing on an endpoint. 1352 * resource (index 19): A resource item can be used to provide 1353 details about an artifact or capability expected to be found on an 1354 endpoint or evidence collected related to the software component. 1355 This can be used to represent concepts not addressed directly by 1356 the directory, file, or process items. Examples include: registry 1357 keys, bound ports, etc. The equivalent construct in [SWID] is 1358 currently under specified. As a result, this item might be 1359 further defined through extension in the future. 1361 * size (index 20): The file's size in bytes. 1363 * file-version (index 21): The file's version as reported by 1364 querying information on the file from the operating system (if 1365 available). This item maps to 1366 '/SoftwareIdentity/(Payload|Evidence)/File/@version' in [SWID]. 1368 * hash (index 7): A hash of the file as described in Section 2.9.1. 1370 * key (index 22): A boolean value indicating if a file or directory 1371 is significant or required for the software component to execute 1372 or function properly. These are files or directories that can be 1373 used to affirmatively determine if the software component is 1374 installed on an endpoint. 1376 * location (index 23): The filesystem path where a file is expected 1377 to be located when installed or copied. The location MUST be 1378 either relative to the location of the parent directory item 1379 (preferred), or relative to the location of the CoSWID tag (as 1380 indicated in the location value in the evidence entry map) if no 1381 parent is defined. The location MUST NOT include a file's name, 1382 which is provided by the fs-name item. 1384 * fs-name (index 24): The name of the directory or file without any 1385 path information. This aligns with a file "name" in [SWID]. This 1386 item maps to 1387 '/SoftwareIdentity/(Payload|Evidence)/(File|Directory)/@name' in 1388 [SWID]. 1390 * root (index 25): A host-specific name for the root of the 1391 filesystem. The location item is considered relative to this 1392 location if specified. If not provided, the value provided by the 1393 location item is expected to be relative to its parent or the 1394 location of the CoSWID tag if no parent is provided. 1396 * path-elements (index 26): This group allows a hierarchy of 1397 directory and file items to be defined in payload or evidence 1398 items. This is a construction within the CDDL definition of 1399 CoSWID to support shared syntax and does not appear in [SWID]. 1401 * process-name (index 27): The software component's process name as 1402 it will appear in an endpoint's process list. This aligns with a 1403 process "name" in [SWID]. This item maps to 1404 '/SoftwareIdentity/(Payload|Evidence)/Process/@name' in [SWID]. 1406 * pid (index 28): The process ID identified for a running instance 1407 of the software component in the endpoint's process list. This is 1408 used as part of the evidence item. 1410 * type (index 29): A human-readable string indicating the type of 1411 resource. 1413 * $$resource-collection-extension: This CDDL socket can be used to 1414 extend the resource-collection group model. This can be used to 1415 add new specialized types of resources. See Section 2.2. 1417 * $$file-extension: This CDDL socket can be used to extend the file- 1418 entry group model. See Section 2.2. 1420 * $$directory-extension: This CDDL socket can be used to extend the 1421 directory-entry group model. See Section 2.2. 1423 * $$process-extension: This CDDL socket can be used to extend the 1424 process-entry group model. See Section 2.2. 1426 * $$resource-extension: This CDDL socket can be used to extend the 1427 resource-entry group model. See Section 2.2. 1429 2.9.3. The payload-entry Map 1431 The CDDL for the payload-entry map follows: 1433 payload-entry = { 1434 resource-collection, 1435 * $$payload-extension, 1436 global-attributes, 1437 } 1439 The following describes each child item of this group. 1441 * global-attributes: The global-attributes group described in 1442 Section 2.4, Paragraph 2. 1444 * resource-collection: The resource-collection group described in 1445 Section 2.9.2. 1447 * $$payload-extension: This CDDL socket can be used to extend the 1448 payload-entry group model. See Section 2.2. 1450 2.9.4. The evidence-entry Map 1452 The CDDL for the evidence-entry map follows: 1454 evidence-entry = { 1455 resource-collection, 1456 ? date => integer-time, 1457 ? device-id => text, 1458 ? location => text, 1459 * $$evidence-extension, 1460 global-attributes, 1461 } 1463 date = 35 1464 device-id = 36 1466 The following describes each child item of this group. 1468 * global-attributes: The global-attributes group described in 1469 Section 2.4, Paragraph 2. 1471 * resource-collection: The resource-collection group described in 1472 Section 2.9.2. 1474 * date (index 35): The date and time the information was collected 1475 pertaining to the evidence item. 1477 * device-id (index 36): The endpoint's string identifier from which 1478 the evidence was collected. 1480 * location (index 23): The absolute filepath of the location of the 1481 CoSWID tag generated as evidence. (Location values in filesystem- 1482 items in the payload can be expressed relative to this location.) 1484 * $$evidence-extension: This CDDL socket can be used to extend the 1485 evidence-entry group model. See Section 2.2. 1487 2.10. Full CDDL Specification 1489 In order to create a valid CoSWID document the structure of the 1490 corresponding CBOR message MUST adhere to the following CDDL 1491 specification. 1493 1494 concise-swid-tag = { 1495 tag-id => text / bstr .size 16, 1496 tag-version => integer, 1497 ? corpus => bool, 1498 ? patch => bool, 1499 ? supplemental => bool, 1500 software-name => text, 1501 ? software-version => text, 1502 ? version-scheme => $version-scheme, 1503 ? media => text, 1504 ? software-meta => one-or-more, 1505 entity => one-or-more, 1506 ? link => one-or-more, 1507 ? payload-or-evidence, 1508 * $$coswid-extension, 1509 global-attributes, 1510 } 1512 payload-or-evidence //= ( payload => payload-entry ) 1513 payload-or-evidence //= ( evidence => evidence-entry ) 1515 any-uri = uri 1516 label = text / int 1518 $version-scheme /= multipartnumeric 1519 $version-scheme /= multipartnumeric-suffix 1520 $version-scheme /= alphanumeric 1521 $version-scheme /= decimal 1522 $version-scheme /= semver 1523 $version-scheme /= int / text 1525 any-attribute = ( 1526 label => one-or-more / one-or-more 1527 ) 1529 one-or-more = T / [ 2* T ] 1531 global-attributes = ( 1532 ? lang => text, 1533 * any-attribute, 1534 ) 1536 hash-entry = [ 1537 hash-alg-id: int, 1538 hash-value: bytes, 1539 ] 1541 entity-entry = { 1542 entity-name => text, 1543 ? reg-id => any-uri, 1544 role => one-or-more<$role>, 1545 ? thumbprint => hash-entry, 1546 * $$entity-extension, 1547 global-attributes, 1548 } 1549 $role /= tag-creator 1550 $role /= software-creator 1551 $role /= aggregator 1552 $role /= distributor 1553 $role /= licensor 1554 $role /= maintainer 1555 $role /= int / text 1557 link-entry = { 1558 ? artifact => text, 1559 href => any-uri, 1560 ? media => text, 1561 ? ownership => $ownership, 1562 rel => $rel, 1563 ? media-type => text, 1564 ? use => $use, 1565 * $$link-extension, 1566 global-attributes, 1567 } 1569 $ownership /= shared 1570 $ownership /= private 1571 $ownership /= abandon 1572 $ownership /= int / text 1574 $rel /= ancestor 1575 $rel /= component 1576 $rel /= feature 1577 $rel /= installationmedia 1578 $rel /= packageinstaller 1579 $rel /= parent 1580 $rel /= patches 1581 $rel /= requires 1582 $rel /= see-also 1583 $rel /= supersedes 1584 $rel /= supplemental 1585 $rel /= -256..64436 / text 1587 $use /= optional 1588 $use /= required 1589 $use /= recommended 1590 $use /= int / text 1592 software-meta-entry = { 1593 ? activation-status => text, 1594 ? channel-type => text, 1595 ? colloquial-version => text, 1596 ? description => text, 1597 ? edition => text, 1598 ? entitlement-data-required => bool, 1599 ? entitlement-key => text, 1600 ? generator => text / bstr .size 16, 1601 ? persistent-id => text, 1602 ? product => text, 1603 ? product-family => text, 1604 ? revision => text, 1605 ? summary => text, 1606 ? unspsc-code => text, 1607 ? unspsc-version => text, 1608 * $$software-meta-extension, 1609 global-attributes, 1610 } 1612 path-elements-group = ( ? directory => one-or-more, 1613 ? file => one-or-more, 1614 ) 1616 resource-collection = ( 1617 path-elements-group, 1618 ? process => one-or-more, 1619 ? resource => one-or-more, 1620 * $$resource-collection-extension, 1621 ) 1623 file-entry = { 1624 filesystem-item, 1625 ? size => uint, 1626 ? file-version => text, 1627 ? hash => hash-entry, 1628 * $$file-extension, 1629 global-attributes, 1630 } 1632 directory-entry = { 1633 filesystem-item, 1634 ? path-elements => { path-elements-group }, 1635 * $$directory-extension, 1636 global-attributes, 1637 } 1639 process-entry = { 1640 process-name => text, 1641 ? pid => integer, 1642 * $$process-extension, 1643 global-attributes, 1644 } 1645 resource-entry = { 1646 type => text, 1647 * $$resource-extension, 1648 global-attributes, 1649 } 1651 filesystem-item = ( 1652 ? key => bool, 1653 ? location => text, 1654 fs-name => text, 1655 ? root => text, 1656 ) 1658 payload-entry = { 1659 resource-collection, 1660 * $$payload-extension, 1661 global-attributes, 1662 } 1664 evidence-entry = { 1665 resource-collection, 1666 ? date => integer-time, 1667 ? device-id => text, 1668 ? location => text, 1669 * $$evidence-extension, 1670 global-attributes, 1671 } 1673 integer-time = #6.1(int) 1675 ; "global map member" integer indexes 1676 tag-id = 0 1677 software-name = 1 1678 entity = 2 1679 evidence = 3 1680 link = 4 1681 software-meta = 5 1682 payload = 6 1683 hash = 7 1684 corpus = 8 1685 patch = 9 1686 media = 10 1687 supplemental = 11 1688 tag-version = 12 1689 software-version = 13 1690 version-scheme = 14 1691 lang = 15 1692 directory = 16 1693 file = 17 1694 process = 18 1695 resource = 19 1696 size = 20 1697 file-version = 21 1698 key = 22 1699 location = 23 1700 fs-name = 24 1701 root = 25 1702 path-elements = 26 1703 process-name = 27 1704 pid = 28 1705 type = 29 1706 entity-name = 31 1707 reg-id = 32 1708 role = 33 1709 thumbprint = 34 1710 date = 35 1711 device-id = 36 1712 artifact = 37 1713 href = 38 1714 ownership = 39 1715 rel = 40 1716 media-type = 41 1717 use = 42 1718 activation-status = 43 1719 channel-type = 44 1720 colloquial-version = 45 1721 description = 46 1722 edition = 47 1723 entitlement-data-required = 48 1724 entitlement-key = 49 1725 generator = 50 1726 persistent-id = 51 1727 product = 52 1728 product-family = 53 1729 revision = 54 1730 summary = 55 1731 unspsc-code = 56 1732 unspsc-version = 57 1734 ; "version-scheme" integer indexes 1735 multipartnumeric = 1 1736 multipartnumeric-suffix = 2 1737 alphanumeric = 3 1738 decimal = 4 1739 semver = 16384 1740 ; "role" integer indexes 1741 tag-creator=1 1742 software-creator=2 1743 aggregator=3 1744 distributor=4 1745 licensor=5 1746 maintainer=6 1748 ; "ownership" integer indexes 1749 abandon=1 1750 private=2 1751 shared=3 1753 ; "rel" integer indexes 1754 ancestor=1 1755 component=2 1756 feature=3 1757 installationmedia=4 1758 packageinstaller=5 1759 parent=6 1760 patches=7 1761 requires=8 1762 see-also=9 1763 supersedes=10 1764 ; supplemental=11 ; this is already defined earlier 1766 ; "use" integer indexes 1767 optional=1 1768 required=2 1769 recommended=3 1770 1772 3. Determining the Type of CoSWID 1774 The operational model for SWID and CoSWID tags was introduced in 1775 Section 1.1, which described four different CoSWID tag types. The 1776 following additional rules apply to the use of CoSWID tags to ensure 1777 that created tags properly identify the tag type. 1779 The first matching rule MUST determine the type of the CoSWID tag. 1781 1. Primary Tag: A CoSWID tag MUST be considered a primary tag if the 1782 corpus, patch, and supplemental items are "false". 1784 2. Supplemental Tag: A CoSWID tag MUST be considered a supplemental 1785 tag if the supplemental item is set to "true". 1787 3. Corpus Tag: A CoSWID tag MUST be considered a corpus tag if the 1788 corpus item is "true". 1790 4. Patch Tag: A CoSWID tag MUST be considered a patch tag if the 1791 patch item is "true". 1793 Note: Multiple of the corpus, patch, and supplemental items can have 1794 values set as "true". The rules above provide a means to determine 1795 the tag's type in such a case. For example, a SWID or CoSWID tag for 1796 a patch installer might have both corpus and patch items set to 1797 "true". In such a case, the tag is a "Corpus Tag". The tag 1798 installed by this installer would have only the patch item set to 1799 "true", making the installed tag type a "Patch Tag". 1801 4. CoSWID Indexed Label Values 1803 This section defines a number of kinds of indexed label values that 1804 are maintained in a registry each (Section 6). These values are 1805 represented as positive integers. In each registry, the value 0 is 1806 marked as Reserved. 1808 4.1. Version Scheme 1810 The following table contains a set of values for use in the concise- 1811 swid-tag group's version-scheme item. Version Scheme Name strings 1812 match the version schemes defined in the ISO/IEC 19770-2:2015 [SWID] 1813 specification. Index value indicates the value to use as the 1814 version-scheme item's value. The Version Scheme Name provides human- 1815 readable text for the value. The Definition describes the syntax of 1816 allowed values for each entry. 1818 +=======+=========================+===============================+ 1819 | Index | Version Scheme Name | Definition | 1820 +=======+=========================+===============================+ 1821 | 1 | multipartnumeric | Numbers separated by dots, | 1822 | | | where the numbers are | 1823 | | | interpreted as decimal | 1824 | | | integers (e.g., 1.2.3, | 1825 | | | 1.2.3.4.5.6.7, 1.4.5, 1.21) | 1826 +-------+-------------------------+-------------------------------+ 1827 | 2 | multipartnumeric+suffix | Numbers separated by dots, | 1828 | | | where the numbers are | 1829 | | | interpreted as decimal | 1830 | | | integers with an additional | 1831 | | | textual suffix (e.g., 1.2.3a) | 1832 +-------+-------------------------+-------------------------------+ 1833 | 3 | alphanumeric | Strictly a string, no | 1834 | | | interpretation as number | 1835 +-------+-------------------------+-------------------------------+ 1836 | 4 | decimal | A single decimal floating | 1837 | | | point number | 1838 +-------+-------------------------+-------------------------------+ 1839 | 16384 | semver | A semantic version as defined | 1840 | | | by [SWID]. Also see the | 1841 | | | [SEMVER] specification for | 1842 | | | more information | 1843 +-------+-------------------------+-------------------------------+ 1845 Table 3: Version Scheme Values 1847 multipartnumeric and the numbers part of multipartnumeric+suffix are 1848 interpreted as a sequence of numbers and are sorted in 1849 lexicographical order by these numbers (i.e., not by the digits in 1850 the numbers) and then the textual suffix (for 1851 multipartnumeric+suffix). Alphanumeric strings are sorted 1852 lexicographically as character strings. Decimal version numbers are 1853 interpreted as a single floating point number (e.g., 1.25 is less 1854 than 1.3). 1856 The values above are registered in the IANA "Software Tag Version 1857 Scheme Values" registry defined in Section Section 6.2.4. Additional 1858 entries will likely be registered over time in this registry. 1860 A CoSWID producer that is aware of the version scheme that has been 1861 used to select the version value, SHOULD include the optional 1862 version-scheme item to avoid semantic ambiguity. If the CoSWID 1863 producer does not have this information, it SHOULD omit the version- 1864 scheme item. The following heuristics can be used by a CoSWID 1865 consumer, based on the version schemes' partially overlapping value 1866 spaces: 1868 * "decimal" and "multipartnumeric" partially overlap in their value 1869 space when a value matches a decimal number. When a corresponding 1870 software-version item's value falls within this overlapping value 1871 space, the "decimal" version scheme SHOULD be assumed. 1873 * "multipartnumeric" and "semver" partially overlap in their value 1874 space when a "multipartnumeric" value matches the semantic 1875 versioning syntax. When a corresponding software-version item's 1876 value falls within this overlapping value space, the "semver" 1877 version scheme SHOULD be assumed. 1879 * "alphanumeric" and other version schemes might overlap in their 1880 value space. When a corresponding software-version item's value 1881 falls within this overlapping value space, the other version 1882 scheme SHOULD be assumed instead of "alphanumeric". 1884 Note that these heuristics are imperfect and can guess wrong, which 1885 is the reason the version-scheme item SHOULD be included by the 1886 producer. 1888 4.2. Entity Role Values 1890 The following table indicates the index value to use for the entity- 1891 entry group's role item (see Section 2.6). These values match the 1892 entity roles defined in the ISO/IEC 19770-2:2015 [SWID] 1893 specification. The "Index" value indicates the value to use as the 1894 role item's value. The "Role Name" provides human-readable text for 1895 the value. The "Definition" describes the semantic meaning of each 1896 entry. 1898 +=======+=================+========================================+ 1899 | Index | Role Name | Definition | 1900 +=======+=================+========================================+ 1901 | 1 | tagCreator | The person or organization that | 1902 | | | created the containing SWID or CoSWID | 1903 | | | tag | 1904 +-------+-----------------+----------------------------------------+ 1905 | 2 | softwareCreator | The person or organization entity that | 1906 | | | created the software component. | 1907 +-------+-----------------+----------------------------------------+ 1908 | 3 | aggregator | From [SWID], "An organization or | 1909 | | | system that encapsulates software from | 1910 | | | their own and/or other organizations | 1911 | | | into a different distribution process | 1912 | | | (as in the case of virtualization), or | 1913 | | | as a completed system to accomplish a | 1914 | | | specific task (as in the case of a | 1915 | | | value added reseller)." | 1916 +-------+-----------------+----------------------------------------+ 1917 | 4 | distributor | From [SWID], "An entity that furthers | 1918 | | | the marketing, selling and/or | 1919 | | | distribution of software from the | 1920 | | | original place of manufacture to the | 1921 | | | ultimate user without modifying the | 1922 | | | software, its packaging or its | 1923 | | | labelling." | 1924 +-------+-----------------+----------------------------------------+ 1925 | 5 | licensor | From [SAM] as "software licensor", a | 1926 | | | "person or organization who owns or | 1927 | | | holds the rights to issue a software | 1928 | | | license for a specific software | 1929 | | | [component]" | 1930 +-------+-----------------+----------------------------------------+ 1931 | 6 | maintainer | The person or organization that is | 1932 | | | responsible for coordinating and | 1933 | | | making updates to the source code for | 1934 | | | the software component. This SHOULD | 1935 | | | be used when the "maintainer" is a | 1936 | | | different person or organization than | 1937 | | | the original "softwareCreator". | 1938 +-------+-----------------+----------------------------------------+ 1940 Table 4: Entity Role Values 1942 The values above are registered in the IANA "Software Tag Entity Role 1943 Values" registry defined in Section 6.2.5. Additional values will 1944 likely be registered over time. 1946 4.3. Link Ownership Values 1948 The following table indicates the index value to use for the link- 1949 entry group's ownership item (see Section 2.7). These values match 1950 the link ownership values defined in the ISO/IEC 19770-2:2015 [SWID] 1951 specification. The "Index" value indicates the value to use as the 1952 link-entry group ownership item's value. The "Ownership Type" 1953 provides human-readable text for the value. The "Definition" 1954 describes the semantic meaning of each entry. 1956 +=======+===========+===============================================+ 1957 | Index | Ownership | Definition | 1958 | | Type | | 1959 +=======+===========+===============================================+ 1960 | 1 | abandon | If the software component referenced by the | 1961 | | | CoSWID tag is uninstalled, then the | 1962 | | | referenced software SHOULD NOT be | 1963 | | | uninstalled | 1964 +-------+-----------+-----------------------------------------------+ 1965 | 2 | private | If the software component referenced by the | 1966 | | | CoSWID tag is uninstalled, then the | 1967 | | | referenced software SHOULD be uninstalled as | 1968 | | | well. | 1969 +-------+-----------+-----------------------------------------------+ 1970 | 3 | shared | If the software component referenced by the | 1971 | | | CoSWID tag is uninstalled, then the | 1972 | | | referenced software SHOULD be uninstalled if | 1973 | | | no other components sharing the software. | 1974 +-------+-----------+-----------------------------------------------+ 1976 Table 5: Link Ownership Values 1978 The values above are registered in the IANA "Software Tag Link 1979 Ownership Values" registry defined in Section 6.2.6. Additional 1980 values will likely be registered over time. 1982 4.4. Link Rel Values 1984 The following table indicates the index value to use for the link- 1985 entry group's rel item (see Section 2.7). These values match the 1986 link rel values defined in the ISO/IEC 19770-2:2015 [SWID] 1987 specification. The "Index" value indicates the value to use as the 1988 link-entry group ownership item's value. The "Relationship Type" 1989 provides human-readable text for the value. The "Definition" 1990 describes the semantic meaning of each entry. 1992 +=======+===================+=======================================+ 1993 | Index | Relationship Type | Definition | 1994 +=======+===================+=======================================+ 1995 | 1 | ancestor | The link references a software | 1996 | | | tag for a previous release of | 1997 | | | this software. This can be | 1998 | | | useful to define an upgrade path. | 1999 +-------+-------------------+---------------------------------------+ 2000 | 2 | component | The link references a software | 2001 | | | tag for a separate component of | 2002 | | | this software. | 2003 +-------+-------------------+---------------------------------------+ 2004 | 3 | feature | The link references a | 2005 | | | configurable feature of this | 2006 | | | software that can be enabled or | 2007 | | | disabled without changing the | 2008 | | | installed files. | 2009 +-------+-------------------+---------------------------------------+ 2010 | 4 | installationmedia | The link references the | 2011 | | | installation package that can be | 2012 | | | used to install this software. | 2013 +-------+-------------------+---------------------------------------+ 2014 | 5 | packageinstaller | The link references the | 2015 | | | installation software needed to | 2016 | | | install this software. | 2017 +-------+-------------------+---------------------------------------+ 2018 | 6 | parent | The link references a software | 2019 | | | tag that is the parent of the | 2020 | | | referencing tag. This | 2021 | | | relationship can be used when | 2022 | | | multiple software components are | 2023 | | | part of a software bundle, where | 2024 | | | the "parent" is the software tag | 2025 | | | for the bundle, and each child is | 2026 | | | a "component". In such a case, | 2027 | | | each child component can provide | 2028 | | | a "parent" link relationship to | 2029 | | | the bundle's software tag, and | 2030 | | | the bundle can provide a | 2031 | | | "component" link relationship to | 2032 | | | each child software component. | 2033 +-------+-------------------+---------------------------------------+ 2034 | 7 | patches | The link references a software | 2035 | | | tag that the referencing software | 2036 | | | patches. Typically only used for | 2037 | | | patch tags (see Section 1.1). | 2038 +-------+-------------------+---------------------------------------+ 2039 | 8 | requires | The link references a | 2040 | | | prerequisite for installing this | 2041 | | | software. A patch tag (see | 2042 | | | Section 1.1) can use this to | 2043 | | | represent base software or | 2044 | | | another patch that needs to be | 2045 | | | installed first. | 2046 +-------+-------------------+---------------------------------------+ 2047 | 9 | see-also | The link references other | 2048 | | | software that may be of interest | 2049 | | | that relates to this software. | 2050 +-------+-------------------+---------------------------------------+ 2051 | 10 | supersedes | The link references another | 2052 | | | software that this software | 2053 | | | replaces. A patch tag (see | 2054 | | | Section 1.1) can use this to | 2055 | | | represent another patch that this | 2056 | | | patch incorporates or replaces. | 2057 +-------+-------------------+---------------------------------------+ 2058 | 11 | supplemental | The link references a software | 2059 | | | tag that the referencing tag | 2060 | | | supplements. Used on | 2061 | | | supplemental tags (see | 2062 | | | Section 1.1). | 2063 +-------+-------------------+---------------------------------------+ 2065 Table 6: Link Relationship Values 2067 The values above are registered in the IANA "Software Tag Link 2068 Relationship Values" registry defined in Section 6.2.7. Additional 2069 values will likely be registered over time. 2071 4.5. Link Use Values 2073 The following table indicates the index value to use for the link- 2074 entry group's use item (see Section 2.7). These values match the 2075 link use values defined in the ISO/IEC 19770-2:2015 [SWID] 2076 specification. The "Index" value indicates the value to use as the 2077 link-entry group use item's value. The "Use Type" provides human- 2078 readable text for the value. The "Definition" describes the semantic 2079 meaning of each entry. 2081 +=======+=============+========================================+ 2082 | Index | Use Type | Definition | 2083 +=======+=============+========================================+ 2084 | 1 | optional | From [SWID], "Not absolutely required; | 2085 | | | the [Link]'d software is installed | 2086 | | | only when specified." | 2087 +-------+-------------+----------------------------------------+ 2088 | 2 | required | From [SWID], "The [Link]'d software is | 2089 | | | absolutely required for an operation | 2090 | | | software installation." | 2091 +-------+-------------+----------------------------------------+ 2092 | 3 | recommended | From [SWID], "Not absolutely required; | 2093 | | | the [Link]'d software is installed | 2094 | | | unless specified otherwise." | 2095 +-------+-------------+----------------------------------------+ 2097 Table 7: Link Use Values 2099 The values above are registered in the IANA "Software Tag Link Use 2100 Values" registry defined in Section 6.2.8. Additional values will 2101 likely be registered over time. 2103 5. URI Schemes 2105 This specification defines the following URI schemes for use in 2106 CoSWID and to provide interoperability with schemes used in [SWID]. 2108 Note: These URI schemes are used in [SWID] without an IANA 2109 registration. The present specification ensures that these URI 2110 schemes are properly defined going forward. 2112 // RFC Ed.: throughout this section, please replace RFC-AAAA with the 2113 // RFC number of this specification and remove this note. 2115 5.1. "swid" URI Scheme 2117 There is a need for a scheme name that can be used in URIs that point 2118 to a specific software tag by that tag's tag-id, such as the use of 2119 the link entry as described in Section 2.7. Since this scheme is 2120 used both in a standards track document and an ISO standard, this 2121 scheme needs to be used without fear of conflicts with current or 2122 future actual schemes. In Section 6.6.1, the scheme "swid" is 2123 registered as a 'permanent' scheme for that purpose. 2125 URIs specifying the "swid" scheme are used to reference a software 2126 tag by its tag-id. A tag-id referenced in this way can be used to 2127 identify the tag resource in the context of where it is referenced 2128 from. For example, when a tag is installed on a given device, that 2129 tag can reference related tags on the same device using URIs with 2130 this scheme. 2132 For URIs that use the "swid" scheme, the scheme specific part MUST 2133 consist of a referenced software tag's tag-id. This tag-id MUST be 2134 URI encoded according to [RFC3986] Section 2.1. 2136 The following expression is a valid example: 2138 swid:2df9de35-0aff-4a86-ace6-f7dddd1ade4c 2140 5.2. "swidpath" URI Scheme 2142 There is a need for a scheme name that can be used in URIs to 2143 identify a collection of specific software tags with data elements 2144 that match an XPath expression, such as the use of the link entry as 2145 described in Section 2.7. The scheme named "swidpath" is used for 2146 this purpose in [SWID], but not registered. To enable usage without 2147 fear of conflicts with current or future actual schemes, the present 2148 document registers it as a 'permanent' scheme for that purpose (see 2149 Section 6.6.2). 2151 URIs specifying the "swidpath" scheme are used to filter tags out of 2152 a base collection, so that matching tags are included in the 2153 identified tag collection. The XPath expression 2154 [W3C.REC-xpath20-20101214] references the data that must be found in 2155 a given software tag out of base collection for that tag to be 2156 considered a matching tag. Tags to be evaluated (the base 2157 collection) include all tags in the context of where the "swidpath 2158 URI" is referenced from. For example, when a tag is installed on a 2159 given device, that tag can reference related tags on the same device 2160 using a URI with this scheme. 2162 For URIs that use the "swidpath" scheme, the following requirements 2163 apply: 2165 * The scheme specific part MUST be an XPath expression as defined by 2166 [W3C.REC-xpath20-20101214]. The included XPath expression will be 2167 URI encoded according to [RFC3986] Section 2.1. 2169 * This XPath is evaluated over SWID tags, or COSWID tags transformed 2170 into SWID tags, found on a system. A given tag MUST be considered 2171 a match if the XPath evaluation result value has an effective 2172 boolean value of "true" according to [W3C.REC-xpath20-20101214] 2173 Section 2.4.3. 2175 6. IANA Considerations 2177 This document has a number of IANA considerations, as described in 2178 the following subsections. In summary, 6 new registries are 2179 established with this request, with initial entries provided for each 2180 registry. New values for 5 other registries are also requested. 2182 6.1. CoSWID Items Registry 2184 This registry uses integer values as index values in CBOR maps. 2186 This document defines a new registry titled "CoSWID Items". Future 2187 registrations for this registry are to be made based on [BCP26] as 2188 follows: 2190 +==================+=====================================+ 2191 | Range | Registration Procedures | 2192 +==================+=====================================+ 2193 | 0-32767 | Standards Action with Expert Review | 2194 +------------------+-------------------------------------+ 2195 | 32768-4294967295 | Specification Required | 2196 +------------------+-------------------------------------+ 2198 Table 8: CoSWID Items Registration Procedures 2200 All negative values are reserved for Private Use. 2202 Initial registrations for the "CoSWID Items" registry are provided 2203 below. Assignments consist of an integer index value, the item name, 2204 and a reference to the defining specification. 2206 +===============+===========================+===============+ 2207 | Index | Item Name | Specification | 2208 +===============+===========================+===============+ 2209 | 0 | tag-id | RFC-AAAA | 2210 +---------------+---------------------------+---------------+ 2211 | 1 | software-name | RFC-AAAA | 2212 +---------------+---------------------------+---------------+ 2213 | 2 | entity | RFC-AAAA | 2214 +---------------+---------------------------+---------------+ 2215 | 3 | evidence | RFC-AAAA | 2216 +---------------+---------------------------+---------------+ 2217 | 4 | link | RFC-AAAA | 2218 +---------------+---------------------------+---------------+ 2219 | 5 | software-meta | RFC-AAAA | 2220 +---------------+---------------------------+---------------+ 2221 | 6 | payload | RFC-AAAA | 2222 +---------------+---------------------------+---------------+ 2223 | 7 | hash | RFC-AAAA | 2224 +---------------+---------------------------+---------------+ 2225 | 8 | corpus | RFC-AAAA | 2226 +---------------+---------------------------+---------------+ 2227 | 9 | patch | RFC-AAAA | 2228 +---------------+---------------------------+---------------+ 2229 | 10 | media | RFC-AAAA | 2230 +---------------+---------------------------+---------------+ 2231 | 11 | supplemental | RFC-AAAA | 2232 +---------------+---------------------------+---------------+ 2233 | 12 | tag-version | RFC-AAAA | 2234 +---------------+---------------------------+---------------+ 2235 | 13 | software-version | RFC-AAAA | 2236 +---------------+---------------------------+---------------+ 2237 | 14 | version-scheme | RFC-AAAA | 2238 +---------------+---------------------------+---------------+ 2239 | 15 | lang | RFC-AAAA | 2240 +---------------+---------------------------+---------------+ 2241 | 16 | directory | RFC-AAAA | 2242 +---------------+---------------------------+---------------+ 2243 | 17 | file | RFC-AAAA | 2244 +---------------+---------------------------+---------------+ 2245 | 18 | process | RFC-AAAA | 2246 +---------------+---------------------------+---------------+ 2247 | 19 | resource | RFC-AAAA | 2248 +---------------+---------------------------+---------------+ 2249 | 20 | size | RFC-AAAA | 2250 +---------------+---------------------------+---------------+ 2251 | 21 | file-version | RFC-AAAA | 2252 +---------------+---------------------------+---------------+ 2253 | 22 | key | RFC-AAAA | 2254 +---------------+---------------------------+---------------+ 2255 | 23 | location | RFC-AAAA | 2256 +---------------+---------------------------+---------------+ 2257 | 24 | fs-name | RFC-AAAA | 2258 +---------------+---------------------------+---------------+ 2259 | 25 | root | RFC-AAAA | 2260 +---------------+---------------------------+---------------+ 2261 | 26 | path-elements | RFC-AAAA | 2262 +---------------+---------------------------+---------------+ 2263 | 27 | process-name | RFC-AAAA | 2264 +---------------+---------------------------+---------------+ 2265 | 28 | pid | RFC-AAAA | 2266 +---------------+---------------------------+---------------+ 2267 | 29 | type | RFC-AAAA | 2268 +---------------+---------------------------+---------------+ 2269 | 30 | Unassigned | | 2270 +---------------+---------------------------+---------------+ 2271 | 31 | entity-name | RFC-AAAA | 2272 +---------------+---------------------------+---------------+ 2273 | 32 | reg-id | RFC-AAAA | 2274 +---------------+---------------------------+---------------+ 2275 | 33 | role | RFC-AAAA | 2276 +---------------+---------------------------+---------------+ 2277 | 34 | thumbprint | RFC-AAAA | 2278 +---------------+---------------------------+---------------+ 2279 | 35 | date | RFC-AAAA | 2280 +---------------+---------------------------+---------------+ 2281 | 36 | device-id | RFC-AAAA | 2282 +---------------+---------------------------+---------------+ 2283 | 37 | artifact | RFC-AAAA | 2284 +---------------+---------------------------+---------------+ 2285 | 38 | href | RFC-AAAA | 2286 +---------------+---------------------------+---------------+ 2287 | 39 | ownership | RFC-AAAA | 2288 +---------------+---------------------------+---------------+ 2289 | 40 | rel | RFC-AAAA | 2290 +---------------+---------------------------+---------------+ 2291 | 41 | media-type | RFC-AAAA | 2292 +---------------+---------------------------+---------------+ 2293 | 42 | use | RFC-AAAA | 2294 +---------------+---------------------------+---------------+ 2295 | 43 | activation-status | RFC-AAAA | 2296 +---------------+---------------------------+---------------+ 2297 | 44 | channel-type | RFC-AAAA | 2298 +---------------+---------------------------+---------------+ 2299 | 45 | colloquial-version | RFC-AAAA | 2300 +---------------+---------------------------+---------------+ 2301 | 46 | description | RFC-AAAA | 2302 +---------------+---------------------------+---------------+ 2303 | 47 | edition | RFC-AAAA | 2304 +---------------+---------------------------+---------------+ 2305 | 48 | entitlement-data-required | RFC-AAAA | 2306 +---------------+---------------------------+---------------+ 2307 | 49 | entitlement-key | RFC-AAAA | 2308 +---------------+---------------------------+---------------+ 2309 | 50 | generator | RFC-AAAA | 2310 +---------------+---------------------------+---------------+ 2311 | 51 | persistent-id | RFC-AAAA | 2312 +---------------+---------------------------+---------------+ 2313 | 52 | product | RFC-AAAA | 2314 +---------------+---------------------------+---------------+ 2315 | 53 | product-family | RFC-AAAA | 2316 +---------------+---------------------------+---------------+ 2317 | 54 | revision | RFC-AAAA | 2318 +---------------+---------------------------+---------------+ 2319 | 55 | summary | RFC-AAAA | 2320 +---------------+---------------------------+---------------+ 2321 | 56 | unspsc-code | RFC-AAAA | 2322 +---------------+---------------------------+---------------+ 2323 | 57 | unspsc-version | RFC-AAAA | 2324 +---------------+---------------------------+---------------+ 2325 | 58-4294967295 | Unassigned | | 2326 +---------------+---------------------------+---------------+ 2328 Table 9: CoSWID Items Inital Registrations 2330 6.2. Software Tag Values Registries 2332 The following IANA registries provide a mechanism for new values to 2333 be added over time to common enumerations used by SWID and CoSWID. 2334 While neither the CoSWID nor SWID specification is subordinate to the 2335 other and will evolve as their respective standards group chooses, 2336 there is value in supporting alignment between the two standards. 2337 Shared use of common code points, as spelled out in these registries, 2338 will facilitate this alignment, hence the intent for shared use of 2339 these registries and the decision to use "swid" (rather than 2340 "coswid") in registry names. 2342 6.2.1. Registration Procedures 2344 The following registries allow for the registration of index values 2345 and names. New registrations will be permitted through either a 2346 Standards Action with Expert Review policy or a Specification 2347 Required policy [BCP26]. 2349 The following registries also reserve the integer-based index values 2350 in the range of -1 to -256 for private use as defined by [BCP26] in 2351 Section 4.1. This allows values -1 to -24 to be expressed as a 2352 single uint_8t in CBOR, and values -25 to -256 to be expressed using 2353 an additional uint_8t in CBOR. 2355 6.2.2. Private Use of Index and Name Values 2357 The integer-based index values in the private use range (-1 to -256) 2358 are intended for testing purposes and closed environments; values in 2359 other ranges SHOULD NOT be assigned for testing. 2361 For names that correspond to private use index values, an 2362 Internationalized Domain Name prefix MUST be used to prevent name 2363 conflicts using the form: 2365 domainprefix/name 2366 Where both "domainprefix" and "name" MUST each be either an NR-LDH 2367 label or a U-label as defined by [RFC5890], and "name" also MUST be a 2368 unique name within the namespace defined by the "domainprefix". Use 2369 of a prefix in this way allows for a name to be used in the private 2370 use range. This is consistent with the guidance in [BCP178]. 2372 6.2.3. Expert Review Criteria 2374 Designated experts MUST ensure that new registration requests meet 2375 the following additional criteria: 2377 * The requesting specification MUST provide a clear semantic 2378 definition for the new entry. This definition MUST clearly 2379 differentiate the requested entry from other previously registered 2380 entries. 2382 * The requesting specification MUST describe the intended use of the 2383 entry, including any co-constraints that exist between the use of 2384 the entry's index value or name, and other values defined within 2385 the SWID/CoSWID model. 2387 * Index values and names outside the private use space MUST NOT be 2388 used without registration. This is considered squatting and MUST 2389 be avoided. Designated experts MUST ensure that reviewed 2390 specifications register all appropriate index values and names. 2392 * Standards track documents MAY include entries registered in the 2393 range reserved for entries under the Specification Required 2394 policy. This can occur when a standards track document provides 2395 further guidance on the use of index values and names that are in 2396 common use, but were not registered with IANA. This situation 2397 SHOULD be avoided. 2399 * All registered names MUST be valid according to the XML Schema 2400 NMTOKEN data type (see [W3C.REC-xmlschema-2-20041028] 2401 Section 3.3.4). This ensures that registered names are compatible 2402 with the SWID format [SWID] where they are used. 2404 * Registration of vanity names SHOULD be discouraged. The 2405 requesting specification MUST provide a description of how a 2406 requested name will allow for use by multiple stakeholders. 2408 6.2.4. Software Tag Version Scheme Values Registry 2410 This document establishes a new registry titled "Software Tag Version 2411 Scheme Values". This registry provides index values for use as 2412 version-scheme item values in this document and version scheme names 2413 for use in [SWID]. 2415 [TO BE REMOVED: This registration should take place at the following 2416 location: https://www.iana.org/assignments/swid] 2418 This registry uses the registration procedures defined in 2419 Section 6.2.1 with the following associated ranges: 2421 +=============+=====================================+ 2422 | Range | Registration Procedures | 2423 +=============+=====================================+ 2424 | 0-16383 | Standards Action with Expert Review | 2425 +-------------+-------------------------------------+ 2426 | 16384-65535 | Specification Required | 2427 +-------------+-------------------------------------+ 2429 Table 10: CoSWID Version Scheme Registration 2430 Procedures 2432 Assignments MUST consist of an integer Index value, the Version 2433 Scheme Name, and a reference to the defining specification. 2435 Initial registrations for the "Software Tag Version Scheme Values" 2436 registry are provided below, which are derived from the textual 2437 version scheme names defined in [SWID]. 2439 +=============+=========================+=================+ 2440 | Index | Version Scheme Name | Specification | 2441 +=============+=========================+=================+ 2442 | 0 | Reserved | | 2443 +-------------+-------------------------+-----------------+ 2444 | 1 | multipartnumeric | See Section 4.1 | 2445 +-------------+-------------------------+-----------------+ 2446 | 2 | multipartnumeric+suffix | See Section 4.1 | 2447 +-------------+-------------------------+-----------------+ 2448 | 3 | alphanumeric | See Section 4.1 | 2449 +-------------+-------------------------+-----------------+ 2450 | 4 | decimal | See Section 4.1 | 2451 +-------------+-------------------------+-----------------+ 2452 | 5-16383 | Unassigned | | 2453 +-------------+-------------------------+-----------------+ 2454 | 16384 | semver | See Section 4.1 | 2455 +-------------+-------------------------+-----------------+ 2456 | 16385-65535 | Unassigned | | 2457 +-------------+-------------------------+-----------------+ 2459 Table 11: CoSWID Version Scheme Initial Registrations 2461 Registrations MUST conform to the expert review criteria defined in 2462 Section 6.2.3. 2464 Designated experts MUST also ensure that newly requested entries 2465 define a value space for the corresponding version item that is 2466 unique from other previously registered entries. Note: The initial 2467 registrations violate this requirement, but are included for 2468 backwards compatibility with [SWID]. See also Section 4.1. 2470 6.2.5. Software Tag Entity Role Values Registry 2472 This document establishes a new registry titled "Software Tag Entity 2473 Role Values". This registry provides index values for use as entity- 2474 entry role item values in this document and entity role names for use 2475 in [SWID]. 2477 [TO BE REMOVED: This registration should take place at the following 2478 location: https://www.iana.org/assignments/swid] 2480 This registry uses the registration procedures defined in 2481 Section 6.2.1 with the following associated ranges: 2483 +=========+=====================================+ 2484 | Range | Registration Procedures | 2485 +=========+=====================================+ 2486 | 0-127 | Standards Action with Expert Review | 2487 +---------+-------------------------------------+ 2488 | 128-255 | Specification Required | 2489 +---------+-------------------------------------+ 2491 Table 12: CoSWID Entity Role Registration 2492 Procedures 2494 Assignments consist of an integer Index value, a Role Name, and a 2495 reference to the defining specification. 2497 Initial registrations for the "Software Tag Entity Role Values" 2498 registry are provided below, which are derived from the textual 2499 entity role names defined in [SWID]. 2501 +=======+=================+=================+ 2502 | Index | Role Name | Specification | 2503 +=======+=================+=================+ 2504 | 0 | Reserved | | 2505 +-------+-----------------+-----------------+ 2506 | 1 | tagCreator | See Section 4.2 | 2507 +-------+-----------------+-----------------+ 2508 | 2 | softwareCreator | See Section 4.2 | 2509 +-------+-----------------+-----------------+ 2510 | 3 | aggregator | See Section 4.2 | 2511 +-------+-----------------+-----------------+ 2512 | 4 | distributor | See Section 4.2 | 2513 +-------+-----------------+-----------------+ 2514 | 5 | licensor | See Section 4.2 | 2515 +-------+-----------------+-----------------+ 2516 | 6 | maintainer | See Section 4.2 | 2517 +-------+-----------------+-----------------+ 2518 | 7-255 | Unassigned | | 2519 +-------+-----------------+-----------------+ 2521 Table 13: CoSWID Entity Role Initial 2522 Registrations 2524 Registrations MUST conform to the expert review criteria defined in 2525 Section 6.2.3. 2527 6.2.6. Software Tag Link Ownership Values Registry 2529 This document establishes a new registry titled "Software Tag Link 2530 Ownership Values". This registry provides index values for use as 2531 link-entry ownership item values in this document and link ownership 2532 names for use in [SWID]. 2534 [TO BE REMOVED: This registration should take place at the following 2535 location: https://www.iana.org/assignments/swid] 2537 This registry uses the registration procedures defined in 2538 Section 6.2.1 with the following associated ranges: 2540 +=========+=====================================+ 2541 | Range | Registration Procedures | 2542 +=========+=====================================+ 2543 | 0-127 | Standards Action with Expert Review | 2544 +---------+-------------------------------------+ 2545 | 128-255 | Specification Required | 2546 +---------+-------------------------------------+ 2548 Table 14: CoSWID Link Ownership Registration 2549 Procedures 2551 Assignments consist of an integer Index value, an Ownership Type 2552 Name, and a reference to the defining specification. 2554 Initial registrations for the "Software Tag Link Ownership Values" 2555 registry are provided below, which are derived from the textual 2556 entity role names defined in [SWID]. 2558 +=======+=====================+=================+ 2559 | Index | Ownership Type Name | Definition | 2560 +=======+=====================+=================+ 2561 | 0 | Reserved | | 2562 +-------+---------------------+-----------------+ 2563 | 1 | abandon | See Section 4.3 | 2564 +-------+---------------------+-----------------+ 2565 | 2 | private | See Section 4.3 | 2566 +-------+---------------------+-----------------+ 2567 | 3 | shared | See Section 4.3 | 2568 +-------+---------------------+-----------------+ 2569 | 4-255 | Unassigned | | 2570 +-------+---------------------+-----------------+ 2572 Table 15: CoSWID Link Ownership Inital 2573 Registrations 2575 Registrations MUST conform to the expert review criteria defined in 2576 Section 6.2.3. 2578 6.2.7. Software Tag Link Relationship Values Registry 2580 This document establishes a new registry titled "Software Tag Link 2581 Relationship Values". This registry provides index values for use as 2582 link-entry rel item values in this document and link ownership names 2583 for use in [SWID]. 2585 [TO BE REMOVED: This registration should take place at the following 2586 location: https://www.iana.org/assignments/swid] 2587 This registry uses the registration procedures defined in 2588 Section 6.2.1 with the following associated ranges: 2590 +=============+=====================================+ 2591 | Range | Registration Procedures | 2592 +=============+=====================================+ 2593 | 0-32767 | Standards Action with Expert Review | 2594 +-------------+-------------------------------------+ 2595 | 32768-65535 | Specification Required | 2596 +-------------+-------------------------------------+ 2598 Table 16: CoSWID Link Relationship Registration 2599 Procedures 2601 Assignments consist of an integer Index value, the Relationship Type 2602 Name, and a reference to the defining specification. 2604 Initial registrations for the "Software Tag Link Relationship Values" 2605 registry are provided below, which are derived from the link 2606 relationship values defined in [SWID]. 2608 +==========+========================+=================+ 2609 | Index | Relationship Type Name | Specification | 2610 +==========+========================+=================+ 2611 | 0 | Reserved | | 2612 +----------+------------------------+-----------------+ 2613 | 1 | ancestor | See Section 4.4 | 2614 +----------+------------------------+-----------------+ 2615 | 2 | component | See Section 4.4 | 2616 +----------+------------------------+-----------------+ 2617 | 3 | feature | See Section 4.4 | 2618 +----------+------------------------+-----------------+ 2619 | 4 | installationmedia | See Section 4.4 | 2620 +----------+------------------------+-----------------+ 2621 | 5 | packageinstaller | See Section 4.4 | 2622 +----------+------------------------+-----------------+ 2623 | 6 | parent | See Section 4.4 | 2624 +----------+------------------------+-----------------+ 2625 | 7 | patches | See Section 4.4 | 2626 +----------+------------------------+-----------------+ 2627 | 8 | requires | See Section 4.4 | 2628 +----------+------------------------+-----------------+ 2629 | 9 | see-also | See Section 4.4 | 2630 +----------+------------------------+-----------------+ 2631 | 10 | supersedes | See Section 4.4 | 2632 +----------+------------------------+-----------------+ 2633 | 11 | supplemental | See Section 4.4 | 2634 +----------+------------------------+-----------------+ 2635 | 12-65535 | Unassigned | | 2636 +----------+------------------------+-----------------+ 2638 Table 17: CoSWID Link Relationship Initial 2639 Registrations 2641 Registrations MUST conform to the expert review criteria defined in 2642 Section 6.2.3. 2644 Designated experts MUST also ensure that a newly requested entry 2645 documents the URI schemes allowed to be used in an href associated 2646 with the link relationship and the expected resolution behavior of 2647 these URI schemes. This will help to ensure that applications 2648 processing software tags are able to interoperate when resolving 2649 resources referenced by a link of a given type. 2651 6.2.8. Software Tag Link Use Values Registry 2653 This document establishes a new registry titled "Software Tag Link 2654 Use Values". This registry provides index values for use as link- 2655 entry use item values in this document and link use names for use in 2656 [SWID]. 2658 [TO BE REMOVED: This registration should take place at the following 2659 location: https://www.iana.org/assignments/swid] 2661 This registry uses the registration procedures defined in 2662 Section 6.2.1 with the following associated ranges: 2664 +=========+=====================================+ 2665 | Range | Registration Procedures | 2666 +=========+=====================================+ 2667 | 0-127 | Standards Action with Expert Review | 2668 +---------+-------------------------------------+ 2669 | 128-255 | Specification Required | 2670 +---------+-------------------------------------+ 2672 Table 18: CoSWID Link Use Registration Procedures 2674 Assignments consist of an integer Index value, the Link Use Type 2675 Name, and a reference to the defining specification. 2677 Initial registrations for the "Software Tag Link Use Values" registry 2678 are provided below, which are derived from the link relationship 2679 values defined in [SWID]. 2681 +=======+====================+=================+ 2682 | Index | Link Use Type Name | Specification | 2683 +=======+====================+=================+ 2684 | 0 | Reserved | | 2685 +-------+--------------------+-----------------+ 2686 | 1 | optional | See Section 4.5 | 2687 +-------+--------------------+-----------------+ 2688 | 2 | required | See Section 4.5 | 2689 +-------+--------------------+-----------------+ 2690 | 3 | recommended | See Section 4.5 | 2691 +-------+--------------------+-----------------+ 2692 | 4-255 | Unassigned | | 2693 +-------+--------------------+-----------------+ 2695 Table 19: CoSWID Link Use Initial Registrations 2697 Registrations MUST conform to the expert review criteria defined in 2698 Section 6.2.3. 2700 6.3. swid+cbor Media Type Registration 2702 IANA is requested to add the following to the IANA "Media Types" 2703 registry [IANA.media-types]. 2705 Type name: application 2707 Subtype name: swid+cbor 2709 Required parameters: none 2711 Optional parameters: none 2713 Encoding considerations: Binary (encoded as CBOR [RFC8949]). See 2714 RFC-AAAA for details. 2716 Security considerations: See Section 9 of RFC-AAAA. 2718 Interoperability considerations: Applications MAY ignore any key 2719 value pairs that they do not understand. This allows backwards 2720 compatible extensions to this specification. 2722 Published specification: RFC-AAAA 2724 Applications that use this media type: The type is used by software 2725 asset management systems, vulnerability assessment systems, and in 2726 applications that use remote integrity verification. 2728 Fragment Identifier Considerations: The syntax and semantics of 2729 fragment identifiers specified for "application/swid+cbor" are as 2730 specified for "application/cbor". (At publication of RFC-AAAA, there 2731 is no fragment identification syntax defined for "application/cbor".) 2733 Additional information: 2735 Magic number(s): if tagged, first five bytes in hex: da 53 57 49 44 2736 (see Section 8 in RFC-AAAA) 2738 File extension(s): coswid 2740 Macintosh file type code(s): none 2742 Macintosh Universal Type Identifier code: org.ietf.coswid conforms to 2743 public.data 2745 Person & email address to contact for further information: IESG 2746 2747 Intended usage: COMMON 2749 Restrictions on usage: None 2751 Author: Henk Birkholz 2753 Change controller: IESG 2755 6.4. CoAP Content-Format Registration 2757 IANA is requested to assign a CoAP Content-Format ID for the CoSWID 2758 media type in the "CoAP Content-Formats" sub-registry, from the "IETF 2759 Review or IESG Approval" space (256..999), within the "CoRE 2760 Parameters" registry [RFC7252] [IANA.core-parameters]: 2762 +=======================+==========+======+===========+ 2763 | Media type | Encoding | ID | Reference | 2764 +=======================+==========+======+===========+ 2765 | application/swid+cbor | - | TBD1 | RFC-AAAA | 2766 +-----------------------+----------+------+-----------+ 2768 Table 20: CoAP Content-Format IDs 2770 6.5. CBOR Tag Registration 2772 IANA is requested to allocate a tag in the "CBOR Tags" registry 2773 [IANA.cbor-tags], preferably with the specific value requested: 2775 +============+===========+=============================+ 2776 | Tag | Data Item | Semantics | 2777 +============+===========+=============================+ 2778 | 1398229316 | map | Concise Software Identifier | 2779 | | | (CoSWID) [RFC-AAAA] | 2780 +------------+-----------+-----------------------------+ 2782 Table 21: CoSWID CBOR Tag 2784 6.6. URI Scheme Registrations 2786 The ISO 19770-2:2015 SWID specification describes use of the "swid" 2787 and "swidpath" URI schemes, which are currently in use in 2788 implementations. This document continues this use for CoSWID. The 2789 following subsections provide registrations for these schemes in to 2790 ensure that a permanent registration exists for these schemes that is 2791 suitable for use in the SWID and CoSWID specifications. 2793 URI schemes are registered within the "Uniform Resource Identifier 2794 (URI) Schemes" registry maintained at [IANA.uri-schemes]. 2796 6.6.1. URI-scheme swid 2798 IANA is requested to register the URI scheme "swid". This 2799 registration request complies with [RFC7595]. 2801 Scheme name: 2802 swid 2804 Status: 2805 Permanent 2807 Applications/protocols that use this scheme name: 2808 Applications that require Software-IDs (SWIDs) or Concise 2809 Software-IDs (CoSWIDs); see Section 5.1 of RFC-AAAA. 2811 Contact: 2812 IETF Chair 2814 Change controller: 2815 IESG 2817 Reference: 2818 Section 5.1 in RFC-AAAA 2820 6.6.2. URI-scheme swidpath 2822 IANA is requested to register the URI scheme "swidpath". This 2823 registration request complies with [RFC7595]. 2825 Scheme name: 2826 swidpath 2828 Status: 2829 Permanent 2831 Applications/protocols that use this scheme name: 2832 Applications that require Software-IDs (SWIDs) or Concise 2833 Software-IDs (CoSWIDs); see Section 5.2 of RFC-AAAA. 2835 Contact: 2836 IETF Chair 2838 Change controller: 2839 IESG 2841 Reference: 2842 Section 5.2 in RFC-AAAA 2844 6.7. CoSWID Model for use in SWIMA Registration 2846 The Software Inventory Message and Attributes (SWIMA) for PA-TNC 2847 specification [RFC8412] defines a standardized method for collecting 2848 an endpoint device's software inventory. A CoSWID can provide 2849 evidence of software installation which can then be used and 2850 exchanged with SWIMA. This registration adds a new entry to the IANA 2851 "Software Data Model Types" registry defined by [RFC8412] 2852 [IANA.pa-tnc-parameters] to support CoSWID use in SWIMA as follows: 2854 Pen: 0 2856 Integer: TBD2 2858 Name: Concise Software Identifier (CoSWID) 2860 Reference: RFC-AAAA 2862 Deriving Software Identifiers: 2864 A Software Identifier generated from a CoSWID tag is expressed as a 2865 concatenation of the form in [RFC5234] as follows: 2867 TAG_CREATOR_REGID "_" "_" UNIQUE_ID 2869 Where TAG_CREATOR_REGID is the reg-id item value of the tag's entity 2870 item having the role value of 1 (corresponding to "tag creator"), and 2871 the UNIQUE_ID is the same tag's tag-id item. If the tag-id item's 2872 value is expressed as a 16-byte binary string, the UNIQUE_ID MUST be 2873 represented using the UUID string representation defined in [RFC4122] 2874 including the "urn:uuid:" prefix. 2876 The TAG_CREATOR_REGID and the UNIQUE_ID are connected with a double 2877 underscore (_), without any other connecting character or whitespace. 2879 7. Signed CoSWID Tags 2881 SWID tags, as defined in the ISO-19770-2:2015 XML schema, can include 2882 cryptographic signatures to protect the integrity of the SWID tag. 2883 In general, tags are signed by the tag creator (typically, although 2884 not exclusively, the vendor of the software component that the SWID 2885 tag identifies). Cryptographic signatures can make any modification 2886 of the tag detectable, which is especially important if the integrity 2887 of the tag is important, such as when the tag is providing reference 2888 integrity measurements for files. The ISO-19770-2:2015 XML schema 2889 uses XML DSIG to support cryptographic signatures. 2891 Signing CoSWID tags follows the procedures defined in CBOR Object 2892 Signing and Encryption [I-D.ietf-cose-rfc8152bis-struct]. A CoSWID 2893 tag MUST be wrapped in a COSE Signature structure, either COSE_Sign1 2894 or COSE_Sign. In the first case, a Single Signer Data Object 2895 (COSE_Sign1) contains a single signature and MUST be signed by the 2896 tag creator. The following CDDL specification defines a restrictive 2897 subset of COSE header parameters that MUST be used in the protected 2898 header in this case. 2900 2901 COSE-Sign1-coswid = [ 2902 protected: bstr .cbor protected-signed-coswid-header, 2903 unprotected: unprotected-signed-coswid-header, 2904 payload: bstr .cbor payload, 2905 signature: bstr, 2906 ] 2908 cose-label = int / tstr 2909 cose-values = any 2911 protected-signed-coswid-header = { 2912 1 => int, ; algorithm identifier 2913 3 => "application/swid+cbor", 2914 * cose-label => cose-values, 2915 } 2917 unprotected-signed-coswid-header = { 2918 * cose-label => cose-values, 2919 } 2920 2922 The COSE_Sign structure allows for more than one signature, one of 2923 which MUST be issued by the tag creator, to be applied to a CoSWID 2924 tag and MAY be used. The corresponding usage scenarios are domain- 2925 specific and require well-specified application guidance. 2927 2928 COSE-Sign-coswid = [ 2929 protected: bstr .cbor protected-signed-coswid-header1, 2930 unprotected: unprotected-signed-coswid-header, 2931 payload: bstr .cbor payload, 2932 signature: [ * COSE_Signature ], 2933 ] 2935 protected-signed-coswid-header1 = { 2936 3 => "application/swid+cbor", 2937 * cose-label => cose-values, 2938 } 2940 protected-signature-coswid-header = { 2941 1 => int, ; algorithm identifier 2942 * cose-label => cose-values, 2943 } 2945 unprotected-sign-coswid-header = { 2946 * cose-label => cose-values, 2947 } 2949 COSE_Signature = [ 2950 protected: bstr .cbor protected-signature-coswid-header, 2951 unprotected: unprotected-sign-coswid-header, 2952 signature : bstr 2953 ] 2954 2956 Additionally, the COSE Header counter signature MAY be used as an 2957 attribute in the unprotected header map of the COSE envelope of a 2958 CoSWID [I-D.ietf-cose-countersign]. The application of counter 2959 signing enables second parties to provide a signature on a signature 2960 allowing for a proof that a signature existed at a given time (i.e., 2961 a timestamp). 2963 A CoSWID MUST be signed, using the above mechanism, to protect the 2964 integrity of the CoSWID tag. See the security considerations (in 2965 Section 9) for more information on why a signed CoSWID is valuable in 2966 most cases. 2968 8. CBOR-Tagged CoSWID Tags 2970 This specification allows for tagged and untagged CBOR data items 2971 that are CoSWID tags. Consecutively, the CBOR tag for CoSWID tags 2972 defined in Table 21 SHOULD be used in conjunction with CBOR data 2973 items that are a CoSWID tags. Other CBOR tags MUST NOT be used with 2974 a CBOR data item that is a CoSWID tag. If tagged, both signed and 2975 unsigned CoSWID tags MUST use the CoSWID CBOR tag. In case a signed 2976 CoSWID is tagged, a CoSWID CBOR tag MUST be appended before the COSE 2977 envelope whether it is a COSE_Untagged_Message or a 2978 COSE_Tagged_Message. In case an unsigned CoSWID is tagged, a CoSWID 2979 CBOR tag MUST be appended before the CBOR data item that is the 2980 CoSWID tag. 2982 2983 coswid = unsigned-coswid / signed-coswid 2984 unsigned-coswid = concise-swid-tag / tagged-coswid 2985 signed-coswid1 = signed-coswid-for 2986 signed-coswid = signed-coswid1 / tagged-coswid 2988 tagged-coswid = #6.1398229316(T) 2990 signed-coswid-for = #6.18(COSE-Sign1-coswid) 2991 / #6.98(COSE-Sign-coswid) 2992 2994 This specification allows for a tagged CoSWID tag to reside in a COSE 2995 envelope that is also tagged with a CoSWID CBOR tag. In cases where 2996 a tag creator is not a signer (e.g., hand-offs between entities in a 2997 trusted portion of a supply-chain), retaining CBOR tags attached to 2998 unsigned CoSWID tags can be of great use. Nevertheless, redundant 2999 use of tags SHOULD be avoided when possible. 3001 9. Security Considerations 3003 The following security considerations for use of CoSWID tags focus 3004 on: 3006 * ensuring the integrity and authenticity of a CoSWID tag 3008 * the application of CoSWID tags to address security challenges 3009 related to unmanaged or unpatched software 3011 * reducing the potential for unintended disclosure of a device's 3012 software load 3014 A tag is considered "authoritative" if the CoSWID tag was created by 3015 the software provider. An authoritative CoSWID tag contains 3016 information about a software component provided by the supplier of 3017 the software component, who is expected to be an expert in their own 3018 software. Thus, authoritative CoSWID tags can represent 3019 authoritative information about the software component. The degree 3020 to which this information can be trusted depends on the tag's chain 3021 of custody and the ability to verify a signature provided by the 3022 supplier if present in the CoSWID tag. The provisioning and 3023 validation of CoSWID tags are handled by local policy and is outside 3024 the scope of this document. 3026 A signed CoSWID tag (see Section 7) whose signature has been 3027 validated can be relied upon to be unchanged since it was signed. By 3028 contrast, the data contained in unsigned tags can be altered by any 3029 user or process with write-access to the tag. To support signature 3030 validation, there is the need to associate the right key with the 3031 software provider or party originating the signature in a secure way. 3032 This operation is application specific and needs to be addressed by 3033 the application or a user of the application; a specific approach for 3034 which is out-of-scope for this document. 3036 When an authoritative tag is signed, the originator of the signature 3037 can be verified. A trustworthy association between the signature and 3038 the originator of the signature can be established via trust anchors. 3039 A certification path between a trust anchor and a certificate 3040 including a public key enabling the validation of a tag signature can 3041 realize the assessment of trustworthiness of an authoritative tag. 3042 Verifying that the software provider is the signer is a different 3043 matter. This requires an association between the signature and the 3044 tag's entity item associated corresponding to the software provider. 3045 No mechanism is defined in this draft to make this association; 3046 therefore, this association will need to be handled by local policy. 3047 As always, the validity of a signature does not imply veracity of the 3048 signed statements: anyone can sign assertions such that the software 3049 is from a specific software-creator or that a specific persistent-id 3050 applies; policy needs to be applied to evaluate these statements and 3051 to determine their suitability for a specific use. 3053 Loss of control of signing credentials used to sign CoSWID tags would 3054 create doubt about the authenticity and integrity of any CoSWID tags 3055 signed using the compromised keys. In such cases, the legitimate tag 3056 signer (namely, the software provider for an authoritative CoSWID 3057 tag) can employ uncompromised signing credentials to create a new 3058 signature on the original tag. The tag version number would not be 3059 incremented since the tag itself was not modified. Consumers of 3060 CoSWID tags would need to validate the tag using the new credentials 3061 and would also need to make use of revocation information available 3062 for the compromised credentials to avoid validating tags signed with 3063 them. The process for doing this is beyond the scope of this 3064 specification. 3066 The CoSWID format allows the use of hash values without an 3067 accompanying hash algorithm identifier. This exposes the tags to 3068 some risk of cross-algorithm attacks. We believe that this can 3069 become a practical problem only if some implementations allow the use 3070 of insecure hash algorithms. Since it may not become known 3071 immediately when an algorithm becomes insecure, this leads to a 3072 strong recommendation to only include support for hash algorithms 3073 that are generally considered secure, and not just marginally so. 3075 CoSWID tags are intended to contain public information about software 3076 components and, as such, the contents of a CoSWID tag (as opposed to 3077 the set of tags that apply to the endpoint, see below) does not need 3078 to be protected against unintended disclosure on an endpoint. 3079 Converse, generators of CoSWID tags need to ensure that only public 3080 information is disclosed. Entitlement Keys are an example for 3081 information where particular care is required; tag authors are 3082 advised not to record unprotected, private software license keys in 3083 this field. 3085 CoSWID tags are intended to be easily discoverable by authorized 3086 applications and users on an endpoint in order to make it easy to 3087 determine the tagged software load. Access to the collection of an 3088 endpoint's CoSWID tags needs to be appropriately controlled to 3089 authorized applications and users using an appropriate access control 3090 mechanism. 3092 Since the tag-id of a CoSWID tag can be used as a global index value, 3093 failure to ensure the tag-id's uniqueness can cause collisions or 3094 ambiguity in CoSWID tags that are retrieved or processed using this 3095 identifier. CoSWID is designed to not require a registry of 3096 identifiers. As a result, CoSWID requires the tag creator to employ 3097 a method of generating a unique tag identifier. Specific methods of 3098 generating a unique identifier are beyond the scope of this 3099 specification. A collision in tag-ids may result in false positives/ 3100 negatives in software integrity checks or mis-identification of 3101 installed software, undermining CoSWID use cases such as 3102 vulnerability identification, software inventory, etc. If such a 3103 collision is detected, then the tag consumer may want to contact the 3104 maintainer of the CoSWID to have them issue a correction addressing 3105 the collision; however, this also discloses to the maintainer that 3106 the consumer has the other tag with the given tag-id in their 3107 database. More generally speaking, a tag consumer needs to be robust 3108 against such collisions lest the collision become a viable attack 3109 vector. 3111 CoSWID tags are designed to be easily added and removed from an 3112 endpoint along with the installation or removal of software 3113 components. On endpoints where addition or removal of software 3114 components is tightly controlled, the addition or removal of CoSWID 3115 tags can be similarly controlled. On more open systems, where many 3116 users can manage the software inventory, CoSWID tags can be easier to 3117 add or remove. On such systems, it can be possible to add or remove 3118 CoSWID tags in a way that does not reflect the actual presence or 3119 absence of corresponding software components. Similarly, not all 3120 software products automatically install CoSWID tags, so products can 3121 be present on an endpoint without providing a corresponding CoSWID 3122 tag. As such, any collection of CoSWID tags cannot automatically be 3123 assumed to represent either a complete or fully accurate 3124 representation of the software inventory of the endpoint. However, 3125 especially on endpoint devices that more strictly control the ability 3126 to add or remove applications, CoSWID tags are an easy way to provide 3127 a preliminary understanding of that endpoint's software inventory. 3129 As CoSWID tags do not expire, inhibiting new CoSWID tags from 3130 reaching an intended consumer would render that consumer stuck with 3131 outdated information, potentially leaving associated vulnerabilities 3132 or weaknesses unmitigated. Therefore, a CoSWID tag consumer should 3133 actively check for updated tag-versions via more than one means. 3135 This specification makes use of relative paths (e.g., filesystem 3136 paths) in several places. A signed COSWID tag cannot make use of 3137 these to derive information that is considered to be covered under 3138 the signature. Typically, relative file system paths will be used to 3139 identify targets for an installation, not sources of tag information. 3141 Any report of an endpoint's CoSWID tag collection provides 3142 information about the software inventory of that endpoint. If such a 3143 report is exposed to an attacker, this can tell them which software 3144 products and versions thereof are present on the endpoint. By 3145 examining this list, the attacker might learn of the presence of 3146 applications that are vulnerable to certain types of attacks. As 3147 noted earlier, CoSWID tags are designed to be easily discoverable by 3148 authorized applications and users on an endpoint, but this does not 3149 present a significant risk since an attacker would already need to 3150 have access to the endpoint to view that information. However, when 3151 the endpoint transmits its software inventory to another party, or 3152 that inventory is stored on a server for later analysis, this can 3153 potentially expose this information to attackers who do not yet have 3154 access to the endpoint. For this reason, it is important to protect 3155 the confidentiality of CoSWID tag information that has been collected 3156 from an endpoint in transit and at rest, not because those tags 3157 individually contain sensitive information, but because the 3158 collection of CoSWID tags and their association with an endpoint 3159 reveals information about that endpoint's attack surface. 3161 Finally, both the ISO-19770-2:2015 XML schema SWID definition and the 3162 CoSWID CDDL specification allow for the construction of "infinite" 3163 tags with link item loops or tags that contain malicious content with 3164 the intent of creating non-deterministic states during validation or 3165 processing of those tags. While software providers are unlikely to 3166 do this, CoSWID tags can be created by any party and the CoSWID tags 3167 collected from an endpoint could contain a mixture of vendor and non- 3168 vendor created tags. For this reason, a CoSWID tag might contain 3169 potentially malicious content. Input sanitization, loop detection, 3170 and signature verification are ways that implementations can address 3171 this concern. 3173 More generally speaking, the security considerations of [RFC8949], 3174 [I-D.ietf-cose-rfc8152bis-struct], and [I-D.ietf-cose-countersign] 3175 apply. 3177 10. Privacy Consideration 3179 As noted in Section 9, collected information about an endpoint's 3180 software load, such as what might be represented by an endpoint's 3181 CoSWID tag collection, could be used to identify vulnerable software 3182 for attack. Collections of endpoint software information also can 3183 have privacy implications for users. The set of application a user 3184 installs can give clues to personal matters such as political 3185 affiliation, banking and investments, gender, sexual orientation, 3186 medical concerns, etc. While the collection of CoSWID tags on an 3187 endpoint wouldn't increase the privacy risk (since a party able to 3188 view those tags could also view the applications themselves), if 3189 those CoSWID tags are gathered and stored in a repository somewhere, 3190 visibility into the repository now also gives visibility into a 3191 user's application collection. For this reason, repositories of 3192 collected CoSWID tags not only need to be protected against 3193 collection by malicious parties, but even authorized parties will 3194 need to be vetted and made aware of privacy responsibilities 3195 associated with having access to this information. Likewise, users 3196 should be made aware that their software inventories are being 3197 collected from endpoints. Furthermore, when collected and stored by 3198 authorized parties or systems, the inventory data needs to be 3199 protected as both security and privacy sensitive information. 3201 11. Change Log 3203 This section is to be removed before publishing as an RFC. 3205 [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] 3207 Changes from version 12 to version 14: 3209 * Moved key identifier to protected COSE header 3211 * Fixed index reference for hash 3213 * Removed indirection of CDDL type definition for filesystem-item 3215 * Fixed quantity of resource and process 3217 * Updated resource-collection 3219 * Renamed socket name in software-meta to be consistent in naming 3221 * Aligned excerpt examples in I-D text with full CDDL 3223 * Fixed titles where title was referring to group instead of map 3225 * Added missing date in SEMVER 3227 * Fixed root cardinality for file and directory, etc. 3229 * Transformed path-elements-entry from map to group for re-usability 3231 * Scrubbed IANA Section 3233 * Removed redundant supplemental rule 3235 * Aligned discrepancy with ISO spec. 3237 * Addressed comments on typos. 3239 * Fixed kramdown nits and BCP reference. 3241 * Addressed comments from WGLC reviewers. 3243 Changes in version 12: 3245 * Addressed a bunch of minor editorial issues based on WGLC 3246 feedback. 3248 * Added text about the use of UTF-8 in CoSWID. 3250 * Adjusted tag-id to allow for a UUID to be provided as a bstr. 3252 * Cleaned up descriptions of index ranges throughout the document, 3253 removing discussion of 8 bit, 16 bit, etc. 3255 * Adjusted discussion of private use ranges to use negative integer 3256 values and to be more clear throughout the document. 3258 * Added discussion around resolving overlapping value spaces for 3259 version schemes. 3261 * Added a set of expert review criteria for new IANA registries 3262 created by this document. 3264 * Added new registrations for the "swid" and "swidpath" URI schemes, 3265 and for using CoSWID with SWIMA. 3267 Changes from version 03 to version 11: 3269 * Reduced representation complexity of the media-entry type and 3270 removed the Section describing the older data structure. 3272 * Added more signature schemes from COSE 3274 * Included a minimal required set of normative language 3276 * Reordering of attribute name to integer label by priority 3277 according to semantics. 3279 * Added an IANA registry for CoSWID items supporting future 3280 extension. 3282 * Cleaned up IANA registrations, fixing some inconsistencies in the 3283 table labels. 3285 * Added additional CDDL sockets for resource collection entries 3286 providing for additional extension points to address future SWID/ 3287 CoSWID extensions. 3289 * Updated Section on extension points to address new CDDL sockets 3290 and to reference the new IANA registry for items. 3292 * Removed unused references and added new references to address 3293 placeholder comments. 3295 * Added table with semantics for the link ownership item. 3297 * Clarified language, made term use more consistent, fixed 3298 references, and replacing lowercase RFC2119 keywords. 3300 Changes from version 02 to version 03: 3302 * Updated core CDDL including the CDDL design pattern according to 3303 RFC 8428. 3305 Changes from version 01 to version 02: 3307 * Enforced a more strict separation between the core CoSWID 3308 definition and additional usage by moving content to corresponding 3309 appendices. 3311 * Removed artifacts inherited from the reference schema provided by 3312 ISO (e.g., NMTOKEN(S)) 3314 * Simplified the core data definition by removing group and type 3315 choices where possible 3317 * Minor reordering of map members 3319 * Added a first extension point to address requested flexibility for 3320 extensions beyond the any-element 3322 Changes from version 00 to version 01: 3324 * Ambiguity between evidence and payload eliminated by introducing 3325 explicit members (while still 3327 * allowing for "empty" SWID tags) 3329 * Added a relatively restrictive COSE envelope using cose_sign1 to 3330 define signed CoSWID (single signer only, at the moment) 3332 * Added a definition how to encode hashes that can be stored in the 3333 any-member using existing IANA tables to reference hash-algorithms 3335 Changes since adopted as a WG I-D -00: 3337 * Removed redundant any-attributes originating from the ISO- 3338 19770-2:2015 XML schema definition 3340 * Fixed broken multi-map members 3342 * Introduced a more restrictive item (any-element-map) to represent 3343 custom maps, increased restriction on types for the any-attribute, 3344 accordingly 3346 * Fixed X.1520 reference 3348 * Minor type changes of some attributes (e.g., NMTOKENS) 3350 * Added semantic differentiation of various name types (e,g. fs- 3351 name) 3353 Changes from version 06 to version 07: 3355 * Added type choices/enumerations based on textual definitions in 3356 19770-2:2015 3358 * Added value registry request 3360 * Added media type registration request 3362 * Added content format registration request 3364 * Added CBOR tag registration request 3366 * Removed RIM appendix to be addressed in complementary draft 3368 * Removed CWT appendix 3370 * Flagged firmware resource collection appendix for revision 3372 * Made use of terminology more consistent 3374 * Better defined use of extension points in the CDDL 3376 * Added definitions for indexed values 3378 * Added IANA registry for Link use indexed values 3379 Changes from version 05 to version 06: 3381 * Improved quantities 3383 * Included proposals for implicit enumerations that were NMTOKENS 3385 * Added extension points 3387 * Improved exemplary firmware-resource extension 3389 Changes from version 04 to version 05: 3391 * Clarified language around SWID and CoSWID to make more consistent 3392 use of these terms. 3394 * Added language describing CBOR optimizations for single vs. arrays 3395 in the model front matter. 3397 * Fixed a number of grammatical, spelling, and wording issues. 3399 * Documented extension points that use CDDL sockets. 3401 * Converted IANA registration tables to markdown tables, reserving 3402 the 0 value for use when a value is not known. 3404 * Updated a number of references to their current versions. 3406 Changes from version 03 to version 04: 3408 * Re-index label values in the CDDL. 3410 * Added a Section describing the CoSWID model in detail. 3412 * Created IANA registries for entity-role and version-scheme 3414 Changes from version 02 to version 03: 3416 * Updated CDDL to allow for a choice between a payload or evidence 3418 * Re-index label values in the CDDL. 3420 * Added item definitions 3422 * Updated references for COSE, CBOR Web Token, and CDDL. 3424 Changes from version 01 to version 02: 3426 * Added extensions for Firmware and CoSWID use as Reference 3427 Integrity Measurements (CoSWID RIM) 3429 * Changes meta handling in CDDL from use of an explicit use of items 3430 to a more flexible unconstrained collection of items. 3432 * Added Sections discussing use of COSE Signatures and CBOR Web 3433 Tokens 3435 Changes from version 00 to version 01: 3437 * Added CWT usage for absolute SWID paths on a device 3439 * Fixed cardinality of type-choices including arrays 3441 * Included first iteration of firmware resource-collection 3443 12. References 3445 12.1. Normative References 3447 [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, 3448 "Deprecating the "X-" Prefix and Similar Constructs in 3449 Application Protocols", BCP 178, RFC 6648, 3450 DOI 10.17487/RFC6648, June 2012, 3451 . 3453 [BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3454 Writing an IANA Considerations Section in RFCs", BCP 26, 3455 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3456 . 3458 [I-D.ietf-cose-countersign] 3459 Schaad, J. and R. Housley, "CBOR Object Signing and 3460 Encryption (COSE): Countersignatures", Work in Progress, 3461 Internet-Draft, draft-ietf-cose-countersign-05, 23 June 3462 2021, . 3465 [I-D.ietf-cose-rfc8152bis-struct] 3466 Schaad, J., "CBOR Object Signing and Encryption (COSE): 3467 Structures and Process", Work in Progress, Internet-Draft, 3468 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 3469 . 3472 [IANA.cbor-tags] 3473 IANA, "Concise Binary Object Representation (CBOR) Tags", 3474 . 3476 [IANA.core-parameters] 3477 IANA, "Constrained RESTful Environments (CoRE) 3478 Parameters", 3479 . 3481 [IANA.media-types] 3482 IANA, "Media Types", 3483 . 3485 [IANA.named-information] 3486 IANA, "Named Information", 3487 . 3489 [IANA.pa-tnc-parameters] 3490 IANA, "Posture Attribute (PA) Protocol Compatible with 3491 Trusted Network Connect (TNC) Parameters", 3492 . 3494 [IANA.uri-schemes] 3495 IANA, "Uniform Resource Identifier (URI) Schemes", 3496 . 3498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3499 Requirement Levels", BCP 14, RFC 2119, 3500 DOI 10.17487/RFC2119, March 1997, 3501 . 3503 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3504 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 3505 2003, . 3507 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3508 Resource Identifier (URI): Generic Syntax", STD 66, 3509 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3510 . 3512 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 3513 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 3514 . 3516 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3517 Specifications: ABNF", STD 68, RFC 5234, 3518 DOI 10.17487/RFC5234, January 2008, 3519 . 3521 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 3522 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 3523 September 2009, . 3525 [RFC5890] Klensin, J., "Internationalized Domain Names for 3526 Applications (IDNA): Definitions and Document Framework", 3527 RFC 5890, DOI 10.17487/RFC5890, August 2010, 3528 . 3530 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3531 Application Protocol (CoAP)", RFC 7252, 3532 DOI 10.17487/RFC7252, June 2014, 3533 . 3535 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3536 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3537 May 2017, . 3539 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 3540 DOI 10.17487/RFC8288, October 2017, 3541 . 3543 [RFC8412] Schmidt, C., Haynes, D., Coffin, C., Waltermire, D., and 3544 J. Fitzgerald-McKay, "Software Inventory Message and 3545 Attributes (SWIMA) for PA-TNC", RFC 8412, 3546 DOI 10.17487/RFC8412, July 2018, 3547 . 3549 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 3550 Definition Language (CDDL): A Notational Convention to 3551 Express Concise Binary Object Representation (CBOR) and 3552 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 3553 June 2019, . 3555 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 3556 Representation (CBOR)", STD 94, RFC 8949, 3557 DOI 10.17487/RFC8949, December 2020, 3558 . 3560 [SAM] "Information technology - Software asset management - Part 3561 5: Overview and vocabulary", ISO/IEC 19770-5:2015, 15 3562 November 2013. 3564 [SEMVER] Preston-Werner, T., "Semantic Versioning 2.0.0", 3565 . 3567 [SWID] "Information technology - Software asset management - Part 3568 2: Software identification tag", ISO/IEC 19770-2:2015, 1 3569 October 2015. 3571 [UNSPSC] "United Nations Standard Products and Services Code", 26 3572 October 2020, . 3574 [W3C.REC-css3-mediaqueries-20120619] 3575 Rivoal, F., "Media Queries", World Wide Web Consortium 3576 Recommendation REC-css3-mediaqueries-20120619, 19 June 3577 2012, . 3580 [W3C.REC-xmlschema-2-20041028] 3581 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 3582 Second Edition", World Wide Web Consortium Recommendation 3583 REC-xmlschema-2-20041028, 28 October 2004, 3584 . 3586 [W3C.REC-xpath20-20101214] 3587 Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., 3588 Kay, M., Robie, J., and J. Simeon, "XML Path Language 3589 (XPath) 2.0 (Second Edition)", World Wide Web Consortium 3590 Recommendation REC-xpath20-20101214, 14 December 2010, 3591 . 3593 12.2. Informative References 3595 [CamelCase] 3596 "UpperCamelCase", 29 August 2014, 3597 . 3599 [I-D.ietf-rats-architecture] 3600 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 3601 W. Pan, "Remote Attestation Procedures Architecture", Work 3602 in Progress, Internet-Draft, draft-ietf-rats-architecture- 3603 15, 8 February 2022, . 3606 [KebabCase] 3607 "KebabCase", 18 December 2014, 3608 . 3610 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 3611 Information Models and Data Models", RFC 3444, 3612 DOI 10.17487/RFC3444, January 2003, 3613 . 3615 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 3616 Unique IDentifier (UUID) URN Namespace", RFC 4122, 3617 DOI 10.17487/RFC4122, July 2005, 3618 . 3620 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 3621 and Registration Procedures for URI Schemes", BCP 35, 3622 RFC 7595, DOI 10.17487/RFC7595, June 2015, 3623 . 3625 [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- 3626 Oriented Lightweight Information Exchange (ROLIE)", 3627 RFC 8322, DOI 10.17487/RFC8322, February 2018, 3628 . 3630 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 3631 Description Specification", RFC 8520, 3632 DOI 10.17487/RFC8520, March 2019, 3633 . 3635 [SWID-GUIDANCE] 3636 Waltermire, D., Cheikes, B.A., Feldman, L., and G. Witte, 3637 "Guidelines for the Creation of Interoperable Software 3638 Identification (SWID) Tags", NISTIR 8060, April 2016, 3639 . 3641 [X.1520] "Recommendation ITU-T X.1520 (2014), Common 3642 vulnerabilities and exposures", 20 April 2011. 3644 Acknowledgments 3646 This document draws heavily on the concepts defined in the ISO/IEC 3647 19770-2:2015 specification. The authors of this document are 3648 grateful for the prior work of the 19770-2 contributors. 3650 We are also grateful for the careful reviews provided by the IESG 3651 reviewers. Special thanks go to Benjamin Kaduk. 3653 Contributors 3655 Carsten Bormann 3656 Universität Bremen TZI 3657 Postfach 330440 3658 D-28359 Bremen 3659 Germany 3660 Phone: +49-421-218-63921 3661 Email: cabo@tzi.org 3662 Carsten Bormann contributed to the CDDL specifications and the IANA 3663 considerations. 3665 Authors' Addresses 3667 Henk Birkholz 3668 Fraunhofer SIT 3669 Rheinstrasse 75 3670 64295 Darmstadt 3671 Germany 3672 Email: henk.birkholz@sit.fraunhofer.de 3674 Jessica Fitzgerald-McKay 3675 National Security Agency 3676 9800 Savage Road 3677 Ft. Meade, Maryland 3678 United States of America 3679 Email: jmfitz2@cyber.nsa.gov 3681 Charles Schmidt 3682 The MITRE Corporation 3683 202 Burlington Road 3684 Bedford, Massachusetts 01730 3685 United States of America 3686 Email: cmschmidt@mitre.org 3688 David Waltermire 3689 National Institute of Standards and Technology 3690 100 Bureau Drive 3691 Gaithersburg, Maryland 20877 3692 United States of America 3693 Email: david.waltermire@nist.gov