idnits 2.17.1 draft-ietf-sacm-rolie-softwaredescriptor-07.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 (June 25, 2019) is 1765 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5070' is defined on line 552, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-10 ** 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: December 27, 2019 June 25, 2019 7 Definition of the ROLIE Software Descriptor Extension 8 draft-ietf-sacm-rolie-softwaredescriptor-07 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 December 27, 2019. 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 section TODO of 136 ROLIE. 138 Several places in this document refer to the "information-type" of a 139 Resource (Entry or Feed). This refers to the "term" attribute of an 140 "atom:category" element whose scheme is 141 "urn:ietf:params:rolie:category:information-type". For an Entry, 142 this value can be inherited from it's containing Feed as per 143 [RFC8322]. 145 3. Background 147 In order to effectively protect and secure an endpoint, it is vital 148 to know what the software load of that endpoint is. Software load, 149 the combination of software, patches and installers on a device, 150 represents a significant portion of the endpoint's attack surface. 151 Unfortunately, without a reliable and secure package manager, or a 152 secured and managed operating system with strict software 153 whitelisting, tracking what software is installed on an endpoint is 154 currently not feasible without undue effort. Even attempting to 155 whitelist software is difficult without a way of identifying software 156 and its editions, versions and hotfixes. 158 Software descriptor information, such as that standardized in the ISO 159 19770-2:2015 Software Identification Tag (SWID) format or expressed 160 in proprietary enterprise databases, attempts to provide as much data 161 about this software as possible. 163 Once this information is expressed, it needs to be stored and shared 164 to internal and external parties. ROLIE provides a mechanism to 165 handle this sharing in an automation-friendly way. 167 4. The "software-descriptor" information type 169 When an "atom:category" element has a "scheme" attribute equal to 170 "urn:ietf:params:rolie:category:information-type", the "term" 171 attribute defines the information type of the associated resource. A 172 new valid value for this "term": "software-descriptor", is described 173 in this section and registered in Section 8.1. When this value is 174 used, the resource in question is considered to have an information- 175 type of "software-descriptor" as per [RFC8322] Section 7.1.2. 177 The "software-descriptor" information type represents any static 178 information that describes a piece of software. This document uses 179 the definition of software provided by [RFC4949]. Note that as per 180 this definition, this information type pertains to static software, 181 that is, code on the disc. The "software-descriptor" information 182 type is intended to provide a category for information that does one 183 or more of the following: 185 identifies and characterizes software: information that provides 186 quantative and qualitative data describing software. This 187 information identifies and charaterizes a given instance of 188 software. 190 provides software installer metadata: information about software 191 used to install other software. This metadata identifies, and 192 characterizes a software installation package or media. 194 describes stateless installation metadata: information that 195 describes the software post-deployment, such as files that may be 196 deployed during an installation. It is expected that this 197 metadata is produced generally for a given installation, and may 198 not exactly match the actual installed files on a given endpoint. 200 Provided below is a non-exhaustive list of information that may be 201 considered to be of a software-descriptor information type. 203 o Naming information: IDs and names that aid in the identification 204 of a piece of software 206 o Version and patching information: Version numbers, patch 207 identifiers, or other information that relates to software updates 208 and patches. 210 o Vendor and source information: Includes where the software was 211 developed or distributed, as well as where the software 212 installation media may be located. 214 o Payload and file information: information that describes or 215 enumerates the files and folders that make up the piece of 216 software, and information about those files. 218 o Descriptive information and data: Any information that otherwise 219 characterizes a piece of software, such as libraries, runtime 220 environments, target operating systems, intended purpose or 221 audience, etc. 223 It is important to note that software descriptor information is 224 static for a given piece of software. That is, the information 225 expressed is the data that doesn't change from the publication of the 226 software to its final install. Information about the current status 227 (e.g. install location, memory usage, CPU usage, launch parameters, 228 job progress, etc.), is out of scope of this information type. 230 5. rolie:property Extensions 232 This document registers new valid rolie:property names as follows: 234 5.1. urn:ietf:params:rolie:property:swd:swname 236 This property provides an exposure point for the plain text name of 237 the software being described. Naming of software is not a well 238 standardized process, and software names can change between product 239 versions or editions. As such, care should be taken that this value 240 is set as consistently as possible by generating it directly from an 241 attached software descriptor resource. 243 5.2. urn:ietf:params:rolie:property:swd:swversion 245 This property provides an exposure point for the version of the 246 software being described. This value should be generated or taken 247 from the software descriptor linked to by the entry. This helps 248 avoid, but does not prevent, inconsistent versioning schemes being 249 shared. 251 5.3. urn:ietf:params:rolie:property:swd:swcreator 253 This property provides an exposure point for a plain text name of the 254 creator of the software being described. This is in many cases an 255 organization or company, but certainly could be a single person. 256 Most software descriptor formats include this information, and where 257 possible, this property should be set equal to that value. 259 6. Data format requirements 261 This section defines usage guidance and additional requirements 262 related to data formats above and beyond those specified in 263 [RFC8322]. The following formats are expected to be commonly used to 264 express software descriptor information. For this reason, this 265 document specifies additional requirements to ensure 266 interoperability. 268 6.1. The ISO SWID 2015 format 270 6.1.1. Description 272 ISO/IEC 19770-2:2015 defines a software record data format referred 273 to as a "SWID Tag". It provides several tag types: 275 o primary: provides descriptive and naming information about 276 software, 278 o patch: describes non-standalone software meant to patch existing 279 software, 281 o corpus: describes the software installation media that installs a 282 given piece of software, 284 o supplemental: provides additional metadata to be deployed 285 alongside a tag. 287 For a more complete overview as well as normative requirements, refer 288 to ISO/IEC 19770-2:2015 [SWID]. 290 For additional requirements and guidance around creation of SWID 291 Tags, consult NIST Internal Report 8060 [NISTIR8060]. 293 6.1.2. Requirements 295 For an Entry to be considered as a "SWID Tag Entry", it MUST fulfill 296 the following conditions: 298 o The information-type of the Entry is "software-descriptor". For a 299 typical Entry, this is derived from the information type of the 300 Feed it is contained in. For a standalone Entry, this is provided 301 by an "atom:category" element. 303 o The document linked to by the "href" attribute of the 304 "atom:content" element is a 2015 SWID Tag per ISO/IEC 305 19770-2:2015. 307 A "SWID Tag Entry" MUST conform to the following requirements: 309 o The value of the "type" attribute of the "atom:content" element 310 MUST be "application/xml". 312 o There MUST be one "rolie:property" with the "name" attribute equal 313 to "urn:ietf:params:rolie:property:content-id" and the "value" 314 attribute exactly equal to the "" element in the attached 315 SWID Tag. This allows ROLIE consumers to more easily search for 316 SWID tags without needing to download the tag itself. 318 o There MUST be one "rolie:property" with the "name" attribute equal 319 to "urn:ietf:params:rolie:property:swd:swname", and the "value" 320 attribute equal to the value of the "" element in the 321 attached SWID Tag. As above, this helps ROLIE consumers search and 322 filter Entries. 324 o There MAY be a property element with the "name" attribute equal to 325 "urn:ietf:params:rolie:property:swd:swversion". When this 326 property appears, its value MUST be equal to the value of the 327 "version" element in the attached SWID Tag. 329 6.2. The Concise SWID format 331 6.2.1. Description 333 The Concise SWID (COSWID) format is an alternative representation of 334 the SWID Tag format using a Concise Binary Object Representation 335 (CBOR) encoding. CBOR provides the format with a reduced size that 336 is more suitable for constrained devices. COSWID provides the same 337 features and attributes as are specified in ISO 19770-2:2015, plus: 339 o a straight forward method to sign and encrypt using COSE, and 341 o additional attributes that provide an improved structure to 342 include file hashes intended to be used as Reference Integrity 343 Measurements (RIM). 345 For more information and the complete specification, refer to the 346 COSWID internet draft [I-D.ietf-sacm-coswid]. 348 6.2.2. Requirements 350 For an Entry to be considered as a "COSWID Tag Entry", it MUST 351 fulfill the following conditions: 353 o The information-type of the Entry is "software-descriptor". For a 354 typical Entry, this is derived from the information-type of the 355 Feed it is contained in. For a standalone Entry, this is provided 356 by an "atom:category" element. 358 o The document linked to by the "href" attribute of the 359 "atom:content" element is a COSWID Tag per [I-D.ietf-sacm-coswid] 361 A "COSWID Tag Entry" MUST conform to the following requirements: 363 o The value of the "type" attribute of the atom:content element MUST 364 be "application/coswid+cbor". 366 o There MUST be one "rolie:property" with the "name" attribute equal 367 to "urn:ietf:params:rolie:property:content-id" and the "value" 368 attribute exactly equal to the "tag-id" element in the attached 369 COSWID Tag (mapped to integer 0). This allows ROLIE consumers to 370 more easily search for COSWID tags without needing to download the 371 tag itself. 373 o There MUST be one "rolie:property" with the "name" attribute equal 374 to "urn:ietf:params:rolie:property:swd:swname", and the "value" 375 attribute equal to the value of the "swid-name" element in the 376 attached COSWID Tag (mapped to the integer 1). As above, this 377 helps ROLIE consumers search and filter Entries. 379 o There MAY be a property element with the "name" attribute equal to 380 "urn:ietf:params:rolie:property:swd:swversion". When this 381 property appears, it's value MUST be equal to the value of the 382 tag-version element in the attached COSWID Tag (mapped to the 383 integer 12). 385 7. atom:link Extensions 387 This section defines additional link relationships that 388 implementations MUST support. These relationships are not registered 389 in the Link Relation IANA table as their use case is too narrow. 390 Each relationship is named and described. 392 +----------------------+--------------------------------------------+ 393 | Name | Description | 394 +----------------------+--------------------------------------------+ 395 | ancestor | Links to a software descriptor resource | 396 | | that defines an ancestor of the software | 397 | | being described by this Entry. This is | 398 | | usually a previous version of the | 399 | | software. | 400 +----------------------+--------------------------------------------+ 401 | descendent | Links to a software descriptor resource | 402 | | that defines an descendent of the software | 403 | | being described by this Entry. This is | 404 | | usually a more recent version or edition | 405 | | of the software. | 406 +----------------------+--------------------------------------------+ 407 | patches | Links to a software descriptor resource | 408 | | that defines the software being patched by | 409 | | this software | 410 +----------------------+--------------------------------------------+ 411 | patchedby | Links to a software descriptor resource | 412 | | that defines the patch or update itself | 413 | | that can be or has been applied to this | 414 | | software. | 415 +----------------------+--------------------------------------------+ 416 | requires | Links to a software descriptor resource | 417 | | that defines a piece of software required | 418 | | for this software to function properly, | 419 | | i.e., a dependency. | 420 +----------------------+--------------------------------------------+ 421 | requiredBy | Links to a software descriptor resource | 422 | | that defines a piece of software that | 423 | | requires this software to function | 424 | | properly. | 425 +----------------------+--------------------------------------------+ 426 | installs | Links to a software descriptor resource | 427 | | that defines the software that is | 428 | | installed by this software. | 429 +----------------------+--------------------------------------------+ 430 | installedBy | Links to a software descriptor resource | 431 | | that defines the software package that | 432 | | installs this software. | 433 +----------------------+--------------------------------------------+ 434 | patchesVulnerability | Links to a vulnerability that this | 435 | | software update fixes. Used for software | 436 | | descriptors that describe software patches | 437 | | or updates. | 438 +----------------------+--------------------------------------------+ 439 | hasVulnerability | Links to a vulnerability description | 440 | | object that details a vulnerability that | 441 | | this software has. | 442 +----------------------+--------------------------------------------+ 444 Table 1: Link Relations for Resource-Oriented Lightweight Indicator 445 Exchange 447 8. IANA Considerations 449 8.1. software-descriptor information-type 451 IANA has added an entry to the "ROLIE Security Resource Information 452 Type Sub-Registry" registry located at 453 . 455 The entry is as follows: 457 name: software-descriptor 459 index: TBD 461 reference: This document, Section 4 463 8.2. swd:swname property 465 IANA has added an entry to the "ROLIE URN Parameters" registry 466 located in . 468 The entry is as follows: 470 name: property:swd:swname 472 Extension IRI: urn:ietf:params:rolie:property:swd:swname 474 Reference: This document, Section 5.1 476 Subregistry: None 478 8.3. swd:swversion property 480 IANA has added an entry to the "ROLIE URN Parameters" registry 481 located in . 483 The entry is as follows: 485 name: property:swd:swversion 487 Extension IRI: urn:ietf:params:rolie:property:swd:swversion 489 Reference: This document, Section 5.1 491 Subregistry: None 493 8.4. swd:swcreator property 495 IANA has added an entry to the "ROLIE URN Parameters" registry 496 located in . 498 The entry is as follows: 500 name: property:swd:swcreator 502 Extension IRI: urn:ietf:params:rolie:property:swd:swcreator 504 Reference: This document, Section 5.1 506 Subregistry: None 508 9. Security Considerations 510 Use of this extension implies dealing with the security implications 511 of both ROLIE and of software descriptors in general. As with any 512 data, care should be taken to verify the trustworthiness and veracity 513 of the descriptor information to the fullest extent possible. 515 Ideally, software descriptors should be signed by the software 516 manufacturer, or signed by whichever agent processed the source code. 517 Software descriptor documents from these sources are more likely to 518 be accurate than those generated by scraping installed software. 520 These "authoritative" sources of software descriptor content should 521 consider additional security for their ROLIE repository beyond the 522 typical recommendations, as the central importance of the repository 523 is likely to make it a target. 525 Version information is often represented differently across 526 manufacturers and even across product releases. If using software 527 version information for low fault tolerance comparisons and searches, 528 care should be taken that the correct version scheme is being used. 530 10. Normative References 532 [I-D.ietf-sacm-coswid] 533 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 534 Waltermire, "Concise Software Identification Tags", draft- 535 ietf-sacm-coswid-10 (work in progress), June 2019. 537 [NISTIR8060] 538 Waltermire, D., Cheikes, B., Feldman, L., and G. Witte, 539 "Guidelines for the Creation of Interoperable Software 540 Identification (SWID) Tags", NISTIR 8060, April 2016, 541 . 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, 545 DOI 10.17487/RFC2119, March 1997, 546 . 548 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 549 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 550 . 552 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 553 Object Description Exchange Format", RFC 5070, 554 DOI 10.17487/RFC5070, December 2007, 555 . 557 [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- 558 Oriented Lightweight Information Exchange (ROLIE)", 559 RFC 8322, DOI 10.17487/RFC8322, February 2018, 560 . 562 [SWID] "Information technology - Software asset management - Part 563 2: Software identification tag", ISO/IEC 19770-2:2015, 564 October 2015, . 566 Appendix A. Schema 568 This document does not require any schema extensions. 570 Appendix B. Examples of Use 572 Use of this extension in a ROLIE repository will not typically change 573 that repository's operation. As such, the general examples provided 574 by the ROLIE core document would serve as examples. Provided below 575 is a sample software descriptor ROLIE entry: 577 578 580 dd786dba-88e6-440b-9158-b8fae67ef67c 581 Sample Software Descriptor 582 2015-08-04T18:13:51.0Z 583 2015-08-05T18:13:51.0Z 584 A descriptor for a piece of software published by this 585 organization. 586 587 588 589 591 594 596 598 600 Authors' Addresses 602 Stephen Banghart 603 NIST 604 100 Bureau Drive 605 Gaithersburg, Maryland 20877 606 USA 608 Email: stephen.banghart@nist.gov 610 David Waltermire 611 NIST 612 100 Bureau Drive 613 Gaithersburg, Maryland 20877 614 USA 616 Email: david.waltermire@nist.gov