idnits 2.17.1 draft-banghart-sacm-rolie-softwaredescriptor-00.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 (October 31, 2016) is 2705 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: May 4, 2017 October 31, 2016 7 Definition of the ROLIE Software Descriptor Extension 8 draft-banghart-sacm-rolie-softwaredescriptor-00 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 May 4, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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 . . . . . . . 3 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 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7.1. incident information-type . . . . . . . . . . . . . . . . 6 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 71 Appendix A. Schema . . . . . . . . . . . . . . . . . . . . . . . 7 72 Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 This document defines an extension to the Resource-Oriented 78 Lightweight Information Exchange (ROLIE) protocol to support the 79 publication of software descriptor information. Software descriptor 80 information is information that characterizes: 82 an installable software package, or 84 information about static software components that may be installed 85 by a software package or patch. 87 Software descriptor information includes identifying, versioning, 88 software creation and publication, and file artifact information. 89 Software descriptor information provides data about what might be 90 installed, but doesn't describe where or how a specific software 91 installation is installed, configured, or executed. 93 Software descriptor information can be used in the following ways: 95 Software providers can publish software descriptor information so 96 that software researchers and users of software can understand the 97 collection of software produced by a that software provider. 99 Organizations can aggregate and syndicate collections of software 100 descriptor information provided by multiple software providers to 101 support software-related analysis processes (e.g., vulnerability 102 analysis) and value added information (e.g., software 103 configuration checklist repositories) using identification and 104 characterization information derived from software descriptor 105 information. 107 End user organizations can consume sources of software descriptor 108 information, and other related software vulnerability and 109 configuration information to provide the data needed to automate 110 software asset, patch, and configuration management practices. 112 This document supports these use cases by describing the content 113 requirements for Collections of software descriptor information that 114 are to be published to or retrieved from a ROLIE repository. This 115 document also discusses requirements around the use of link 116 relationships and describing the data model formats used in a ROLIE 117 Entry describing a software descriptor information resource. 119 TODO: describe how this approach differs from the SWIMA approach. 121 2. Terminology 123 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 124 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 Definitions for some of the common computer security-related 128 terminology used in this document can be found in Section 2 of 129 [RFC5070]. 131 3. New information-types 133 This document defines the following information type: 135 3.1. The "software-descriptor" information type 137 The "software-descriptor" information type represents any information 138 that describes a piece of software. This document uses the 139 definition of software provided by [RFC4949]. Note that as per this 140 definition, this information type pertains to static software, that 141 is, code on the disc. The software-descriptor information type is 142 intended to provide a category for information that does one or more 143 of the following: 145 identifies and characterizes software This software identification 146 and characterization information can be provided by a large 147 variety of data, but always describes software in a pre-installed 148 state. 150 provides software installer metadata This represents information 151 about software used to install other software. This metadata 152 identifies, and characterizes a software installation package or 153 media. 155 describes stateless installation metadata Information that describes 156 the software post-deployment, such as files that may be deployed 157 during an installation. It is expected that this metadata is 158 produced generally for a given installation, and may not exactly 159 match the actual installed files on a given endpoint. 161 Provided below is a non-exhaustive list of information that may be 162 considered to be of a software-descriptor information type. 164 o Naming information: IDs and names that aid in the identification 165 of a piece of software 167 o Version and patching information: Version numbers, patch 168 identifiers, or other information that 170 o Vendor and source information: Includes where the software was 171 developed or distributed from, as well as where the software 172 installation media may be located. 174 o Payload and file information: information that describes or 175 enumerates the files and folders that make up the piece of 176 software, and information about those files. 178 o Descriptive information and data: Any information that otherwise 179 characterizes a piece of software, such as libraries, runtime 180 environments, target OSes, intended purpose or audience, etc. 182 Note again that this list is not exhaustive, any information that in 183 is the abstract realm of an incident should be classified under this 184 information-type. 186 This information type does not include descriptions of running 187 software, or state and configuration information that is associated 188 with a software installation. 190 4. Usage of CSIRT Information Types in the Atom Publishing Protocol 192 This document does not specify any additional requirements for use of 193 the Atom Publishing Protocol. 195 5. Usage of the software-descriptor Information Type in the atom:feed 196 element 198 This document does not specify any additional requirements for use of 199 the atom:feed element. 201 6. Usage of the software-descriptor Information Type in an atom:entry 203 This document specifies the following requirements for use of the 204 software-descriptor information type with regards to Atom Entries. 206 6.1. Use of the atom:link element 208 This section defines the requirements around the use of atom:links in 209 Entries. Each relationship should be named,described, and given a 210 requirement level. TODO 212 +--------------------+--------------------------------+-------------+ 213 | Name | Description | Conformance | 214 +--------------------+--------------------------------+-------------+ 215 | ancestor | Links to a software descriptor | MAY | 216 | | resource that defines an | | 217 | | ancestor of the software being | | 218 | | described by this Entry. | | 219 | patches | Links to a software descriptor | MAY | 220 | | resource that defines the | | 221 | | software being patched by this | | 222 | | software | | 223 | requires | Links to a software descriptor | MAY | 224 | | resource that defines a piece | | 225 | | of software required for this | | 226 | | software to function properly. | | 227 | installs | Links to a software descriptor | MAY | 228 | | resource that defines the | | 229 | | software being installed by | | 230 | | this software. | | 231 | installationrecord | Provides a link to a resource | MAY | 232 | | that describes an installation | | 233 | | of this software. | | 234 +--------------------+--------------------------------+-------------+ 236 Table 1: Link Relations for Resource-Oriented Lightweight Indicator 237 Exchange 239 6.2. Use of the rolie:format element 241 New supported data formats would be described here alongside any 242 other rolie:format requirements. 244 6.2.1. The ISO SWID 2016 format 246 The ISO SWID Tag 2016 format is a software descriptor and software 247 record data format. It provides several tags: primary, which 248 provides descriptive and naming information about software, patch, 249 which describes non-standalone software meant to patch existing 250 software, and corpus, which describes the software installation media 251 that installs a given piece of software. 253 For a more complete overview as well as normative requirements, refer 254 to TODO(ref?):ISO/IEC 19770-2 256 7. IANA Considerations 258 7.1. incident information-type 260 IANA has added an entry to the "ROLIE Security Resource Information 261 Type Sub-Registry" registry located at 262 . 264 The entry is as follows: 266 name: software-descriptor 268 index: TBD 270 reference: This document, Section 3.1 272 8. Security Considerations 274 9. Normative References 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, 278 DOI 10.17487/RFC2119, March 1997, 279 . 281 [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 282 Object Description Exchange Format", RFC 5070, 283 DOI 10.17487/RFC5070, December 2007, 284 . 286 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 287 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 288 . 290 Appendix A. Schema 292 This document does not require any schema extensions. 294 Appendix B. Examples of Use 296 TODO: Add examples of Use 298 Authors' Addresses 300 David Waltermire 301 National Institute of Standards and Technology 302 100 Bureau Drive 303 Gaithersburg, Maryland 20877 304 USA 306 Email: david.waltermire@nist.gov 308 Stephen Banghart 309 National Institute of Standards and Technology 310 100 Bureau Drive 311 Gaithersburg, Maryland 20877 312 USA 314 Email: stephen.banghart@nist.gov