idnits 2.17.1 draft-ietf-sacm-rolie-softwaredescriptor-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 : ---------------------------------------------------------------------------- ** 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). == Unrecognized Status in 'Intended status: InformationalNational Institute of Standards and Techno', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (March 27, 2019) is 1857 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) == Unused Reference: 'RFC5070' is defined on line 548, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'NISTIR8060' ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970) -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). 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: InformationalNational Institute of Standards and Techno 5 Expires: September 28, 2019 March 27, 2019 7 Definition of the ROLIE Software Descriptor Extension 8 draft-ietf-sacm-rolie-softwaredescriptor-06 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 (SWID Tag) and the Concise SWID (COSWID) formats in 20 ROLIE are standardized. Additionally, this document discusses 21 requirements and usage of other ROLIE elements in order to best 22 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 September 28, 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 . . . . . . . . . . . . . . . . . . . . . 8 72 6.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 8 73 7. atom:link Extensions . . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8.1. software-descriptor information-type . . . . . . . . . . 11 76 8.2. swd:swname property . . . . . . . . . . . . . . . . . . . 11 77 8.3. swd:swversion property . . . . . . . . . . . . . . . . . 11 78 8.4. swd:swcreator property . . . . . . . . . . . . . . . . . 12 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 81 Appendix A. Schema . . . . . . . . . . . . . . . . . . . . . . . 13 82 Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 identifying, 92 versioning, 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 smaller state space that covers the majority of 99 current use cases for software inventory and record keeping. 101 Some possible use cases for software descriptor information ROLIE 102 Feeds 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 value added information (e.g., software 113 configuration checklist repositories) using identification and 114 characterization information derived from software descriptor 115 information. 117 o End user organizations can consume sources of software descriptor 118 information, and other related software vulnerability and 119 configuration information to provide the data needed to automate 120 software asset, patch, and configuration management practices. 122 o Organizations can use software descriptors to support verification 123 of other entities, thru mechanisms such as RIM or other integrity 124 measurements. 126 This document supports these use cases by describing the content 127 requirements for Feeds and Entries of software descriptor information 128 that are to be published to or retrieved from a ROLIE repository. 130 2. Terminology 132 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 133 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 Several places in this document refer to the "information-type" of a 137 Resource (Entry or Feed). This refers to the "value" attribute of an 138 "atom:category" element whose scheme is 139 "urn:ietf:params:rolie:category:information-type". For an Entry, 140 this value can be inherited from it's containing Feed as per 141 [RFC8322]. 143 3. Background 145 In order to effectively protect and secure an endpoint, it is vital 146 to know what the software load of that endpoint is. This software 147 load, the combination of software, patches and installers on a 148 device, represents the majority of the endpoint's attack surface. 149 Unfortunately, without a reliable and secure package manager, or 150 otherwise a secured and managed operating system, tracking what 151 software is installed on an endpoint is currently not feasible 152 without undue effort. Even attempting to whitelist software is 153 difficult without a way of identifying software and its editions, 154 versions and hotfixes. 156 Software descriptor information, such as that standardized in the ISO 157 19770-2:2015 SWID Tag format, or expressed in proprietary enterprise 158 databases, attempts to provide as much data about this software as 159 possible. 161 Once this information is expressed, it needs to be stored and shared 162 to internal and external parties. ROLIE provides a mechanism to 163 handle this sharing in an automation-friendly way. 165 4. The "software-descriptor" information type 167 When an "atom:category" element has a "scheme" attribute equal to 168 "urn:ietf:params:rolie:category:information-type", the "term" 169 attribute defines the information type of the associated resource. A 170 new information type value: "software-descriptor", is described in 171 this section, and registered in Section 8.1. 173 The "software-descriptor" information type represents any static 174 information that describes a piece of software. This document uses 175 the definition of software provided by [RFC4949]. Note that as per 176 this definition, this information type pertains to static software, 177 that is, code on the disc. The "software-descriptor" information 178 type is intended to provide a category for information that does one 179 or more of the following: 181 identifies and characterizes software: This software identification 182 and characterization information can be provided by a large 183 variety of data, but always describes software in a pre-installed 184 state. 186 provides software installer metadata: This represents information 187 about software used to install other software. This metadata 188 identifies, and characterizes a software installation package or 189 media. 191 describes stateless installation metadata: Information that 192 describes the software post-deployment, such as files that may be 193 deployed during an installation. It is expected that this 194 metadata is produced generally for a given installation, and may 195 not exactly match the actual installed files on a given endpoint. 197 Provided below is a non-exhaustive list of information that may be 198 considered to be of a software-descriptor information type. 200 o Naming information: IDs and names that aid in the identification 201 of a piece of software 203 o Version and patching information: Version numbers, patch 204 identifiers, or other information that 206 o Vendor and source information: Includes where the software was 207 developed or distributed from, as well as where the software 208 installation media may be located. 210 o Payload and file information: information that describes or 211 enumerates the files and folders that make up the piece of 212 software, and information about those files. 214 o Descriptive information and data: Any information that otherwise 215 characterizes a piece of software, such as libraries, runtime 216 environments, target OSes, intended purpose or audience, etc. 218 Note again that this list is not exhaustive, any information that in 219 is the abstract realm of an incident should be classified under this 220 information-type. 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 as 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 for ROLIE consumers to more easily search 315 for 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 field aids ROLIE consumers in 321 search and filtering 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, it's value MUST be equal to the value of the 326 "version" element in the attached SWID Tag. 328 6.2. The Concise SWID format 329 6.2.1. Description 331 The Concise SWID (COSWID) format is an alternative representation of 332 the SWID Tag format using a Concise Binary Object Representation 333 (CBOR) encoding. This provides the format with a reduced size that 334 is more suitable for constrained devices. It provides the same 335 features and attributes as are specified in ISO 19770-2:2015, plus: 337 o a straight forward method to sign and encrypt using COSE, and 339 o additional attributes that provide an improved structure to 340 include file hashes intended to be used as Reference Integrity 341 Measurements (RIM). 343 For more information and the complete specification, refer to the 344 COSWID internet draft [I-D.ietf-sacm-coswid]. 346 6.2.2. Requirements 348 For an Entry to be considered as a "COSWID Tag Entry", it MUST 349 fulfill the following conditions: 351 o The information-type of the Entry is "software-descriptor". For a 352 typical Entry, this is derived from the information-type of the 353 Feed it is contained in. For a standalone Entry, this is provided 354 by an "atom:category" element. 356 o The document linked to by the "href" attribute of the 357 "atom:content" element is a COSWID Tag as per 358 [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/coswid+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 "tag-id" element in the attached 368 COSWID Tag (mapped to integer 0). This allows for ROLIE consumers 369 to more easily search for COSWID tags without needing to download 370 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 value of the "swid-name" element in the 375 attached COSWID Tag (mapped to the integer 1). As above, this 376 field aids ROLIE consumers in searching and filtering 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 value of the 381 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 These relations come in related pairs. The first of each pair is 392 expected to be more common, as they can be determined at the time 393 that the Entry is created. The second of each pair will often need 394 to be added retroactively to an Entry. 396 +----------------------+--------------------------------------------+ 397 | Name | Description | 398 +----------------------+--------------------------------------------+ 399 | ancestor | Links to a software descriptor resource | 400 | | that defines an ancestor of the software | 401 | | being described by this Entry. This is | 402 | | usually a previous version of the | 403 | | software. | 404 | descendent | Links to a software descriptor resource | 405 | | that defines an descendent of the software | 406 | | being described by this Entry. This is | 407 | | usually a more recent version or edition | 408 | | of the software. | 409 | patches | Links to a software descriptor resource | 410 | | that defines the software being patched by | 411 | | this software | 412 | patchedby | Links to a software descriptor resource | 413 | | that defines the patch or update itself | 414 | | that can be or has been applied to this | 415 | | software. | 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 | requiredBy | Links to a software descriptor resource | 421 | | that defines a piece of software that | 422 | | requires this software to function | 423 | | properly. | 424 | installs | Links to a software descriptor resource | 425 | | that defines the software that is | 426 | | installed by this software. | 427 | installedBy | Links to a software descriptor resource | 428 | | that defines the software package that | 429 | | installs this software. | 430 | patchesVulnerability | Links to a vulnerability that this | 431 | | software update fixes. Used for software | 432 | | descriptors that are describing software | 433 | | patches or updates. | 434 | hasVulnerability | Links to a vulnerability description | 435 | | object that details a vulnerability that | 436 | | this software has. | 437 +----------------------+--------------------------------------------+ 439 Table 1: Link Relations for Resource-Oriented Lightweight Indicator 440 Exchange 442 8. IANA Considerations 444 8.1. software-descriptor information-type 446 IANA has added an entry to the "ROLIE Security Resource Information 447 Type Sub-Registry" registry located at 448 . 450 The entry is as follows: 452 name: software-descriptor 454 index: TBD 456 reference: This document, Section 4 458 8.2. swd:swname property 460 IANA has added an entry to the "ROLIE URN Parameters" registry 461 located in . 463 The entry is as follows: 465 name: property:swd:swname 467 Extension IRI: urn:ietf:params:rolie:property:swd:swname 469 Reference: This document, Section 5.1 471 Subregistry: None 473 8.3. swd:swversion property 475 IANA has added an entry to the "ROLIE URN Parameters" registry 476 located in . 478 The entry is as follows: 480 name: property:swd:swversion 482 Extension IRI: urn:ietf:params:rolie:property:swd:swversion 484 Reference: This document, Section 5.1 486 Subregistry: None 488 8.4. swd:swcreator property 490 IANA has added an entry to the "ROLIE URN Parameters" registry 491 located in . 493 The entry is as follows: 495 name: property:swd:swcreator 497 Extension IRI: urn:ietf:params:rolie:property:swd:swcreator 499 Reference: This document, Section 5.1 501 Subregistry: None 503 9. Security Considerations 505 Use of this extension implies dealing with the security implications 506 of both ROLIE and of software descriptors in general. As with any 507 data, care should be taken to verify the trustworthiness and veracity 508 of the descriptor information to the fullest extent possible. 510 Ideally, software descriptors should have been signed by the software 511 manufacturer, or signed by whichever agent processed the source code. 512 Software descriptor documents from these sources are more likely to 513 be accurate than those generated by scraping installed software. 515 These "authoritative" sources of software descriptor content should 516 consider additional security for their ROLIE repository beyond the 517 typical recommendations, as the central importance of the repository 518 is likely to make it a target. 520 Version information is often represented differently across 521 manufacturers and even across product releases. If using software 522 version information for low fault tolerance comparisons and searches, 523 care should be taken that the correct version scheme is being 524 utilized. 526 10. Normative References 528 [I-D.ietf-sacm-coswid] 529 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 530 Waltermire, "Concise Software Identifiers", draft-ietf- 531 sacm-coswid-08 (work in progress), November 2018. 533 [NISTIR8060] 534 Waltermire, D., Cheikes, B., Feldman, L., and G. Witte, 535 "Guidelines for the Creation of Interoperable Software 536 Identification (SWID) Tags", NISTIR 8060, April 2016, 537 . 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, 541 DOI 10.17487/RFC2119, March 1997, 542 . 544 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 545 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 546 . 548 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 549 Object Description Exchange Format", RFC 5070, 550 DOI 10.17487/RFC5070, December 2007, 551 . 553 [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- 554 Oriented Lightweight Information Exchange (ROLIE)", 555 RFC 8322, DOI 10.17487/RFC8322, February 2018, 556 . 558 [SWID] "Information technology - Software asset management - Part 559 2: Software identification tag", ISO/IEC 19770-2:2015, 560 October 2015. 562 Appendix A. Schema 564 This document does not require any schema extensions. 566 Appendix B. Examples of Use 568 Use of this extension in a ROLIE repository will not typically change 569 that repository's operation. As such, the general examples provided 570 by the ROLIE core document would serve as examples. Provided below 571 is a sample software descriptor ROLIE entry: 573 574 576 dd786dba-88e6-440b-9158-b8fae67ef67c 577 Sample Software Descriptor 578 2015-08-04T18:13:51.0Z 579 2015-08-05T18:13:51.0Z 580 A descriptor for a piece of software published by this 581 organization. 582 583 584 585 587 590 592 594 596 Authors' Addresses 598 Stephen Banghart 599 National Institute of Standards and Technology 600 100 Bureau Drive 601 Gaithersburg, Maryland 20877 602 USA 604 Email: stephen.banghart@nist.gov 606 David Waltermire 607 National Institute of Standards and Technology 608 100 Bureau Drive 609 Gaithersburg, Maryland 20877 610 USA 612 Email: david.waltermire@nist.gov