idnits 2.17.1 draft-ietf-sacm-coswid-06.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 77 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 03, 2018) is 2118 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) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) -- 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. 'SWID-GUIDANCE' == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-02 == Outdated reference: A later version (-08) exists of draft-ietf-sacm-rolie-softwaredescriptor-02 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-15 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 5 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: January 4, 2019 Department of Defense 6 C. Schmidt 7 The MITRE Corporation 8 D. Waltermire 9 NIST 10 July 03, 2018 12 Concise Software Identifiers 13 draft-ietf-sacm-coswid-06 15 Abstract 17 This document defines a concise representation of ISO/IEC 18 19770-2:2015 Software Identification (SWID) tags that are 19 interoperable with the XML schema definition of ISO/IEC 19770-2:2015 20 and augmented for application in Constrained-Node Networks. Next to 21 the inherent capability of SWID tags to express arbitrary context 22 information, Concise SWID (CoSWID) tags support the definition of 23 additional semantics via well-defined data definitions incorporated 24 by extension points. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 4, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. The SWID Tag Lifecycle . . . . . . . . . . . . . . . . . 4 62 1.2. Concise SWID Extensions . . . . . . . . . . . . . . . . . 6 63 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 7 64 2. Concise SWID Data Definition . . . . . . . . . . . . . . . . 7 65 2.1. The concise-software-identity Object . . . . . . . . . . 8 66 2.1.1. Determining the tag type . . . . . . . . . . . . . . 11 67 2.1.2. concise-software-identity Co-constraints . . . . . . 12 68 2.2. The global-attributes Group . . . . . . . . . . . . . . . 12 69 2.3. The any-element-map Entry . . . . . . . . . . . . . . . . 13 70 2.4. The entity Object . . . . . . . . . . . . . . . . . . . . 13 71 2.5. The link Object . . . . . . . . . . . . . . . . . . . . . 14 72 2.6. The software-meta Object . . . . . . . . . . . . . . . . 16 73 2.7. The Resource Collection Definition . . . . . . . . . . . 19 74 2.7.1. The hash-entry Array . . . . . . . . . . . . . . . . 19 75 2.7.2. The resource-collection Group . . . . . . . . . . . . 20 76 2.7.3. The payload Object . . . . . . . . . . . . . . . . . 22 77 2.7.4. The evidence Object . . . . . . . . . . . . . . . . . 23 78 2.8. Full CDDL Definition . . . . . . . . . . . . . . . . . . 24 79 3. CoSWID Indexed Label Values . . . . . . . . . . . . . . . . . 29 80 3.1. Version Scheme . . . . . . . . . . . . . . . . . . . . . 29 81 3.2. Entity Role Values . . . . . . . . . . . . . . . . . . . 29 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 83 4.1. SWID/CoSWID Version Schema Values Registry . . . . . . . 30 84 4.2. SWID/CoSWID Entity Role Values Registry . . . . . . . . . 31 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 86 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 87 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 34 88 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 91 9.2. Informative References . . . . . . . . . . . . . . . . . 37 92 Appendix A. CoSWID Attributes for Firmware (label 60) . . . . . 38 93 Appendix B. Signed Concise SWID Tags using COSE . . . . . . . . 44 94 Appendix C. CoSWID used as Reference Integrity Measurements 95 (CoSWID RIM) . . . . . . . . . . . . . . . . . . . . 45 97 Appendix D. CBOR Web Token for Concise SWID Tags . . . . . . . . 45 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 100 1. Introduction 102 SWID tags have several use-applications including but not limited to: 104 o Software Inventory Management, a part of the Software Asset 105 Management [SAM] process, which requires an accurate list of 106 discernible deployed software components. 108 o Vulnerability Assessment, which requires a semantic link between 109 standardized vulnerability descriptions and software components 110 installed on IT-assets [X.1520]. 112 o Remote Attestation, which requires a link between reference 113 integrity measurements (RIM) and security logs of measured 114 software components [I-D.birkholz-tuda]. 116 SWID tags, as defined in ISO-19770-2:2015 [SWID], provide a 117 standardized XML-based record format that identifies and describes a 118 specific release of a software component. Different software 119 components, and even different releases of a particular software 120 component, each have a different SWID tag record associated with 121 them. SWID tags are meant to be flexible and able to express a broad 122 set of metadata about a software component. 124 While there are very few required fields in SWID tags, there are many 125 optional fields that support different use scenarios. While a SWID 126 tag consisting of only required fields might be a few hundred bytes 127 in size, a tag containing many of the optional fields can be many 128 orders of magnitude larger. Thus, real-world instances of SWID tags 129 can be fairly large, and the communication of SWID tags in use- 130 applications such as those described earlier can cause a large amount 131 of data to be transported. This can be larger than acceptable for 132 constrained devices and networks. Concise SWID (CoSWID) tags 133 significantly reduce the amount of data transported as compared to a 134 typical SWID tag. This reduction is enabled through the use of CBOR, 135 which maps human-readable labels of that content to more concise 136 integer labels (indices). The use of CBOR to express SWID 137 information in CoSWID tags allows both CoSWID and SWID tags to be 138 part of an enterprise security solution for a wider range of 139 endpoints and environments. 141 1.1. The SWID Tag Lifecycle 143 In addition to defining the format of a SWID tag record, ISO/IEC 144 19770-2:2015 defines requirements concerning the SWID tag lifecycle. 145 Specifically, when a software component is installed on an endpoint, 146 that product's SWID tag is also installed. Likewise, when the 147 product is uninstalled or replaced, the SWID tag is deleted or 148 replaced, as appropriate. As a result, ISO/IEC 19770-2:2015 149 describes a system wherein there is a correspondence between the set 150 of installed software components on an endpoint, and the presence of 151 the correspondingsponding SWID tags for these components on that 152 endpoint. CoSWIDs share the same lifecycle requirements as a SWID 153 tag. 155 The following is an excerpt (with some modifications and reordering) 156 from NIST Interagency Report (NISTIR) 8060: Guidelines for the 157 Creation of Interoperable SWID Tags [SWID-GUIDANCE], which describes 158 the tag types used within the lifecycle defined in ISO-19770-2:2015. 160 The SWID specification defines four types of SWID tags: primary, 161 patch, corpus, and supplemental. 163 1. Primary Tag - A SWID or CoSWID tag that identifies and describes 164 a software component is installed on a computing device. 166 2. Patch Tag - A SWID or CoSWID tag that identifies and describes an 167 installed patch which has made incremental changes to a software 168 component installed on a computing device. 170 3. Corpus Tag - A SWID or CoSWID tag that identifies and describes 171 an installable software component in its pre-installation state. 172 A corpus tag can be used to represent metadata about an 173 installation package or installer for a software component, a 174 software update, or a patch. 176 4. Supplemental Tag - A SWID or CoSWID tag that allows additional 177 information to be associated with a referenced SWID tag. This 178 helps to ensure that SWID Primary and Patch Tags provided by a 179 software provider are not modified by software management tools, 180 while allowing these tools to provide their own software 181 metadata. 183 Corpus, primary, and patch tags have similar functions in that 184 they describe the existence and/or presence of different types of 185 software (e.g., software installers, software installations, 186 software patches), and, potentially, different states of software 187 components. In contrast, supplemental tags furnish additional 188 information not contained in corpus, primary, or patch tags. All 189 four tag types come into play at various points in the software 190 lifecycle, and support software management processes that depend 191 on the ability to accurately determine where each software 192 component is in its lifecycle. 194 +------------+ 195 v | 196 Installation Product Product Product Product 197 Media -> Installed -> Patched -> Upgraded -> Removed 198 Deployed 200 Corpus Primary Primary xPrimary xPrimary 201 Supplemental Supplemental xSupplemental xSuplemental 202 Patch xPatch 203 Primary 204 Supplemental 206 Figure 1: Use of Tag Types in the Software Lifecycle 208 Figure 1 illustrates the steps in the software lifecycle and the 209 relationships among those lifecycle events supported by the four 210 types of SWID and CoSWID tags, as follows: 212 * Software Deployment. Before the software component is 213 installed (i.e., pre-installation), and while the product is 214 being deployed, a corpus tag provides information about the 215 installation files and distribution media (e.g., CD/DVD, 216 distribution package). 218 * Software Installation. A primary tag will be installed with 219 the software component (or subsequently created) to uniquely 220 identify and describe the software component. Supplemental 221 tags are created to augment primary tags with additional site- 222 specific or extended information. While not illustrated in the 223 figure, patch tags may also be installed during software 224 installation to provide information about software fixes 225 deployed along with the base software installation. 227 * Software Patching. When a new patch is applied to the software 228 component, a new patch tag is provided, supplying details about 229 the patch and its dependencies. While not illustrated in the 230 figure, a corpus tag can also provide information about the 231 patch installer, and patching dependencies that need to be 232 installed before the patch. 234 * Software Upgrading. As a software component is upgraded to a 235 new version, new primary and supplemental tags replace existing 236 tags, enabling timely and accurate tracking of updates to 237 software inventory. While not illustrated in the figure, a 238 corpus tag can also provide information about the upgrade 239 installer, and dependencies that need to be installed before 240 the upgrade. 242 * Software Removal. Upon removal of the software component, 243 relevant SWID tags are removed. This removal event can trigger 244 timely updates to software inventory reflecting the removal of 245 the product and any associated patch or supplemental tags. 247 Note: While not fully illustrated in the figure, supplemental tags 248 can be associated with any corpus, primary, or patch tag to provide 249 additional metadata about an installer, installed software, or 250 installed patch respectively. 252 Each of the different SWID and CoSWID tag types provide different 253 sets of information. For example, a "corpus tag" is used to describe 254 a software component's installation image on an installation media, 255 while a "patch tag" is meant to describe a patch that modifies some 256 other software component. 258 1.2. Concise SWID Extensions 260 This document defines the CoSWID format, a more concise 261 representation of SWID information in the Concise Binary Object 262 Representation (CBOR) [RFC7049]. This is described via the Concise 263 Data Definition Language (CDDL) [I-D.ietf-cbor-cddl]. The resulting 264 CoSWID data definition is interoperable with the XML schema 265 definition of ISO-19770-2:2015 [SWID]. The vocabulary, i.e., the 266 CDDL names of the types and members used in the CoSWID data 267 definition, are mapped to more concise labels represented as small 268 integer values. The names used in the CDDL data definition and the 269 mapping to the CBOR representation using integer labels is based on 270 the vocabulary of the XML attribute and element names defined in ISO/ 271 IEC 19770-2:2015. 273 The corresponding CoSWID data definition includes two kinds of 274 augmentation. 276 o The explicit definition of types for attributes that are typically 277 stored in the "any attribute" of an ISO-19770-2:2015 in XML 278 representation. These are covered in Section 2.2 and Section 2.3 279 of this document. 281 o The inclusion of extension points in the CoSWID data definition 282 that allow for additional uses of CoSWID tags that go beyond the 283 original scope of ISO-19770-2:2015 tags. These are covered in 284 Section 2.7.3 and Section 2.7.4. 286 1.3. Requirements Notation 288 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 289 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 290 "OPTIONAL" in this document are to be interpreted as described in RFC 291 2119, BCP 14 [RFC2119]. 293 2. Concise SWID Data Definition 295 The following is a CDDL representation for a CoSWID tag. This CDDL 296 represetation is intended to be parallel to the XML schema definition 297 in the ISO/IEC 19770-2:2015 [SWID] specification, allowing both SWID 298 and CoSWID tags to represent a common set of SWID information and to 299 support all SWID tag use cases. To achieve this end, the CDDL 300 representation includes every SWID tag field and attribute. The 301 CamelCase notation used in the XML schema definition is changed to a 302 hyphen-separated notation (e.g. ResourceCollection is named 303 resource-collection in the CoSWID data definition). This deviation 304 from the original notation used in the XML representation reduces 305 ambiguity when referencing certain attributes in corresponding 306 textual descriptions. An attribute referred by its name in CamelCase 307 notation explicitly relates to XML SWID tags, an attribute referred 308 by its name in hyphen-separated notation explicitly relates to CoSWID 309 tags. This approach simplifies the composition of further work that 310 reference both XML SWID and CoSWID documents. 312 Human-readable names of members in the CDDL data definition are 313 mapped to integer indices via a block of rules at the bottom of the 314 definition. The 67 character strings of the SWID vocabulary that 315 would have to be stored or transported in full if using the original 316 vocabulary are replaced. 318 In CBOR, an array is encoded using bytes that identify the array, and 319 the array's length or stop point (see [RFC7049]). To make items that 320 support 1 or more values, the following CDDL notion is used. 322 _name_ = (_label_: _data_ / [ 2* _data_ ]) 324 The CDDL above allows for a more effecient CBOR encoding of the data 325 when a single value is used by avoiding the need to first encode the 326 array. An array is used for two or more values. This modeling 327 pattern is used frequently in the CoSWID CDDL data definition in such 328 cases. 330 The following subsections describe the different parts of the CoSWID 331 model. 333 2.1. The concise-software-identity Object 335 The CDDL for the main concise-software-identity object is as follows: 337 concise-software-identity = { 338 global-attributes, 339 tag-id, 340 tag-version, 341 ? corpus, 342 ? patch, 343 ? supplemental, 344 swid-name, 345 ? software-version, 346 ? version-scheme, 347 ? media, 348 ? software-meta-entry, 349 ? entity-entry, 350 ? link-entry, 351 ? ( payload-entry / evidence-entry ), 352 ? any-element-entry, 353 } 354 tag-id = (0: text) 355 swid-name = (1: text) 356 entity-entry = (2: entity / [ 2* entity ]) 357 evidence-entry = (3: evidence) 358 link-entry = (4: link / [ 2* link ]) 359 software-meta-entry = (5: software-meta / [ 2* software-meta ]) 360 payload-entry = (6: payload) 361 any-element-entry = (7: any-element-map / [ 2* any-element-map ]) 362 corpus = (8: bool) 363 patch = (9: bool) 364 media = (10: text) 365 supplemental = (11: bool) 366 tag-version = (12: integer) 367 software-version = (13: text) 368 version-scheme = (14: text) 370 The following describes each child item of the concise-software- 371 identity object model. 373 o global-attributes: A list of items including an optional language 374 definition to support the processing of text-string values and an 375 unbounded set of any-attribute items. Described in Section 2.2. 377 o tag-id (label 0): An textual identifier uniquely referencing a 378 (composite) software component. The tag identifier MUST be 379 globally unique. There are no strict guidelines on how this 380 identifier is structured, but examples include a 16 byte GUID 381 (e.g. class 4 UUID) [RFC4122]. 383 o tag-version (label 12): An integer value that indicates if a 384 specific release of a software component has more than one tag 385 that can represent that specific release. Typically, the initial 386 value of this field is set to 0, and the value is monotonically 387 increased for subsequent tags produced for the same software 388 component release. This item is used when a CoSWID tag producer 389 creates and releases an incorrect tag that they subsequently want 390 to fix, but no underlying changes have been made to the product 391 the CoSWID tag represents. This could happen if, for example, a 392 patch is distributed that has a link reference that does not cover 393 all the various software releases it can patch. A newer CoSWID 394 tag for that patch can be generated and the tag-version value 395 incremented to indicate that the data is updated. 397 o corpus (label 8): A boolean value that indicates if the tag 398 identifies and describes an installable software component in its 399 pre-installation state. Installable software includes a 400 installation package or installer for a software component, a 401 software update, or a patch. If the CoSWID tag represents 402 installable software, the corpus item MUST be set to "true". If 403 not provided the default value MUST be considered "false". 405 o patch (label 9): A boolean value that indicates if the tag 406 identifies and describes an installed patch which has made 407 incremental changes to a software component installed on a 408 computing device. Typically, an installed patch has made a set of 409 file modifications to pre-installed software, and does not alter 410 the version number or the descriptive metadata of an installed 411 software component. If a CoSWID tag is for a patch, it MUST 412 contain the patch item and its value MUST be set to "true". If 413 not provided the default value MUST be considered "false". 415 o supplemental (label 11): A boolean value that indicates if the tag 416 is providing additional information to be associated with another 417 referenced SWID or CoSWID tag. Tags using this item help to 418 ensure that primary and patch tags provided by a software provider 419 are not modified by software management tools, while allowing 420 these tools to provide their own software metadata for a software 421 component. If a CoSWID tag is a supplemntal tag, it MUST contain 422 the supplemental item and its value MUST be set to "true". If not 423 provided the default value MUST be considered "false". 425 o swid-name (label 1): This textual item provides the software 426 component name as it would typically be referenced. For example, 427 what would be seen in the add/remove software dialog in an 428 operating system, or what is specified as the name of a packaged 429 software component or a patch identifier name. 431 o software-version (label 13): A textual value representing the 432 specific underlying release or development version of the software 433 component. 435 o version-scheme (label 14): An 8-bit integer or textual value 436 representing the versioning scheme used for the software-version 437 item. If an integer value is used it MUST be a value from the 438 registry (see section Section 4.1 or a value in the private use 439 range: 32768-65,535. 441 o media (label 10): This text value is a hint to the tag consumer to 442 understand what this tag applies to. This item represents a query 443 as defined by the W3C Media Queries Recommendation (see 444 http://www.w3.org/TR/css3-mediaqueries/). A hint to the consumer 445 of the link to what the target item is applicable for. 447 o software-meta-entry (label 5): An open-ended collection of key/ 448 value data related to this CoSWID. A number of predefined 449 attributes can be used within this item providing for common usage 450 and semantics across the industry. The data definition of this 451 entry allows for any additional attribute to be included, though 452 it is recommended that industry norms for new attributes are 453 defined and followed to the degree possible. Described in 454 Section 2.6. 456 o entity-entry (label 2): Specifies the organizations related to the 457 software component referenced by this CoSWID tag. Described in 458 Section 2.4. 460 o link-entry (label 4): Provides a means to establish a relationship 461 arc between the tag and another item. A link can be used to 462 establish relationships between tags and to reference other 463 resources that are related to the CoSWID tag, e.g. vulnerability 464 database associations, ROLIE feeds, MUD files, software download 465 location, etc). This is modeled after the HTML "link" element. 466 Described in Section 2.5. 468 o payload-entry (label 6): The items that may be installed on a 469 system entity when the software component is installed. Note that 470 payload may be a superset of the items installed and - depending 471 on optimization mechanisms in respect to that system entity - may 472 or may not include every item that could be created or executed on 473 the corresponding system entitiy when software components are 474 installed. In general, payload will be used to indicate the files 475 that may be installed with a software component. Therefore 476 payload will often be a superset of those files (i.e. if a 477 particular optional sub-component is not installed, the files 478 associated with that software component may be included in 479 payload, but not installed in the system entity). Described in 480 Section 2.7.3. 482 o evidence-entry (label 3): This item is used to provide results 483 from a scan of a system where software that does not have a CoSWID 484 tag is discovered. This information is not provided by the 485 software-creator, and is instead created when a system is being 486 scanned and the evidence for why software is believed to be 487 installed on the device is provided in the evidence item. 488 Described in Section 2.7.4. 490 o any-element-entry (label 7): A default map that can contain 491 arbitrary map members and even nested maps (which would also be 492 any-elements). In essence, the any-element allows items not 493 defined in this CDDL data definition to be included in a Concise 494 Software Identifier. Described in Section 2.3. 496 2.1.1. Determining the tag type 498 The operational model for SWID and CoSWID tags introduced in 499 Section 1.1. The following rules can be used to determine the type 500 of a CoSWID tag. 502 o Corpus Tag: A CoSWID tag MUST be considered a corpus tag if the 503 corpus item is "true". 505 o Primary Tag: A CoSWID tag MUST be considered a primary tag if the 506 corpus, patch, and supplemental items are "false". 508 o Patch Tag: A CoSWID tag MUST be considered a patch tag if the 509 patch item is "true" and the corpus item is "false". 511 o Supplemental Tag: A CoSWID tag MUST be considered a supplemental 512 tag if the supplemental item is set to "true". 514 A tag that does not match one of the above rules MUST be considered 515 an invalid, unsupported tag type. 517 If a patch modifies the version number or the descriptive metadata of 518 the software, then a new tag representing these details SHOULD be 519 installed, and the old tag SHOULD be removed. 521 2.1.2. concise-software-identity Co-constraints 523 o Only one of the corpus, patch, and supplemental items MUST be set 524 to "true", or all of the corpus, patch, and supplemental items 525 MUST be set to "false" or be omitted. 527 o If the patch item is set to "true", the the tag SHOULD contain at 528 least one link with the rel(ation) item value of "patches" and an 529 href item specifying an association with the software that was 530 patched. 532 o If the supplemental item is set to "true", the the tag SHOULD 533 contain at least one link with the rel(ation) item value of 534 "supplements" and an href item specifying an association with the 535 software that is supplemented. 537 o If all of the corpus, patch, and supplemental items are "false", 538 or if the corpus item is set to "true", then a software-version 539 item MUST be included with a value set to the version of the 540 software component. This ensures that primary and corpus tags 541 have an identifiable software version. 543 2.2. The global-attributes Group 545 The global-attributes group provides a list of items including an 546 optional language definition to support the processing of text-string 547 values and an unbounded set of any-attribute items allowing for 548 additional items to be provided as a general point of extension in 549 the model. 551 The CDDL for the global-attributes is as follows: 553 global-attributes = ( 554 ? lang, 555 * any-attribute, 556 ) 558 label = text / int 560 any-attribute = ( 561 label => text / int / [ 2* text ] / [ 2* int ] 562 ) 564 lang = (15: text) 566 The following describes each child item of this object. 568 o lang (index 15): A language tag or corresponding IANA index 569 integer that conforms with IANA Language Subtag Registry 570 [RFC5646]. 572 o any-attribute: This sub-group provides a means to include 573 arbitrary information via label (key) item value pairs where both 574 keys and values can be either a single integer or text string, or 575 an array of integers or text strings. 577 2.3. The any-element-map Entry 579 The CDDL for the any-element-entry object is as follows: 581 any-element-map = { 582 global-attributes, 583 * label => any-element-map / [ 2* any-element-map ], 584 } 585 any-element-entry = (7: any-element-map / [ 2* any-element-map ]) 587 The following describes each child item of this object. 589 o global-attributes: The global-attributes group described in 590 Section 2.2. 592 o label: a single or multiple 594 2.4. The entity Object 596 The CDDL for the entity object is as follows: 598 entity = { 599 global-attributes, 600 entity-name, 601 ? reg-id, 602 role, 603 ? thumbprint, 604 extended-data, 605 } 607 any-uri = text 609 extended-data = (30: any-element-map / [ 2* any-element-map ]) 610 entity-name = (31: text) 611 reg-id = (32: any-uri) 612 role = (33: text / [2* text]) 613 thumbprint = (34: hash-entry) 615 The following describes each child item of this object. 617 o global-attributes: The global-attributes group described in 618 Section 2.2. 620 o entity-name (index 32): The text-string name of the organization 621 claiming a particular role in the CoSWID tag. 623 o reg-id (index 32): The registration id is intended to uniquely 624 identify a naming authority in a given scope (e.g. global, 625 organization, vendor, customer, administrative domain, etc.) that 626 is implied by the referenced naming authority. The value of an 627 registration ID MUST be a RFC 3986 URI. The scope SHOULD be the 628 scope of an organization. In a given scope, the registration id 629 MUST be used consistently. 631 o role (index 33): The relationship(s) between this organization and 632 this tag. The role of tag creator is required for every CoSWID 633 tag. The role of an entity may include any role value, but the 634 pre-defined roles include: "aggregator", "distributor", 635 "licensor", "software-creator", and "tag-creator". These pre- 636 defined role index and text values are defined in Section 3.2. 637 Use of index values instead of text for these pre-defined roles 638 allows a CoSWID to be more concise. 640 o thumbprint (index 34): The value of the thmbprint item provides an 641 integer-based hash algorithm identifier (hash-alg-id) and a byte 642 string string value (hash-value) that contains the corresponding 643 hash value (i.e. the thumbprint) of the signing entities 644 certificate(s). If the hash-alg-id is not known, then the integer 645 value "0" MUST be used. This ensures parity between the SWID tag 646 specification [SWID], which does not allow an algorithm to be 647 identified for this field. See Section 2.7.1 for more details on 648 the use of the hash-entry data structure. 650 o extended-data (index 30): An open-ended collection of elements 651 that can be used to attach arbitrary metadata to an entity item. 653 2.5. The link Object 655 The CDDL for the link object is as follows: 657 link = { 658 global-attributes, 659 ? artifact, 660 href, 661 ? media 662 ? ownership, 663 rel, 664 ? media-type, 665 ? use, 666 } 667 artifact = (37: text) 668 href = (38: any-uri) 669 media = (10: any-uri) 670 ownership = (39: "shared" / "private" / "abandon") 671 rel = (40: text) 672 media-type = (41: text) 673 use = (42: "optional" / "required" / "recommended") 675 The following describes each child item of this object. 677 o global-attributes: The global-attributes group described in 678 Section 2.2. 680 o artifact (index: 37): For installation media (rel="installation- 681 media"), this item value indicates the path of the installer 682 executable or script that can be run to launch the referenced 683 installation. Items with the same artifact name should be 684 considered mirrors of each other, allowing the installation media 685 to be downloaded from any of the described sources. 687 o href (index 38): The link to the item being referenced. The 688 "href" item's value can point to several different things, and can 689 be any of the following: 691 * If no URI scheme is provided, then the URI is to be interpreted 692 as being relative to the URI of the CoSWID tag. For example, 693 "./folder/supplemental.coswid". 695 * a physical resource location with any system-acceptable URI 696 scheme (e.g., file:// http:// https:// ftp://) 698 * a URI with "coswid:" as the scheme, which refers to another 699 CoSWID by tag-id. This URI would need to be resolved in the 700 context of the system by software that can lookup other CoSWID 701 tags. For example, "coswid:2df9de35-0aff- 702 4a86-ace6-f7dddd1ade4c" references the tag with the tag-id 703 value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c". 705 * a URI with "swidpath:" as the scheme, which refers to another 706 CoSIWD via an XPATH query. This URI would need to be resolved 707 in the context of the system entity via dedicated software 708 components that can lookup other CoSWID tags and select the 709 appropriate tag based on an XPATH query. Examples include: 711 * swidpath://SoftwareIdentity[Entity/@regid='http://contoso.com'] 712 would retrieve all CoSWID tags that include an entity where the 713 regid is "Contoso" or swidpath://SoftwareIdentity[Meta/@persist 714 entId='b0c55172-38e9-4e36-be86-92206ad8eddb'] would match 715 CoSWID tags with the persistent-id value 716 "b0c55172-38e9-4e36-be86-92206ad8eddb". 718 * See XPATH query standard : http://www.w3.org/TR/xpath20/ 720 o media (index 10): See media defined in Section 2.1. 722 o ownership (index 39): Determines the relative strength of 723 ownership of the software components. Valid enumerations are: 724 abandon, private, shared 726 o rel (index 40): The relationship between this CoSWID and the 727 target file. Relationships can be identified by referencing the 728 IANA registration library: https://www.iana.org/assignments/link- 729 relations/link-relations.xhtml. 731 o media-type (index 41): The IANA MediaType for the target file; 732 this provides the consumer with intelligence of what to expect. 733 See http://www.iana.org/assignments/media-types/media-types.xhtml 734 for more details on link type. 736 o use (index 42): Determines if the target software is a hard 737 requirement or not. Valid enumerations are: required, 738 recommended, optional. 740 2.6. The software-meta Object 742 The CDDL for the software-meta object is as follows: 744 software-meta = { 745 global-attributes, 746 ? activation-status, 747 ? channel-type, 748 ? colloquial-version, 749 ? description, 750 ? edition, 751 ? entitlement-data-required, 752 ? entitlement-key, 753 ? generator, 754 ? persistent-id, 755 ? product, 756 ? product-family, 757 ? revision, 758 ? summary, 759 ? unspsc-code, 760 ? unspsc-version, 761 } 762 activation-status = (43: text) 763 channel-type = (44: text) 764 colloquial-version = (45: text) 765 description = (46: text) 766 edition = (47: text) 767 entitlement-data-required = (48: bool) 768 entitlement-key = (49: text) 769 generator = (50: text) 770 persistent-id = (51: text) 771 product = (52: text) 772 product-family = (53: text) 773 revision = (54: text) 774 summary = (55: text) 775 unspsc-code = (56: text) 776 unspsc-version = (57: text) 778 The following describes each child item of this object. 780 o global-attributes: The global-attributes group described in 781 Section 2.2. 783 o activation-status (index 43): Identification of the activation 784 status of this software title (e.g. Trial, Serialized, Licensed, 785 Unlicensed, etc). Typically, this is used in supplemental tags. 787 o channel-type (index 44): Provides information on which channel 788 this particular software was targeted for (e.g. Volume, Retail, 789 OEM, Academic, etc). Typically used in supplemental tags. 791 o colloquial-version (index 45): The informal or colloquial version 792 of the product (i.e. 2013). Note that this version may be the 793 same through multiple releases of a software component where the 794 version specified in entity is much more specific and will change 795 for each software release. Note that this representation of 796 version is typically used to identify a group of specific software 797 releases that are part of the same release/support infrastructure 798 (i.e. Fabrikam Office 2013). This version is used for string 799 comparisons only and is not compared to be an earlier or later 800 release (that is done via the entity version). 802 o description (index 46): A longer, detailed description of the 803 software. This description can be multiple sentences 804 (differentiated from summary, which is a very short, one-sentence 805 description). 807 o edition (index 47): The variation of the product (Extended, 808 Enterprise, Professional, Standard etc). 810 o entitlement-data-required (index 48): An indicator to determine if 811 there should be accompanying proof of entitlement when a software 812 license reconciliation is completed. 814 o entitlement-key (index 49): A vendor-specific textual key that can 815 be used to reconcile the validity of an entitlement. (e.g. serial 816 number, product or license key). 818 o generator (index 50): The name of the software tool that created a 819 CoSWID tag. This item is typically used if tags are created on 820 the fly or via a catalog-based analysis for data found on a 821 computing device. 823 o persistent-id (index 51): A GUID used to represent products 824 installed where the products are related, but may be different 825 versions. 827 o product (index 52): The base name of the product (e.g. ). 829 o product-family (index 53): The overall product family this 830 software belongs to. Product family is not used to identify that 831 a product is part of a suite, but is instead used when a set of 832 products that are all related may be installed on multiple 833 different devices. For example, an enterprise backup system may 834 consist of a backup services, multiple different backup services 835 that support mail services, databases and ERP systems, as well as 836 individual software components that backup client system entities. 837 In such an usage scenario, all software components that are part 838 of the backup system would have the same product-family name so 839 they can be grouped together in respect to reporting systems. 841 o revision (index 54): The informal or colloquial representation of 842 the sub-version of the given product (ie, SP1, R2, RC1, Beta 2, 843 etc). Note that the version will provide very exact version 844 details, the revision is intended for use in environments where 845 reporting on the informal or colloquial representation of the 846 software is important (for example, if for a certain business 847 process, an organization recognizes that it must have, for example 848 "ServicePack 1" or later of a specific product installed on all 849 devices, they can use the revision data value to quickly identify 850 any devices that do not meet this requirement). Depending on how 851 a software organizations distributes revisions, this value could 852 be specified in a primary (if distributed as an upgrade) or 853 supplemental (if distributed as a patch) CoSWID tag. 855 o summary (index 55): A short (one-sentence) description of the 856 software. 858 o unspsc-code (index 56): An 8 digit code that provides UNSPSC 859 classification of the software component this SWID tag identifies. 860 For more information see, http://www.unspsc.org/. 862 o unspsc-version (index 57): The version of the UNSPSC code used to 863 define the UNSPSC code value. For more information see, 864 http://www.unspsc.org/. 866 2.7. The Resource Collection Definition 868 2.7.1. The hash-entry Array 870 CoSWID add explicit support for the representation of hash entries 871 using algorithms that are registered at the Named Information Hash 872 Algorithm Registry via the hash-entry member (label 58). 874 hash-entry = (58: [ hash-alg-id: int, hash-value: bstr ] ) 876 The number used as a value for hash-alg-id MUST refer an ID in the 877 Named Information Hash Algorithm Registry; other hash algorithms MUST 878 NOT be used. The hash-value MUST represent the raw hash value of the 879 hashed resource generated using the hash algorithm indicated by the 880 hash-alg-id. 882 2.7.2. The resource-collection Group 884 A list of items both used in evidence (discovered by an inventory 885 process) and payload (installed in a system entity) content of a 886 CoSWID tag document to structure and differentiate the content of 887 specific CoSWID tag types. Potential content includes directories, 888 files, processes, resources or firmwares. 890 The CDDL for the resource-collection group is as follows: 892 resource-collection = ( 893 ? directory-entry, 894 ? file-entry, 895 ? process-entry, 896 ? resource-entry 897 ) 899 directory = { 900 filesystem-item, 901 path-elements, 902 } 904 file = { 905 filesystem-item, 906 ? size, 907 ? file-version, 908 ? hash-entry, 909 } 911 process = { 912 global-attributes, 913 process-name, 914 ? pid, 915 } 917 resource = { 918 global-attributes, 919 type, 920 } 922 filesystem-item = ( 923 global-attributes, 924 ? key, 925 ? location, 926 fs-name, 927 ? root, 928 ) 929 directory-entry = (16: directory / [ 2* directory ]) 930 file-entry = (17: file / [ 2* file ]) 931 process-entry = (18: process / [ 2* process ]) 932 resource-entry = (19: resource / [ 2* resource ]) 933 size = (20: integer) 934 file-version = (21: text) 935 key = (22: bool) 936 location = (23: text) 937 fs-name = (24: text) 938 root = (25: text) 939 path-elements = (26: { * file-entry, 940 * directory-entry, 941 } 942 ) 943 process-name = (27: text) 944 pid = (28: integer) 945 type = (29: text) 947 The following describes each child item or group for these groups. 949 o filesystem-item: A list of items both used in representing the 950 nodes of a file-system hierarchy, i.e. directory items that allow 951 one or more directories to be defined in the file structure, and 952 file items that allow one or more files to be specified for a 953 given location. 955 o global-attributes: The global-attributes group described in 956 Section 2.2. 958 o directory-entry (index 16): A directory item allows one or more 959 directories to be defined in the file structure. 961 o file-entry (index 17): A file element that allows one or more 962 files to be specified for a given location. 964 o process-entry (index 18): Provides process (software component in 965 execution) information for data that will show up in a devices 966 process table. 968 o resource-entry (index 19): A set of items that can be used to 969 provide arbitrary resource information about an application 970 installed on a system entity, or evidence collected from a system 971 entity. 973 o size (index 20): The file size in bytes of the file. 975 o file-version (index 21): The version of the file. 977 o key (index 22): Files that are considered important or required 978 for the use of a software component. Typical key files would be 979 those which, if not available on a system entity, would cause the 980 software component not to execute or function properly. Key files 981 will typically be used to validate that a software component 982 referenced by the CoSWID tag document is actually installed on a 983 specific system entity. 985 o location (index 23): The directory or location where a file was 986 found or can expected to be located. This text-string is intended 987 to include the filename itself. This SHOULD be the relative path 988 from the location represented by the root item. 990 o fs-name (index 24): The file name or directory name without any 991 path characters. 993 o root (index 25): A system-specific root folder that the location 994 item is an offset from. If this is not specified the assumption 995 is the root is the same folder as the location of the CoSWID tag. 996 The text-string value represents a path expression relative to the 997 CoSWID tag document location in the (composite) file-system 998 hierarchy. 1000 o path-elements (index 26): Provides the ability to apply a 1001 directory structure to the path expressions for files defined in a 1002 payload or evidence item. 1004 o process-name (index 27): The process name as it will be found in 1005 the system entity's process table. 1007 o pid (index 28): The process ID for the process in execution that 1008 can be included in the process item as part of an evidence tag. 1010 o type (index 29): The type of resource represented via a text- 1011 string (typically, registry-key, port or root-uri). 1013 2.7.3. The payload Object 1015 The CDDL for the payload object is as follows: 1017 payload = { 1018 global-attributes, 1019 resource-collection, 1020 * $$payload-extension 1021 } 1023 The following describes each child item of this object. 1025 o global-attributes: The global-attributes group described in 1026 Section 2.2. 1028 o resource-collection: The resource-collection group described in 1029 Section 2.7.2. 1031 o $$payload-extension: This CDDL socket (see [I-D.ietf-cbor-cddl] 1032 section 3.9) can be used to extend the payload model, allowing 1033 well-formed extensions to be defined in additional CDDL 1034 descriptions. 1036 2.7.4. The evidence Object 1038 The CDDL for the evidence object is as follows: 1040 evidence = { 1041 global-attributes, 1042 resource-collection, 1043 ? date, 1044 ? device-id, 1045 * $$evidence-extension 1046 } 1047 date = (35: time) 1048 device-id = (36: text) 1050 The following describes each child item of this object. 1052 o global-attributes: The global-attributes group described in 1053 Section 2.2. 1055 o resource-collection: The resource-collection group described in 1056 Section 2.7.2. 1058 o date (index 35): The date and time evidence represented by an 1059 evidence item was gathered. 1061 o device-id (index 36): A text-string identifier for a device 1062 evidence was gathered from. 1064 o $$evidence-extension: This CDDL socket (see [I-D.ietf-cbor-cddl] 1065 section 3.9) can be used to extend the evidence model, allowing 1066 well-formed extensions to be defined in additional CDDL 1067 descriptions. 1069 2.8. Full CDDL Definition 1071 In order to create a valid CoSWID document the structure of the 1072 corresponding CBOR message MUST adhere to the following CDDL data 1073 definition. 1075 concise-software-identity = { 1076 global-attributes, 1077 tag-id, 1078 tag-version, 1079 ? corpus, 1080 ? patch, 1081 ? supplemental, 1082 swid-name, 1083 ? software-version, 1084 ? version-scheme, 1085 ? media, 1086 ? software-meta-entry, 1087 entity-entry, 1088 ? link-entry, 1089 ? ( payload-entry // evidence-entry ), 1090 ? any-element-entry, 1091 } 1093 any-uri = text 1094 label = text / int 1096 any-attribute = ( 1097 label => text / int / [ 2* text ] / [ 2* int ] 1098 ) 1100 any-element-map = { 1101 global-attributes, 1102 * label => any-element-map / [ 2* any-element-map ], 1103 } 1105 global-attributes = ( 1106 ? lang, 1107 * any-attribute, 1108 ) 1110 resource-collection = ( 1111 ? directory-entry, 1112 ? file-entry, 1113 ? process-entry, 1114 ? resource-entry 1115 ) 1116 file = { 1117 filesystem-item, 1118 ? size, 1119 ? file-version, 1120 ? hash-entry, 1121 } 1123 filesystem-item = ( 1124 global-attributes, 1125 ? key, 1126 ? location, 1127 fs-name, 1128 ? root, 1129 ) 1131 directory = { 1132 filesystem-item, 1133 path-elements, 1134 } 1136 process = { 1137 global-attributes, 1138 process-name, 1139 ? pid, 1140 } 1142 resource = { 1143 global-attributes, 1144 type, 1145 } 1147 entity = { 1148 global-attributes, 1149 entity-name, 1150 ? reg-id, 1151 role, 1152 ? thumbprint, 1153 extended-data, 1154 } 1156 evidence = { 1157 global-attributes, 1158 resource-collection, 1159 ? date, 1160 ? device-id, 1161 * $$evidence-extension 1162 } 1163 link = { 1164 global-attributes, 1165 ? artifact, 1166 href, 1167 ? media 1168 ? ownership, 1169 rel, 1170 ? media-type, 1171 ? use, 1172 } 1174 software-meta = { 1175 global-attributes, 1176 ? activation-status, 1177 ? channel-type, 1178 ? colloquial-version, 1179 ? description, 1180 ? edition, 1181 ? entitlement-data-required, 1182 ? entitlement-key, 1183 ? generator, 1184 ? persistent-id, 1185 ? product, 1186 ? product-family, 1187 ? revision, 1188 ? summary, 1189 ? unspsc-code, 1190 ? unspsc-version, 1191 } 1193 payload = { 1194 global-attributes, 1195 resource-collection, 1196 * $$payload-extension 1197 } 1199 tag-id = (0: text) 1200 swid-name = (1: text) 1201 entity-entry = (2: entity / [ 2* entity ]) 1202 evidence-entry = (3: evidence) 1203 link-entry = (4: link / [ 2* link ]) 1204 software-meta-entry = (5: software-meta / [ 2* software-meta ]) 1205 payload-entry = (6: payload) 1206 any-element-entry = (7: any-element-map / [ 2* any-element-map ]) 1207 corpus = (8: bool) 1208 patch = (9: bool) 1209 media = (10: [ + [ media-expression, 1210 ? [ media-operation, 1211 media-expression, 1212 ] 1213 ] 1214 ]) 1215 media-operation = text 1216 media-expression = media-environment / [ media-prefix, 1217 media-environment, 1218 media-attribute, 1219 media-value, 1220 ] 1221 media-prefix = text 1222 media-environment = text 1223 media-attribute = text 1224 media-value = text 1225 supplemental = (11: bool) 1226 tag-version = (12: integer) 1227 software-version = (13: text) 1228 version-scheme = (14: text / int) 1229 lang = (15: text) 1230 directory-entry = (16: directory / [ 2* directory ]) 1231 file-entry = (17: file / [ 2* file ]) 1232 process-entry = (18: process / [ 2* process ]) 1233 resource-entry = (19: resource / [ 2* resource ]) 1234 size = (20: integer) 1235 file-version = (21: text) 1236 key = (22: bool) 1237 location = (23: text) 1238 fs-name = (24: text) 1239 root = (25: text) 1240 path-elements = (26: { * file-entry, 1241 * directory-entry, 1242 } 1243 ) 1244 process-name = (27: text) 1245 pid = (28: integer) 1246 type = (29: text) 1247 extended-data = (30: any-element-map / [ 2* any-element-map ]) 1248 entity-name = (31: text) 1249 reg-id = (32: any-uri) 1250 role = (33: roles / [ 2* roles ] / text / [ 2* text ]) 1251 roles= aggregator / distributor / licensor / software-creator / tag-creator 1252 aggregator=0 1253 distributor=1 1254 licensor=2 1255 software-creator=3 1256 tag-creator=4 1257 thumbprint = (34: [ hash-alg-id: int, 1258 hash-value: bstr, 1260 ] 1261 ) 1262 date = (35: time) 1263 device-id = (36: text) 1264 artifact = (37: text) 1265 href = (38: any-uri) 1266 ownership = (39: shared / private / abandon) 1267 shared=0 1268 private=1 1269 abandon=2 1270 rel = (40: rels / [ 2* rels ]) 1271 rels = ancestor / component / feature / installationmedia / packageinstaller / parent / patches / requires / see-also / supersedes / rel-supplemental 1272 ancestor=0 1273 component=1 1274 feature=2 1275 installationmedia=3 1276 packageinstaller=4 1277 parent=5 1278 patches=6 1279 requires=7 1280 see-also=8 1281 supersedes=9 1282 rel-supplemental=10 1283 media-type = (41: text) 1284 use = (42: optional / required / recommended) 1285 optional=0 1286 required=1 1287 recommended=2 1288 activation-status = (43: text) 1289 channel-type = (44: text) 1290 colloquial-version = (45: text) 1291 description = (46: text) 1292 edition = (47: text) 1293 entitlement-data-required = (48: bool) 1294 entitlement-key = (49: text) 1295 generator = (50: text) 1296 persistent-id = (51: text) 1297 product = (52: text) 1298 product-family = (53: text) 1299 revision = (54: text) 1300 summary = (55: text) 1301 unspsc-code = (56: text) 1302 unspsc-version = (57: text) 1303 hash-entry = (58: [ hash-alg-id: int, 1304 hash-value: bstr, 1305 ] 1306 ) 1308 3. CoSWID Indexed Label Values 1310 3.1. Version Scheme 1312 The following are an initial set of values for use in the version- 1313 scheme item for the version schemes defined in the ISO/IEC 1314 19770-2:2015 [SWID] specification. Index value in parens indicates 1315 the index value to use in the version-scheme item. 1317 o multipartnumeric (index 1): Numbers separated by dots, where the 1318 numbers are interpreted as integers (e.g.,1.2.3, 1.4.5, 1319 1.2.3.4.5.6.7) 1321 o multipartnumeric+suffix (index 2): Numbers separated by dots, 1322 where the numbers are interpreted as integers with an additional 1323 string suffix(e.g., 1.2.3a) 1325 o alphanumeric (index 3): Strictly a string, sorting is done 1326 alphanumerically 1328 o decimal (index 4): A floating point number (e.g., 1.25 is less 1329 than 1.3) 1331 o semver (index 16384): Follows the [SEMVER] specification 1333 The values above are registered in the "SWID/CoSWID Version Schema 1334 Values" registry defined in section Section 4.1. Additional valid 1335 values will likely be registered over time in this registry. 1337 3.2. Entity Role Values 1339 The following table indicates the index value to use for the entity 1340 roles defined in the ISO/IEC 19770-2:2015 [SWID] specification. 1342 +-------+-----------------+ 1343 | Index | Role Name | 1344 +-------+-----------------+ 1345 | 0 | Reserved | 1346 | | | 1347 | 1 | tagCreator | 1348 | | | 1349 | 2 | softwareCreator | 1350 | | | 1351 | 3 | aggregator | 1352 | | | 1353 | 4 | distributor | 1354 | | | 1355 | 5 | licensor | 1356 +-------+-----------------+ 1358 The values above are registered in the "SWID/CoSWID Entity Role 1359 Values" registry defined in section Section 4.2. Additional valid 1360 values will likely be registered over time. Additionally, the index 1361 values 226 through 255 have been reserved for private use. 1363 4. IANA Considerations 1365 This document will include requests to IANA: 1367 o Integer indices for SWID content attributes and information 1368 elements. 1370 o Content-Type for CoAP to be used in COSE. 1372 This document has a number of IANA considerations, as described in 1373 the following subsections. 1375 4.1. SWID/CoSWID Version Schema Values Registry 1377 This document uses unsigned 16-bit index values to version-scheme 1378 item values. The initial set of version-scheme values are derived 1379 from the textual version scheme names defined in the ISO/IEC 1380 19770-2:2015 specification [SWID]. 1382 This document defines a new a new registry entitled "SWID/CoSWID 1383 Version Schema Values". Future registrations for this registry are 1384 to be made based on [RFC8126] as follows: 1386 +-------------+--------------------------+ 1387 | Range | Registration Procedures | 1388 +-------------+--------------------------+ 1389 | 0-16383 | Standards Action | 1390 | | | 1391 | 16384-32767 | Specification Required | 1392 | | | 1393 | 32768-65535 | Reserved for Private Use | 1394 +-------------+--------------------------+ 1396 Initial registrations for the SWID/CoSWID Version Schema Values 1397 registry are provided below. 1399 +-------------+--------------------------+-----------------+ 1400 | Index | Role Name | Specification | 1401 +-------------+--------------------------+-----------------+ 1402 | 0 | Reserved | | 1403 | | | | 1404 | 1 | multipartnumeric | See Section 3.1 | 1405 | | | | 1406 | 2 | multipartnumeric+suffix | See Section 3.1 | 1407 | | | | 1408 | 3 | alphanumeric | See Section 3.1 | 1409 | | | | 1410 | 4 | decimal | See Section 3.1 | 1411 | | | | 1412 | 5-16383 | Unassigned | | 1413 | | | | 1414 | 16384 | semver | [SEMVER] | 1415 | | | | 1416 | 16385-32767 | Unassigned | | 1417 | | | | 1418 | 32768-65535 | Reserved for Private Use | | 1419 +-------------+--------------------------+-----------------+ 1421 4.2. SWID/CoSWID Entity Role Values Registry 1423 This document uses unsigned 8-bit index values to represent entity- 1424 role values. The initial set of Entity roles are derived from the 1425 textual role names defined in the ISO/IEC 19770-2:2015 specification 1426 [SWID]. 1428 This document defines a new a new registry entitled "SWID/CoSWID 1429 Entity Role Values". Future registrations for this registry are to 1430 be made based on [RFC8126] as follows: 1432 +---------+--------------------------+ 1433 | Range | Registration Procedures | 1434 +---------+--------------------------+ 1435 | 0-31 | Standards Action | 1436 | | | 1437 | 32-127 | Specification Required | 1438 | | | 1439 | 128-255 | Reserved for Private Use | 1440 +---------+--------------------------+ 1442 Initial registrations for the SWID/CoSWID Entity Role Values registry 1443 are provided below. 1445 +---------+--------------------------+-----------------+ 1446 | Index | Role Name | Specification | 1447 +---------+--------------------------+-----------------+ 1448 | 0 | Reserved | | 1449 | | | | 1450 | 1 | tagCreator | See Section 3.2 | 1451 | | | | 1452 | 2 | softwareCreator | See Section 3.2 | 1453 | | | | 1454 | 3 | aggregator | See Section 3.2 | 1455 | | | | 1456 | 4 | distributor | See Section 3.2 | 1457 | | | | 1458 | 5 | licensor | See Section 3.2 | 1459 | | | | 1460 | 6-49 | Unassigned | | 1461 | | | | 1462 | 50-225 | Unassigned | | 1463 | | | | 1464 | 225-255 | Reserved for Private Use | | 1465 +---------+--------------------------+-----------------+ 1467 5. Security Considerations 1469 SWID and CoSWID tags contain public information about software 1470 components and, as such, do not need to be protected against 1471 disclosure on an endpoint. Similarly, SWID tags are intended to be 1472 easily discoverable by applications and users on an endpoint in order 1473 to make it easy to identify and collect all of an endpoint's SWID 1474 tags. As such, any security considerations regarding SWID tags focus 1475 on the application of SWID tags to address security challenges, and 1476 the possible disclosure of the results of those applications. 1478 A signed SWID tag whose signature has been validated can be relied 1479 upon to be unchanged since it was signed. If the SWID tag was 1480 created by the software provider, is signed, and the software 1481 provider can be authenticated as the originator of the signature, 1482 then the tag can be considered authoritative. In this way, an 1483 authoritative SWID tag contains information about a software product 1484 provided by the maintainer of the product, who is expected to be an 1485 expert in their own product. Thus, authoritative SWID tags can be 1486 trusted to represent authoritative information about the software 1487 product. Having an authoritative SWID tag can be useful when the 1488 information in the tag needs to be trusted, such as when the tag is 1489 being used to convey reference integrity measurements for software 1490 components. By contrast, the data contained in unsigned tags cannot 1491 be trusted to be unmodified. 1493 SWID tags are designed to be easily added and removed from an 1494 endpoint along with the installation or removal of software 1495 components. On endpoints where addition or removal of software 1496 components is tightly controlled, the addition or removal of SWID 1497 tags can be similarly controlled. On more open systems, where many 1498 users can manage the software inventory, SWID tags may be easier to 1499 add or remove. On such systems, it may be possible to add or remove 1500 SWID tags in a way that does not reflect the actual presence or 1501 absence of corresponding software components. Similarly, not all 1502 software products automatically install SWID tags, so products may be 1503 present on an endpoint without providing a corresponding SWID tag. 1504 As such, any collection of SWID tags cannot automatically be assumed 1505 to represent either a complete or fully accurate representation of 1506 the software inventory of the endpoint. However, especially on 1507 devices that more strictly control the ability to add or remove 1508 applications, SWID tags are an easy way to provide an preliminary 1509 understanding of that endpoint's software inventory. 1511 Any report of an endpoint's SWID tag collection provides information 1512 about the software inventory of that endpoint. If such a report is 1513 exposed to an attacker, this can tell them which software products 1514 and versions thereof are present on the endpoint. By examining this 1515 list, the attacker might learn of the presence of applications that 1516 are vulnerable to certain types of attacks. As noted earlier, SWID 1517 tags are designed to be easily discoverable by an endpoint, but this 1518 does not present a significant risk since an attacker would already 1519 need to have access to the endpoint to view that information. 1520 However, when the endpoint transmits its software inventory to 1521 another party, or that inventory is stored on a server for later 1522 analysis, this can potentially expose this information to attackers 1523 who do not yet have access to the endpoint. As such, it is important 1524 to protect the confidentiality of SWID tag information that has been 1525 collected from an endpoint, not because those tags individually 1526 contain sensitive information, but because the collection of SWID 1527 tags and their association with an endpoint reveals information about 1528 that endpoint's attack surface. 1530 Finally, both the ISO-19770-2:2015 XML schema definition and the 1531 Concise SWID data definition allow for the construction of "infinite" 1532 SWID tags or SWID tags that contain malicious content with the intent 1533 if creating non-deterministic states during validation or processing 1534 of SWID tags. While software product vendors are unlikely to do 1535 this, SWID tags can be created by any party and the SWID tags 1536 collected from an endpoint could contain a mixture of vendor and non- 1537 vendor created tags. For this reason, tools that consume SWID tags 1538 ought to treat the tag contents as potentially malicious and should 1539 employ input sanitizing on the tags they ingest. 1541 6. Acknowledgments 1543 7. Change Log 1545 Changes from version 05 to version 06: 1547 o Improved quantities 1549 o Included proposals for implicet enumerations that were NMTOKENS 1551 o Added extension points 1553 o Improved exemplary firmware-resource extension 1555 Changes from version 04 to version 05: 1557 o Clarified language around SWID and CoSWID to make more consistant 1558 use of these terms. 1560 o Added language describing CBOR optimizations for single vs. arrays 1561 in the model front matter. 1563 o Fixed a number of gramatical, spelling, and wording issues. 1565 o Documented extension points that use CDDL sockets. 1567 o Converted IANA registration tables to markdown tables, reserving 1568 the 0 value for use when a value is not known. 1570 o Updated a number of references to their current versions. 1572 Changes from version 03 to version 04: 1574 o Re-index label values in the CDDL. 1576 o Added a section describing the CoSWID model in detail. 1578 o Created IANA registries for entity-role and version-scheme 1580 Changes from version 02 to version 03: 1582 o Updated CDDL to allow for a choice between a payload or evidence 1584 o Re-index label values in the CDDL. 1586 o Added item definitions 1588 o Updated references for COSE, CBOR Web Token, and CDDL. 1590 Changes from version 01 to version 02: 1592 o Added extensions for Firmware and CoSWID use as Reference 1593 Integrity Measurements (CoSWID RIM) 1595 o Changes meta handling in CDDL from use of an explicit use of items 1596 to a more flexible unconstrained collection of items. 1598 o Added sections discussing use of COSE Signatures and CBOR Web 1599 Tokens 1601 Changes from version 00 to version 01: 1603 o Added CWT usage for absolute SWID paths on a device 1605 o Fixed cardinality of type-choices including arrays 1607 o Included first iteration of firmware resource-collection 1609 Changes since adopted as a WG I-D -00: 1611 o Removed redundant any-attributes originating from the ISO- 1612 19770-2:2015 XML schema definition 1614 o Fixed broken multi-map members 1616 o Introduced a more restrictive item (any-element-map) to represent 1617 custom maps, increased restriction on types for the any-attribute, 1618 accordingly 1620 o Fixed X.1520 reference 1622 o Minor type changes of some attributes (e.g. NMTOKENS) 1623 o Added semantic differentiation of various name types (e,g. fs- 1624 name) 1626 Changes from version 00 to version 01: 1628 o Ambiguity between evidence and payload eliminated by introducing 1629 explicit members (while still 1631 o allowing for "empty" SWID tags) 1633 o Added a relatively restrictive COSE envelope using cose_sign1 to 1634 define signed CoSWID (single signer only, at the moment) 1636 o Added a definition how to encode hashes that can be stored in the 1637 any-member using existing IANA tables to reference hash-algorithms 1639 Changes from version 01 to version 02: 1641 o Enforced a more strict separation between the core CoSWID 1642 definition and additional usage by moving content to corresponding 1643 appendices. 1645 o Removed artifacts inherited from the reference schema provided by 1646 ISO (e.g. NMTOKEN(S)) 1648 o Simplified the core data definition by removing group and type 1649 choices where possible 1651 o Minor reordering of map members 1653 o Added a first extension point to address requested flexibility for 1654 extensions beyond the any-element 1656 8. Contributors 1658 9. References 1660 9.1. Normative References 1662 [I-D.ietf-ace-cbor-web-token] 1663 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1664 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15 1665 (work in progress), March 2018. 1667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1668 Requirement Levels", BCP 14, RFC 2119, 1669 DOI 10.17487/RFC2119, March 1997, 1670 . 1672 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 1673 Protect Firmware Packages", RFC 4108, 1674 DOI 10.17487/RFC4108, August 2005, 1675 . 1677 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1678 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 1679 September 2009, . 1681 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1682 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1683 October 2013, . 1685 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1686 Writing an IANA Considerations Section in RFCs", BCP 26, 1687 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1688 . 1690 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1691 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1692 . 1694 [SAM] "Information technology - Software asset management - Part 1695 5: Overview and vocabulary", ISO/IEC 19770-5:2013, 1696 November 2013. 1698 [SEMVER] Preston-Werner, T., "Semantic Versioning 2.0.0", n.d., 1699 . 1701 [SWID] "Information technology - Software asset management - Part 1702 2: Software identification tag", ISO/IEC 19770-2:2015, 1703 October 2015. 1705 [SWID-GUIDANCE] 1706 Waltermire, D., Cheikes, B., Feldman, L., and G. Witte, 1707 "Guidelines for the Creation of Interoperable Software 1708 Identification (SWID) Tags", NISTIR 8060, April 2016, 1709 . 1711 [X.1520] "Recommendation ITU-T X.1520 (2014), Common 1712 vulnerabilities and exposures", April 2011. 1714 9.2. Informative References 1716 [I-D.birkholz-tuda] 1717 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 1718 "Time-Based Uni-Directional Attestation", draft-birkholz- 1719 tuda-04 (work in progress), March 2017. 1721 [I-D.ietf-cbor-cddl] 1722 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 1723 definition language (CDDL): a notational convention to 1724 express CBOR data structures", draft-ietf-cbor-cddl-02 1725 (work in progress), February 2018. 1727 [I-D.ietf-sacm-rolie-softwaredescriptor] 1728 Waltermire, D. and S. Banghart, "Definition of the ROLIE 1729 Software Descriptor Extension", draft-ietf-sacm-rolie- 1730 softwaredescriptor-02 (work in progress), March 2018. 1732 [I-D.ietf-sacm-terminology] 1733 Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and 1734 A. Montville, "Security Automation and Continuous 1735 Monitoring (SACM) Terminology", draft-ietf-sacm- 1736 terminology-15 (work in progress), June 2018. 1738 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1739 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1740 DOI 10.17487/RFC4122, July 2005, 1741 . 1743 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1744 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1745 . 1747 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1748 Constrained-Node Networks", RFC 7228, 1749 DOI 10.17487/RFC7228, May 2014, 1750 . 1752 Appendix A. CoSWID Attributes for Firmware (label 60) 1754 The ISO-19770-2:2015 specification of SWID tags assumes the existence 1755 of a file system a software component is installed and stored in. In 1756 the case of constrained-node networks [RFC7228] or network equipment 1757 this assumption might not apply. Concise software instances in the 1758 form of (modular) firmware are often stored directly on a block 1759 device that is a hardware component of the constrained-node or 1760 network equipment. Multiple differentiable block devices or 1761 segmented block devices that contain parts of modular firmware 1762 components (potentially each with their own instance version) are 1763 already common at the time of this writing. 1765 The optional attributes that annotate a firmware package address 1766 specific characteristics of pieces of firmware stored directly on a 1767 block-device in contrast to software deployed in a file-system. In 1768 essence, trees of relative path-elements expressed by the directory 1769 and file structure in CoSWID tags are typically unable to represent 1770 the location of a firmware on a constrained-node (small thing). The 1771 composite nature of firmware and also the actual composition of small 1772 things require a set of attributes to address the identification of 1773 the correct component in a composite thing for each individual piece 1774 of firmware. A single component also potentially requires a number 1775 of distinct firmware parts that might depend on each other 1776 (versions). These dependencies can be limited to the scope of the 1777 component itself or extend to the scope of a larger composite device. 1778 In addition, it might not be possible (or feasible) to store a CoSWID 1779 tag document (permanently) on a small thing along with the 1780 corresponding piece of firmware. 1782 To address the specific characteristics of firmware, the extension 1783 points "$$payload-extension" and "$$evidence-extension" are used to 1784 allow for an additional type of resource description--firmware- 1785 entry--thereby increasing the self-descriptiveness and flexibility of 1786 CoSWID. The optional use of the extension points "$$payload- 1787 extension" and "$$evidence-extension" in respect to firmware MUST 1788 adhere to the following CDDL data definition. 1790 1791 $$payload-extension //= (firmware-entry,) 1792 $$evidence-extension //= (firmware-entry,) 1794 firmware-manifest = { 1795 firmware-manifest-id, 1796 firmware-manifest-creation-timestamp, 1797 firmware-manifest-version, 1798 firmware-manifest-description, 1799 firmware-manifest-nonce, 1800 ? firmware-manifest-aliases, 1801 ? firmware-manifest-dependencies, 1802 firmware-target-device-identifier, 1803 firmware-payload-entry, 1804 ? simple-firmware-manifest-extensions, 1805 $$firmware-manifest-extensions, 1806 } 1808 firmware-payload = { 1809 firmware-payload-id, 1810 ? firmware-package-identifier, 1811 firmware-payload-description, 1812 firmware-payload-format, 1813 firmware-payload-size, 1814 ? firmware-payload-simple-version, 1815 ? firmware-payload-version, 1816 firmware-payload-digests, 1817 ? firmware-target-component-index, 1818 firmware-target-storage-identifier, 1819 firmware-payload-conditions, 1820 ? firmware-payload-directives, 1821 ? firmware-target-dependency, 1822 ? firmware-target-minimal-version, 1823 ? firmware-payload-relationships, 1824 firmware-payload-package, 1825 ? simple-firmware-payload-extensions, 1826 $$firmware-payload-extensions, 1827 } 1829 firmware-entry = (59: firmware-manifest / [ 2* firmware-manifest ]) 1830 firmware-payload-entry = (60: firmware-payload / [ 2* firmware-payload ]) 1831 firmware-payload-id = (61: bytes / text / uint) 1832 firmware-package-identifier = (62: text) 1833 firmware-manifest-id = (63: bytes / text / int) 1834 firmware-manifest-creation-timestamp = (64: time) 1835 firmware-manifest-version = (65: uint) 1836 firmware-manifest-description = (66: text) 1837 firmware-manifest-nonce = (67: bytes) 1838 firmware-manifest-dependencies = (68: resource-reference) 1839 firmware-manifest-aliases = (69: resource-reference) 1840 resource-reference = [ + [ resource-reference-uri: uri, 1841 resource-reference-digest: bytes, 1842 ], 1843 ] 1844 firmware-payload-description = (70: text) 1845 firmware-payload-format = (71: { firmware-payload-format-type, 1846 ? firmware-payload-format-guidance, 1847 } 1848 ) 1849 firmware-payload-format-type = (72: int) 1850 firmware-payload-format-guidance = (73: bytes) 1851 firmware-payload-size = (74: uint) 1852 firmware-payload-package = (75: { ? firmware-package-compression-type, 1853 ? firmware-package-compression-guidance, 1854 firmware-package, 1855 } 1856 ) 1857 firmware-package-compression-type = (76: text / int) 1858 firmware-package-compression-guidance = (77: bytes) 1859 firmware-package = (78: bytes) 1860 firmware-target-component-index = (79: text) 1861 firmware-target-storage-identifier = (80: bytes / text / int) 1862 firmware-target-dependency = (81: [ ? { firmware-target-major-version, 1863 version-comparison, 1864 required-version, 1866 }, 1867 ? { firmware-target-minor-version, 1868 version-comparison, 1869 required-version, 1870 }, 1871 ? { firmware-target-revision-version, 1872 version-comparison, 1873 required-version, 1874 }, 1875 ? { firmware-target-build-version, 1876 version-comparison, 1877 required-version, 1878 }, 1879 ] 1880 ) 1881 firmware-payload-relationships = (82: [ + { firmware-payload-relationship-type, 1882 firmware-payload-ids, 1883 }, 1884 ] 1885 ) 1886 firmware-payload-ids = (83: [ + ( bytes / text / int )]) 1887 firmware-payload-relationship-type = (84: $firmware-payload-relationship-types) 1888 $firmware-payload-relationship-types /= patches-firmware 1889 $firmware-payload-relationship-types /= requires-firmware 1890 $firmware-payload-relationship-types /= supersedes-firmware 1891 patches-firmware = 1 1892 requires-firmware = 2 1893 supersedes-firmware = 3 1894 firmware-target-device-identifier = (85: { firmware-target-vendor-identifier, 1895 ? firmware-target-type-identifier, 1896 firmware-target-model-identifier, 1897 ? firmware-target-class-identifier, 1898 ? firmware-target-rfc4122-identifier, 1899 ? firmware-target-8021AR-identifier, 1900 $$firmware-target-identifier-extensions, 1901 } 1902 ) 1903 firmware-target-vendor-identifier = (86: text) 1904 firmware-target-type-identifier = (87: text) 1905 firmware-target-model-identifier = (88: text) 1906 firmware-target-class-identifier = (89: text) 1907 firmware-target-rfc4122-identifier = (90: text) 1908 firmware-target-8021AR-identifier = (91: bytes) 1909 firmware-target-minimal-version = (92: { firmware-target-major-version, 1910 firmware-target-minor-version, 1911 ? firmware-target-revision-version, 1912 ? firmware-target-build-version, 1913 ? firmware-target-storage-identifier, 1915 }, 1916 ) 1917 firmware-target-major-version = (93: uint) 1918 firmware-target-minor-version = (94: uint) 1919 firmware-target-revision-version = (95: uint) 1920 firmware-target-build-version = (96: uint) 1921 firmware-payload-digests = (97: [ + { firmware-digest-type, 1922 ? firmware-digest-config-guidance, 1923 firmware-digest, 1924 }, 1925 ] 1926 ) 1927 firmware-digest-type = (98: $firmware-digest-types) 1928 $firmware-digest-types /= raw-payload-digest 1929 $firmware-digest-types /= installed-payload-digest 1930 $firmware-digest-types /= ciphertext-digest 1931 $firmware-digest-types /= pre-image-digest 1932 raw-payload-digest = 1 1933 installed-payload-digest = 2 1934 ciphertext-digest = 3 1935 pre-image-digest = 4 1936 firmware-digest-config-guidance = (99: bytes) 1937 firmware-digest = (100: bytes) 1938 firmware-payload-conditions = (101: [ + { firmware-payload-condition-type, 1939 firmware-payload-condition-parameters, 1940 }, 1941 ] 1942 ) 1943 firmware-payload-condition-parameters = (102: bytes) 1944 firmware-payload-condition-type = (103: $firmware-payload-condition-types) 1945 $firmware-payload-condition-types /= vendor-id-condition 1946 $firmware-payload-condition-types /= class-id-condition 1947 $firmware-payload-condition-types /= device-id-condition 1948 $firmware-payload-condition-types /= best-before-condition 1949 vendor-id-condition = 1 1950 class-id-condition = 2 1951 device-id-condition = 3 1952 best-before-condition = 4 1953 firmware-payload-directives = (104: [ + { firmware-payload-directive-type, 1954 firmware-payload-directive-parameters, 1955 }, 1956 ] 1957 ) 1958 firmware-payload-directive-parameters = (105: bytes) 1959 firmware-payload-directive-type = (106: $firmware-payload-directive-types) 1960 $firmware-payload-directive-types /= apply-immediately-directive 1961 $firmware-payload-directive-types /= apply-after-directive 1962 apply-immediately-directive = 1 1963 apply-after-directive = 2 1964 firmware-payload-simple-version = (107: uint) 1965 firmware-payload-version = (108: { firmware-payload-major-version, 1966 firmware-payload-minor-version, 1967 ? firmware-payload-revision-version, 1968 ? firmware-payload-build-version, 1969 } 1970 ) 1971 firmware-payload-major-version = (109: uint) 1972 firmware-payload-minor-version = (110: uint) 1973 firmware-payload-revision-version = (111: uint) 1974 firmware-payload-build-version = (112: uint) 1975 version-comparison = (113: eq / ne / lt / le / gt / ge) 1976 required-version = (114: uint) 1977 simple-firmware-manifest-extensions = (115: { + int => bytes }) 1978 simple-firmware-payload-extensions = (116: { + int => bytes }) 1979 eq = 0 1980 ne = 1 1981 lt = 2 1982 le = 3 1983 gt = 4 1984 ge = 5 1985 1987 The members of the firmware group that constitutes the content of the 1988 firmware-entry is based on the metadata about firmware Described in 1989 [RFC4108]. As with every semantic differentiation that is supported 1990 by the resource-collection type, the use of firmware-entry is 1991 optional. It is REQUIRED not to instantiate more than one firmware- 1992 entry, as the firmware group is used in a map and therefore only 1993 allows for unique labels. 1995 The optional cms-firmware-package member allows to include the actual 1996 firmware in the CoSWID tag that also expresses its metadata as a 1997 byte-string. This option enables a CoSWID tag to be used as a 1998 container or wrapper that composes both firmware and its metadata in 1999 a single document (which again can be signed, encrypted and/or 2000 compressed). In consequence, a CoSWID tag about firmware can be 2001 conveyed as an identifying document across endpoints or used as a 2002 reference integrity measurement as usual. Alternatively, it can also 2003 convey an actual piece of firmware, serve its intended purpose as a 2004 SWID tag and then - due to the lack of a location to store it - be 2005 discarded. 2007 Appendix B. Signed Concise SWID Tags using COSE 2009 SWID tags, as defined in the ISO-19770-2:2015 XML schema, can include 2010 cryptographic signatures to protect the integrity of the SWID tag. 2011 In general, tags are signed by the tag creator (typically, although 2012 not exclusively, the vendor of the software component that the SWID 2013 tag identifies). Cryptographic signatures can make any modification 2014 of the tag detectable, which is especially important if the integrity 2015 of the tag is important, such as when the tag is providing reference 2016 integrity measurements for files. 2018 The ISO-19770-2:2015 XML schema uses XML DSIG to support 2019 cryptographic signatures. CoSWID tags require a different signature 2020 scheme than this. COSE (CBOR Object Signing and Encryption) provides 2021 the required mechanism [RFC8152]. Concise SWID can be wrapped in a 2022 COSE Single Signer Data Object (cose-sign1) that contains a single 2023 signature. The following CDDL defines a more restrictive subset of 2024 header attributes allowed by COSE tailored to suit the requirements 2025 of Concise SWID. 2027 2028 signed-coswid = #6.997(COSE-Sign1-coswid) ; see TBS7 in current COSE I-D 2030 label = int / tstr ; see COSE I-D 1.4. 2031 values = any ; see COSE I-D 1.4. 2033 unprotected-signed-coswid-header = { 2034 1 => int, ; algorithm identifier 2035 3 => "application/coswid", ; request for CoAP IANA registry to become an int 2036 * label => values, 2037 } 2039 protected-signed-coswid-header = { 2040 4 => bstr, ; key identifier 2041 * label => values, 2042 } 2044 COSE-Sign1-coswid = [ 2045 protected: bstr .cbor protected-signed-coswid-header, 2046 unprotected: unprotected-signed-coswid-header, 2047 payload: bstr .cbor concise-software-identity, 2048 signature: bstr, 2049 ] 2050 2051 Appendix C. CoSWID used as Reference Integrity Measurements (CoSWID 2052 RIM) 2054 A vendor supplied signed CoSWID tag that includes hash-values for the 2055 files that compose a software component can be used as a RIM 2056 (reference integrity measurement). A RIM is a type of declarative 2057 guidance that can be used to assert the compliance of an endpoint by 2058 assessing the installed software. In the context of remote 2059 attestation based on an attestation via hardware rooted trust, a 2060 verifier can appraise the integrity of the conveyed measurements of 2061 software components using a CoSWID RIM provided by a source, such as 2062 [I-D.ietf-sacm-rolie-softwaredescriptor]. 2064 RIM Manifests (RIMM): A group of SWID tags about the same 2065 (sub-)system, system entity, or (sub-)component (compare 2066 [RFC4949]). A RIMM manifest is a distinct document that is 2067 typically conveyed en-block and constitutes declarative guidance 2068 in respect to a specific (target) endpoint (compare 2069 [I-D.ietf-sacm-terminology]). 2071 If multiple CoSWID compose a RIMM, the following CDDL data definition 2072 SHOULD be used. 2074 RIMM = [ + concise-software-identity / signed-coswid ] 2076 Appendix D. CBOR Web Token for Concise SWID Tags 2078 A typical requirement regarding specific instantiations of endpoints 2079 - and, as a result, specific instantiations of software components - 2080 is a representation of the absolute path of a CoSWID tag document in 2081 a file system in order to derive absolute paths of files represented 2082 in the corresponding CoSWID tag. The absolute path of an evidence 2083 CoSWID tag can be included as a claim in the header of a CBOR Web 2084 Token [I-D.ietf-ace-cbor-web-token]. Depending on the source of the 2085 token, the claim can be in the protected or unprotected header 2086 portion. 2088 2089 CDDL TBD 2090 2092 Authors' Addresses 2093 Henk Birkholz 2094 Fraunhofer SIT 2095 Rheinstrasse 75 2096 Darmstadt 64295 2097 Germany 2099 Email: henk.birkholz@sit.fraunhofer.de 2101 Jessica Fitzgerald-McKay 2102 Department of Defense 2103 9800 Savage Road 2104 Ft. Meade, Maryland 2105 USA 2107 Email: jmfitz2@nsa.gov 2109 Charles Schmidt 2110 The MITRE Corporation 2111 202 Burlington Road 2112 Bedford, Maryland 01730 2113 USA 2115 Email: cmschmidt@mitre.org 2117 David Waltermire 2118 National Institute of Standards and Technology 2119 100 Bureau Drive 2120 Gaithersburg, Maryland 20877 2121 USA 2123 Email: david.waltermire@nist.gov