idnits 2.17.1 draft-ietf-sacm-rolie-softwaredescriptor-08.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8322]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 21, 2019) is 1740 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5070' is defined on line 551, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-11 ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM Working Group S. Banghart 3 Internet-Draft D. Waltermire 4 Intended status: Informational NIST 5 Expires: January 22, 2020 July 21, 2019 7 Definition of the ROLIE Software Descriptor Extension 8 draft-ietf-sacm-rolie-softwaredescriptor-08 10 Abstract 12 This document uses the "information-type" extension point as defined 13 in the Resource-Oriented Lightweight Information Exchange (ROLIE) 14 [RFC8322] Section 7.1.2 to better support Software Record and 15 Software Inventory use cases. This specification registers a new 16 ROLIE information-type, "software-descriptor", that allows for the 17 categorization of information relevant to software description 18 activities and formats. In particular, the usage of the ISO 19 19770-2:2015 Software Identification Tag (SWID Tag) and the Concise 20 SWID (COSWID) formats in ROLIE are standardized. Additionally, this 21 document discusses requirements and usage of other ROLIE elements in 22 order to best syndicate software description information. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 22, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. The "software-descriptor" information type . . . . . . . . . 4 62 5. rolie:property Extensions . . . . . . . . . . . . . . . . . . 5 63 5.1. urn:ietf:params:rolie:property:swd:swname . . . . . . . . 5 64 5.2. urn:ietf:params:rolie:property:swd:swversion . . . . . . 6 65 5.3. urn:ietf:params:rolie:property:swd:swcreator . . . . . . 6 66 6. Data format requirements . . . . . . . . . . . . . . . . . . 6 67 6.1. The ISO SWID 2015 format . . . . . . . . . . . . . . . . 6 68 6.1.1. Description . . . . . . . . . . . . . . . . . . . . . 6 69 6.1.2. Requirements . . . . . . . . . . . . . . . . . . . . 7 70 6.2. The Concise SWID format . . . . . . . . . . . . . . . . . 7 71 6.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7 72 6.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 8 73 7. atom:link Extensions . . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8.1. software-descriptor information-type . . . . . . . . . . 10 76 8.2. swd:swname property . . . . . . . . . . . . . . . . . . . 10 77 8.3. swd:swversion property . . . . . . . . . . . . . . . . . 11 78 8.4. swd:swcreator property . . . . . . . . . . . . . . . . . 11 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 81 Appendix A. Schema . . . . . . . . . . . . . . . . . . . . . . . 12 82 Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 This document defines an extension to the Resource-Oriented 88 Lightweight Information Exchange (ROLIE) [RFC8322] to support the 89 publication of software descriptor information. Software descriptor 90 information is information that characterizes static software 91 components, packages, and installers; including identification, 92 version, software creation and publication, and file artifact 93 information. 95 Software descriptor information provides data about what might be 96 installed, but doesn't describe a specific software installation's 97 configuration or execution. This static approach to software 98 description is a tightly limited scope that still covers the majority 99 of current use cases for software inventory and record keeping. 101 Some possible use cases for software descriptor information ROLIE 102 Feeds (Section 6.1 of [RFC8322]) include: 104 o Software providers can publish software descriptor information so 105 that software researchers, enterprises, and users of software can 106 understand the collection of software produced by that software 107 provider. 109 o Organizations can aggregate and syndicate collections of software 110 descriptor information provided by multiple software providers to 111 support software-related analysis processes (e.g., vulnerability 112 analysis) and to provide downsteam services (e.g., software 113 configuration checklist repositories). 115 o End user organizations can consume software descriptor information 116 along with related software vulnerability and configuration 117 information to provide the data needed to automate software asset, 118 patch, and configuration management practices. 120 o Organizations can use software descriptors to support verification 121 of other entities through integrity measurement mechanisms. 123 This document supports these use cases by describing the content 124 requirements for Feeds and Entries of software descriptor information 125 that are to be published to or retrieved from a ROLIE repository. 127 2. Terminology 129 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 130 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 As an extension of [RFC8322], this document refers to many terms 134 defined in that document. In particular, the use of "Entry" and 135 "Feed" are aligned with the definitions presented in RFC8322. 137 Several places in this document refer to the "information-type" of a 138 Resource (Entry or Feed). This refers to the "term" attribute of an 139 "atom:category" element whose scheme is 140 "urn:ietf:params:rolie:category:information-type". For an Entry, 141 this value can be inherited from it's containing Feed as per 142 [RFC8322]. 144 3. Background 146 In order to effectively protect and secure an endpoint, it is vital 147 to know what the software load of that endpoint is. Software load, 148 the combination of software, patches and installers on a device, 149 represents a significant portion of the endpoint's attack surface. 150 Unfortunately, without a reliable and secure package manager, or a 151 secured and managed operating system with strict software 152 whitelisting, tracking what software is installed on an endpoint is 153 currently not feasible without undue effort. Even attempting to 154 whitelist software is difficult without a way of identifying software 155 and its editions, versions and hotfixes. 157 Software descriptor information, such as that standardized in the ISO 158 19770-2:2015 Software Identification Tag (SWID) format or expressed 159 in proprietary enterprise databases, attempts to provide as much data 160 about this software as possible. 162 Once this information is expressed, it needs to be stored and shared 163 to internal and external parties. ROLIE provides a mechanism to 164 handle this sharing in an automation-friendly way. 166 4. The "software-descriptor" information type 168 When an "atom:category" element has a "scheme" attribute equal to 169 "urn:ietf:params:rolie:category:information-type", the "term" 170 attribute defines the information type of the associated resource. A 171 new valid value for this "term": "software-descriptor", is described 172 in this section and registered in Section 8.1. When this value is 173 used, the resource in question is considered to have an information- 174 type of "software-descriptor" as per [RFC8322] Section 7.1.2. 176 The "software-descriptor" information type represents any static 177 information that describes a piece of software. This document uses 178 the definition of software provided by [RFC4949]. Note that as per 179 this definition, this information type pertains to static software, 180 that is, code on the disc. The "software-descriptor" information 181 type is intended to provide a category for information that does one 182 or more of the following: 184 identifies and characterizes software: information that provides 185 quantative and qualitative data describing software. This 186 information identifies and charaterizes a given instance of 187 software. 189 provides software installer metadata: information about software 190 used to install other software. This metadata identifies, and 191 characterizes a software installation package or media. 193 describes stateless installation metadata: information that 194 describes the software post-deployment, such as files that may be 195 deployed during an installation. It is expected that this 196 metadata is produced generally for a given installation, and may 197 not exactly match the actual installed files on a given endpoint. 199 Provided below is a non-exhaustive list of information that may be 200 considered to be of a software-descriptor information type. 202 o Naming information: IDs and names that aid in the identification 203 of a piece of software 205 o Version and patching information: Version numbers, patch 206 identifiers, or other information that relates to software updates 207 and patches. 209 o Vendor and source information: Includes where the software was 210 developed or distributed, as well as where the software 211 installation media may be located. 213 o Payload and file information: information that describes or 214 enumerates the files and folders that make up the piece of 215 software, and information about those files. 217 o Descriptive information and data: Any information that otherwise 218 characterizes a piece of software, such as libraries, runtime 219 environments, target operating systems, intended purpose or 220 audience, etc. 222 It is important to note that software descriptor information is 223 static for a given piece of software. That is, the information 224 expressed is the data that doesn't change from the publication of the 225 software to its final install. Information about the current status 226 (e.g. install location, memory usage, CPU usage, launch parameters, 227 job progress, etc.), is out of scope of this information type. 229 5. rolie:property Extensions 231 This document registers new valid rolie:property names as follows: 233 5.1. urn:ietf:params:rolie:property:swd:swname 235 This property provides an exposure point for the plain text name of 236 the software being described. Naming of software is not a well 237 standardized process, and software names can change between product 238 versions or editions. As such, care should be taken that this value 239 is set as consistently as possible by generating it directly from an 240 attached software descriptor resource. 242 5.2. urn:ietf:params:rolie:property:swd:swversion 244 This property provides an exposure point for the version of the 245 software being described. This value should be generated or taken 246 from the software descriptor linked to by the entry. This helps 247 avoid, but does not prevent, inconsistent versioning schemes being 248 shared. 250 5.3. urn:ietf:params:rolie:property:swd:swcreator 252 This property provides an exposure point for a plain text name of the 253 creator of the software being described. This is in many cases an 254 organization or company, but certainly could be a single person. 255 Most software descriptor formats include this information, and where 256 possible, this property should be set equal to that value. 258 6. Data format requirements 260 This section defines usage guidance and additional requirements 261 related to data formats above and beyond those specified in 262 [RFC8322]. The following formats are expected to be commonly used to 263 express software descriptor information. For this reason, this 264 document specifies additional requirements to ensure 265 interoperability. 267 6.1. The ISO SWID 2015 format 269 6.1.1. Description 271 ISO/IEC 19770-2:2015 defines a software record data format referred 272 to as a "SWID Tag". It provides several tag types: 274 o primary: provides descriptive and naming information about 275 software, 277 o patch: describes non-standalone software meant to patch existing 278 software, 280 o corpus: describes the software installation media that installs a 281 given piece of software, 283 o supplemental: provides additional metadata to be deployed 284 alongside a tag. 286 For a more complete overview as well as normative requirements, refer 287 to ISO/IEC 19770-2:2015 [SWID]. 289 For additional requirements and guidance around creation of SWID 290 Tags, consult NIST Internal Report 8060 [NISTIR8060]. 292 6.1.2. Requirements 294 For an Entry to be considered as a "SWID Tag Entry", it MUST fulfill 295 the following conditions: 297 o The information-type of the Entry is "software-descriptor". For a 298 typical Entry, this is derived from the information type of the 299 Feed it is contained in. For a standalone Entry, this is provided 300 by an "atom:category" element. 302 o The document linked to by the "href" attribute of the 303 "atom:content" element is a 2015 SWID Tag per ISO/IEC 304 19770-2:2015. 306 A "SWID Tag Entry" MUST conform to the following requirements: 308 o The value of the "type" attribute of the "atom:content" element 309 MUST be "application/xml". 311 o There MUST be one "rolie:property" with the "name" attribute equal 312 to "urn:ietf:params:rolie:property:content-id" and the "value" 313 attribute exactly equal to the "" element in the attached 314 SWID Tag. This allows ROLIE consumers to more easily search for 315 SWID tags without needing to download the tag itself. 317 o There MUST be one "rolie:property" with the "name" attribute equal 318 to "urn:ietf:params:rolie:property:swd:swname", and the "value" 319 attribute equal to the value of the "" element in the 320 attached SWID Tag. As above, this helps ROLIE consumers search and 321 filter Entries. 323 o There MAY be a property element with the "name" attribute equal to 324 "urn:ietf:params:rolie:property:swd:swversion". When this 325 property appears, its value MUST be equal to the value of the 326 "version" element in the attached SWID Tag. 328 6.2. The Concise SWID format 330 6.2.1. Description 332 The Concise SWID (COSWID) format is an alternative representation of 333 the SWID Tag format using a Concise Binary Object Representation 334 (CBOR) encoding. CBOR provides the format with a reduced size that 335 is more suitable for constrained devices. COSWID provides the same 336 features and attributes as are specified in ISO 19770-2:2015, plus: 338 o a straight forward method to sign and encrypt using COSE, and 340 o additional attributes that provide an improved structure to 341 include file hashes intended to be used as Reference Integrity 342 Measurements (RIM). 344 For more information and the complete specification, refer to the 345 COSWID internet draft [I-D.ietf-sacm-coswid]. 347 6.2.2. Requirements 349 For an Entry to be considered as a "COSWID Tag Entry", it MUST 350 fulfill the following conditions: 352 o The information-type of the Entry is "software-descriptor". For a 353 typical Entry, this is derived from the information-type of the 354 Feed it is contained in. For a standalone Entry, this is provided 355 by an "atom:category" element. 357 o The document linked to by the "href" attribute of the 358 "atom:content" element is a COSWID Tag per [I-D.ietf-sacm-coswid] 360 A "COSWID Tag Entry" MUST conform to the following requirements: 362 o The value of the "type" attribute of the atom:content element MUST 363 be "application/swid+cbor". 365 o There MUST be one "rolie:property" with the "name" attribute equal 366 to "urn:ietf:params:rolie:property:content-id" and the "value" 367 attribute exactly equal to the decoded "tag-id" element in the 368 attached COSWID Tag (mapped to integer 0). This allows ROLIE 369 consumers to more easily search for COSWID tags without needing to 370 download the tag itself. 372 o There MUST be one "rolie:property" with the "name" attribute equal 373 to "urn:ietf:params:rolie:property:swd:swname", and the "value" 374 attribute equal to the decoded value of the "swid-name" element in 375 the attached COSWID Tag (mapped to the integer 1). As above, this 376 helps ROLIE consumers search and filter Entries. 378 o There MAY be a property element with the "name" attribute equal to 379 "urn:ietf:params:rolie:property:swd:swversion". When this 380 property appears, it's value MUST be equal to the decoded value of 381 the tag-version element in the attached COSWID Tag (mapped to the 382 integer 12). 384 7. atom:link Extensions 386 This section defines additional link relationships that 387 implementations MUST support. These relationships are not registered 388 in the Link Relation IANA table as their use case is too narrow. 389 Each relationship is named and described. 391 +----------------------+--------------------------------------------+ 392 | Name | Description | 393 +----------------------+--------------------------------------------+ 394 | ancestor | Links to a software descriptor resource | 395 | | that defines an ancestor of the software | 396 | | being described by this Entry. This is | 397 | | usually a previous version of the | 398 | | software. | 399 +----------------------+--------------------------------------------+ 400 | descendent | Links to a software descriptor resource | 401 | | that defines an descendent of the software | 402 | | being described by this Entry. This is | 403 | | usually a more recent version or edition | 404 | | of the software. | 405 +----------------------+--------------------------------------------+ 406 | patches | Links to a software descriptor resource | 407 | | that defines the software being patched by | 408 | | this software | 409 +----------------------+--------------------------------------------+ 410 | patchedby | Links to a software descriptor resource | 411 | | that defines the patch or update itself | 412 | | that can be or has been applied to this | 413 | | software. | 414 +----------------------+--------------------------------------------+ 415 | requires | Links to a software descriptor resource | 416 | | that defines a piece of software required | 417 | | for this software to function properly, | 418 | | i.e., a dependency. | 419 +----------------------+--------------------------------------------+ 420 | requiredBy | Links to a software descriptor resource | 421 | | that defines a piece of software that | 422 | | requires this software to function | 423 | | properly. | 424 +----------------------+--------------------------------------------+ 425 | installs | Links to a software descriptor resource | 426 | | that defines the software that is | 427 | | installed by this software. | 428 +----------------------+--------------------------------------------+ 429 | installedBy | Links to a software descriptor resource | 430 | | that defines the software package that | 431 | | installs this software. | 432 +----------------------+--------------------------------------------+ 433 | patchesVulnerability | Links to a vulnerability that this | 434 | | software update fixes. Used for software | 435 | | descriptors that describe software patches | 436 | | or updates. | 437 +----------------------+--------------------------------------------+ 438 | hasVulnerability | Links to a vulnerability description | 439 | | object that details a vulnerability that | 440 | | this software has. | 441 +----------------------+--------------------------------------------+ 443 Table 1: Link Relations for Resource-Oriented Lightweight Indicator 444 Exchange 446 8. IANA Considerations 448 8.1. software-descriptor information-type 450 IANA has added an entry to the "ROLIE Security Resource Information 451 Type Sub-Registry" registry located at 452 . 454 The entry is as follows: 456 name: software-descriptor 458 index: TBD 460 reference: This document, Section 4 462 8.2. swd:swname property 464 IANA has added an entry to the "ROLIE URN Parameters" registry 465 located in . 467 The entry is as follows: 469 name: property:swd:swname 471 Extension IRI: urn:ietf:params:rolie:property:swd:swname 473 Reference: This document, Section 5.1 475 Subregistry: None 477 8.3. swd:swversion property 479 IANA has added an entry to the "ROLIE URN Parameters" registry 480 located in . 482 The entry is as follows: 484 name: property:swd:swversion 486 Extension IRI: urn:ietf:params:rolie:property:swd:swversion 488 Reference: This document, Section 5.1 490 Subregistry: None 492 8.4. swd:swcreator property 494 IANA has added an entry to the "ROLIE URN Parameters" registry 495 located in . 497 The entry is as follows: 499 name: property:swd:swcreator 501 Extension IRI: urn:ietf:params:rolie:property:swd:swcreator 503 Reference: This document, Section 5.1 505 Subregistry: None 507 9. Security Considerations 509 Use of this extension implies dealing with the security implications 510 of both ROLIE and of software descriptors in general. As with any 511 data, care should be taken to verify the trustworthiness and veracity 512 of the descriptor information to the fullest extent possible. 514 Ideally, software descriptors should be signed by the software 515 manufacturer, or signed by whichever agent processed the source code. 516 Software descriptor documents from these sources are more likely to 517 be accurate than those generated by scraping installed software. 519 These "authoritative" sources of software descriptor content should 520 consider additional security for their ROLIE repository beyond the 521 typical recommendations, as the central importance of the repository 522 is likely to make it a target. 524 Version information is often represented differently across 525 manufacturers and even across product releases. If using software 526 version information for low fault tolerance comparisons and searches, 527 care should be taken that the correct version scheme is being used. 529 10. Normative References 531 [I-D.ietf-sacm-coswid] 532 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 533 Waltermire, "Concise Software Identification Tags", draft- 534 ietf-sacm-coswid-11 (work in progress), June 2019. 536 [NISTIR8060] 537 Waltermire, D., Cheikes, B., Feldman, L., and G. Witte, 538 "Guidelines for the Creation of Interoperable Software 539 Identification (SWID) Tags", NISTIR 8060, April 2016, 540 . 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, 544 DOI 10.17487/RFC2119, March 1997, 545 . 547 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 548 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 549 . 551 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 552 Object Description Exchange Format", RFC 5070, 553 DOI 10.17487/RFC5070, December 2007, 554 . 556 [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- 557 Oriented Lightweight Information Exchange (ROLIE)", 558 RFC 8322, DOI 10.17487/RFC8322, February 2018, 559 . 561 [SWID] "Information technology - Software asset management - Part 562 2: Software identification tag", ISO/IEC 19770-2:2015, 563 October 2015, . 565 Appendix A. Schema 567 This document does not require any schema extensions. 569 Appendix B. Examples of Use 571 Use of this extension in a ROLIE repository will not typically change 572 that repository's operation. As such, the general examples provided 573 by the ROLIE core document would serve as examples. Provided below 574 is a sample software descriptor ROLIE entry: 576 577 579 dd786dba-88e6-440b-9158-b8fae67ef67c 580 Sample Software Descriptor 581 2015-08-04T18:13:51.0Z 582 2015-08-05T18:13:51.0Z 583 A descriptor for a piece of software published by this 584 organization. 585 586 587 588 590 593 595 597 599 Authors' Addresses 601 Stephen Banghart 602 NIST 603 100 Bureau Drive 604 Gaithersburg, Maryland 20877 605 USA 607 Email: stephen.banghart@nist.gov 609 David Waltermire 610 NIST 611 100 Bureau Drive 612 Gaithersburg, Maryland 20877 613 USA 615 Email: david.waltermire@nist.gov