idnits 2.17.1 draft-banghart-sacm-rolie-softwaredescriptor-01.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 : ---------------------------------------------------------------------------- No issues found here. 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 (May 3, 2017) is 2548 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 5070 (Obsoleted by RFC 7970) ** Downref: Normative reference to an Informational RFC: RFC 4949 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM Working Group D. Waltermire 3 Internet-Draft S. Banghart 4 Intended status: InformationalNational Institute of Standards and Techno 5 Expires: November 4, 2017 May 3, 2017 7 Definition of the ROLIE Software Descriptor Extension 8 draft-banghart-sacm-rolie-softwaredescriptor-01 10 Abstract 12 This document extends the Resource-Oriented Lightweight Information 13 Exchange (ROLIE) core to add the information type category and 14 related requirements needed to support Software Record and Software 15 Inventory use cases. The 'software-descriptor' information type is 16 defined as a ROLIE extension. Additional supporting requirements are 17 also defined that describe the use of specific formats and link 18 relations pertaining to the new information type. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 4, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. New information-types . . . . . . . . . . . . . . . . . . . . 3 57 3.1. The "software-descriptor" information type . . . . . . . 4 58 4. Usage of CSIRT Information Types in the Atom 59 Publishing Protocol . . . . . . . . . . . . . . . . . . . . . 5 60 5. Usage of the software-descriptor Information Type in the 61 atom:feed element . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Usage of the software-descriptor Information Type in an 63 atom:entry . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.1. Use of the atom:link element . . . . . . . . . . . . . . 5 65 6.2. Use of the rolie:format element . . . . . . . . . . . . . 6 66 6.2.1. The ISO SWID 2016 format . . . . . . . . . . . . . . 6 67 6.2.2. The Concise SWID format . . . . . . . . . . . . . . . 7 68 6.3. Use of the rolie:property element . . . . . . . . . . . . 7 69 6.3.1. urn:ietf:params:rolie:property:swd:id . . . . . . . . 7 70 6.3.2. urn:ietf:params:rolie:property:swd:swname . . . . . . 7 71 6.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 7 72 6.4.1. incident information-type . . . . . . . . . . . . . . 7 73 6.4.2. swd:id property . . . . . . . . . . . . . . . . . . . 8 74 6.4.3. swd:swname property . . . . . . . . . . . . . . . . . 8 75 6.5. Security Considerations . . . . . . . . . . . . . . . . . 8 76 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 77 Appendix A. Schema . . . . . . . . . . . . . . . . . . . . . . . 9 78 Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 This document defines an extension to the Resource-Oriented 84 Lightweight Information Exchange (ROLIE) protocol to support the 85 publication of software descriptor information. Software descriptor 86 information is information that characterizes: 88 an installable software package, or 90 information about static software components that may be installed 91 by a software package or patch. 93 Software descriptor information includes identifying, versioning, 94 software creation and publication, and file artifact information. 95 Software descriptor information provides data about what might be 96 installed, but doesn't describe where or how a specific software 97 installation is installed, configured, or executed. 99 Some possible use cases for Software descriptor information include: 101 Software providers can publish software descriptor information so 102 that software researchers and users of software can understand the 103 collection of software produced by a that software provider. 105 Organizations can aggregate and syndicate collections of software 106 descriptor information provided by multiple software providers to 107 support software-related analysis processes (e.g., vulnerability 108 analysis) and value added information (e.g., software 109 configuration checklist repositories) using identification and 110 characterization information derived from software descriptor 111 information. 113 End user organizations can consume sources of software descriptor 114 information, and other related software vulnerability and 115 configuration information to provide the data needed to automate 116 software asset, patch, and configuration management practices. 118 Organizations can use software descriptors to support verification 119 of other entities, thru mechanisms such as RIM or other integrity 120 measurements. 122 This document supports these use cases by describing the content 123 requirements for Collections of software descriptor information that 124 are to be published to or retrieved from a ROLIE repository. This 125 document also discusses requirements around the use of link 126 relationships and describing the data model formats used in a ROLIE 127 Entry describing a software descriptor information resource. 129 2. Terminology 131 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 132 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 Definitions for some of the common computer security-related 136 terminology used in this document can be found in Section 2 of 137 [RFC5070]. 139 3. New information-types 141 This document defines the following information type: 143 3.1. The "software-descriptor" information type 145 The "software-descriptor" information type represents any information 146 that describes a piece of software. This document uses the 147 definition of software provided by [RFC4949]. Note that as per this 148 definition, this information type pertains to static software, that 149 is, code on the disc. The software-descriptor information type is 150 intended to provide a category for information that does one or more 151 of the following: 153 identifies and characterizes software This software identification 154 and characterization information can be provided by a large 155 variety of data, but always describes software in a pre-installed 156 state. 158 provides software installer metadata This represents information 159 about software used to install other software. This metadata 160 identifies, and characterizes a software installation package or 161 media. 163 describes stateless installation metadata Information that describes 164 the software post-deployment, such as files that may be deployed 165 during an installation. It is expected that this metadata is 166 produced generally for a given installation, and may not exactly 167 match the actual installed files on a given endpoint. 169 Provided below is a non-exhaustive list of information that may be 170 considered to be of a software-descriptor information type. 172 o Naming information: IDs and names that aid in the identification 173 of a piece of software 175 o Version and patching information: Version numbers, patch 176 identifiers, or other information that 178 o Vendor and source information: Includes where the software was 179 developed or distributed from, as well as where the software 180 installation media may be located. 182 o Payload and file information: information that describes or 183 enumerates the files and folders that make up the piece of 184 software, and information about those files. 186 o Descriptive information and data: Any information that otherwise 187 characterizes a piece of software, such as libraries, runtime 188 environments, target OSes, intended purpose or audience, etc. 190 Note again that this list is not exhaustive, any information that in 191 is the abstract realm of an incident should be classified under this 192 information-type. 194 This information type does not include descriptions of running 195 software, or state and configuration information that is associated 196 with a software installation. 198 4. Usage of CSIRT Information Types in the Atom Publishing Protocol 200 This document does not specify any additional requirements for use of 201 the Atom Publishing Protocol. 203 5. Usage of the software-descriptor Information Type in the atom:feed 204 element 206 This document does not specify any additional requirements for use of 207 the atom:feed element. 209 6. Usage of the software-descriptor Information Type in an atom:entry 211 This document specifies the following requirements for use of the 212 software-descriptor information type with regards to Atom Entries. 214 6.1. Use of the atom:link element 216 This section defines the requirements around the use of atom:links in 217 Entries. Each relationship should be named,described, and given a 218 requirement level. 220 +--------------------+--------------------------------+-------------+ 221 | Name | Description | Conformance | 222 +--------------------+--------------------------------+-------------+ 223 | ancestor | Links to a software descriptor | MAY | 224 | | resource that defines an | | 225 | | ancestor of the software being | | 226 | | described by this Entry. | | 227 | patches | Links to a software descriptor | MAY | 228 | | resource that defines the | | 229 | | software being patched by this | | 230 | | software | | 231 | requires | Links to a software descriptor | MAY | 232 | | resource that defines a piece | | 233 | | of software required for this | | 234 | | software to function properly. | | 235 | installs | Links to a software descriptor | MAY | 236 | | resource that defines the | | 237 | | software being installed by | | 238 | | this software. | | 239 | installationrecord | Provides a link to a resource | MAY | 240 | | that describes an installation | | 241 | | of this software. | | 242 +--------------------+--------------------------------+-------------+ 244 Table 1: Link Relations for Resource-Oriented Lightweight Indicator 245 Exchange 247 6.2. Use of the rolie:format element 249 This document does not contain any additional requirements for the 250 rolie:format element, the formats that follow are provided as 251 examples of formats that describe the software descriptor information 252 type. 254 6.2.1. The ISO SWID 2016 format 256 The ISO SWID Tag 2016 format is a software descriptor and software 257 record data format. It provides several tags: primary, which 258 provides descriptive and naming information about software, patch, 259 which describes non-standalone software meant to patch existing 260 software, and corpus, which describes the software installation media 261 that installs a given piece of software. 263 For a more complete overview as well as normative requirements, refer 264 to TODO(ref?):ISO/IEC 19770-2 266 6.2.2. The Concise SWID format 268 The Consise SWID format is an alternative representation of the ISO 269 SWID Tag 2016 format using a CBOR encoding defined by a CDDL 270 specification. It provides the same features and attributes as are 271 specified in ISO 19770-2, plus: 273 o a straight forward method to sign and encrypt SWID Tags using 274 COSE, and 276 o additional attributes that provide an improved structure to 277 include file hashes intended to be used as Reference Integrity 278 Measurements (RIM). 280 6.3. Use of the rolie:property element 282 This document registers new valid rolie:property names as follows: 284 6.3.1. urn:ietf:params:rolie:property:swd:id 286 This property provides an exposure point for an identification field 287 from the associated software descriptor. The value of this property 288 SHOULD be uniquely identifying information generated from the 289 software descriptor linked to by the entry's atom:content element. 290 swd:id property values SHOULD have a one-to-one mapping to individual 291 pieces of SWD content. 293 6.3.2. urn:ietf:params:rolie:property:swd:swname 295 This property provides an exposure point for the plain text name of 296 the software being described. Due to the great variance in naming 297 schemes, this property should be considered informative. 299 6.4. IANA Considerations 301 6.4.1. incident information-type 303 IANA has added an entry to the "ROLIE Security Resource Information 304 Type Sub-Registry" registry located at 305 . 307 The entry is as follows: 309 name: software-descriptor 311 index: TBD 313 reference: This document, Section 3.1 315 6.4.2. swd:id property 317 IANA has added an entry to the "ROLIE URN Parameters" registry 318 located in . 320 The entry is as follows: 322 name: property:swd:id 324 Extension IRI: urn:ietf:params:rolie:property:swd:id 326 Reference: This document, Section 6.3.1 328 Subregistry: None 330 6.4.3. swd:swname property 332 IANA has added an entry to the "ROLIE URN Parameters" registry 333 located in . 335 The entry is as follows: 337 name: property:swd:swname 339 Extension IRI: urn:ietf:params:rolie:property:swd:swname 341 Reference: This document, Section 6.3.2 343 Subregistry: None 345 6.5. Security Considerations 347 Use of this extension implies dealing with the security implications 348 of both ROLIE and of software descriptors in general. As with any 349 SWD information, care should be taken to verify the trustworthiness 350 and veracity of the descriptor information to the fullest extent 351 possible. 353 Ideally, software descriptors should have been signed by the software 354 manufacturer, or signed by whichever agent processed the source code. 355 SWD documents from these sources are more likely to be accurate than 356 those generated by scraping installed software. 358 These "authoritative" sources of SWD content should consider 359 additional security for their ROLIE repository beyond the typical 360 recommendations, as the central importance of the repository is 361 likely to make it a target. 363 Version information is often represented differently across 364 manufacturers and even across product releases. If using SWD version 365 information for low fault tolerance comparisons and searches, care 366 should be taken that the correct version scheme is being utilized. 368 7. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, 372 DOI 10.17487/RFC2119, March 1997, 373 . 375 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 376 Object Description Exchange Format", RFC 5070, 377 DOI 10.17487/RFC5070, December 2007, 378 . 380 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 381 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 382 . 384 Appendix A. Schema 386 This document does not require any schema extensions. 388 Appendix B. Examples of Use 390 Use of this extension in a ROLIE repository will not typically change 391 that repo's operation. As such, the general examples provided by the 392 ROLIE core document would serve as examples. Provided below is a 393 sample SWD ROLIE entry: 395 396 398 dd786dba-88e6-440b-9158-b8fae67ef67c 399 Sample Software Descriptor 400 2015-08-04T18:13:51.0Z 401 2015-08-05T18:13:51.0Z 402 A descriptor for a piece of software published by this 403 organization. 404 405 408 409 411 413 Authors' Addresses 415 David Waltermire 416 National Institute of Standards and Technology 417 100 Bureau Drive 418 Gaithersburg, Maryland 20877 419 USA 421 Email: david.waltermire@nist.gov 423 Stephen Banghart 424 National Institute of Standards and Technology 425 100 Bureau Drive 426 Gaithersburg, Maryland 20877 427 USA 429 Email: stephen.banghart@nist.gov