idnits 2.17.1 draft-ietf-sacm-coswid-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 09, 2017) is 2657 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 7049 (Obsoleted by RFC 8949) -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID' == Outdated reference: A later version (-04) exists of draft-birkholz-tuda-03 == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-09 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SACM Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Standards Track J. Fitzgerald-McKay 5 Expires: July 13, 2017 Department of Defense 6 C. Schmidt 7 The MITRE Corporation 8 D. Waltermire 9 NIST 10 January 09, 2017 12 Concise Software Identifiers 13 draft-ietf-sacm-coswid-00 15 Abstract 17 This document defines a concise representation of ISO 19770-2:2015 18 Software Identifiers (SWID tags) that is interoperable with the XML 19 schema definition of ISO 19770-2:2015. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 13, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 57 2. Concise SWID data definition . . . . . . . . . . . . . . . . 4 58 3. Encoding hashes for Concise SWID tags . . . . . . . . . . . . 8 59 4. COSE signatures for Concise SWID tags . . . . . . . . . . . . 8 60 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 63 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 67 10.2. Informative References . . . . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 SWID tags have several use-applications including but not limited to: 74 o Software Inventory Management, a part of the Software Asset 75 Management [SAM] process, which requires an accurate list of 76 discernible deployed software instances. 78 o Vulnerability Assessment, which requires a semantic link between 79 standardized vulnerability descriptions and IT-assets [X.1520]. 81 o Remote Attestation, which requires a link between golden (well- 82 known) measurements and software instances [I-D-birkholz-tuda]. 84 SWID tags, as defined in ISO-19770-2:2015 [SWID], provide a 85 standardized format for a record that identifies and describes a 86 specific release of a software product. Different software products, 87 and even different releases of a particular software product, each 88 have a different SWID tag record associated with them. In addition 89 to defining the format of these records, ISO-19770-2:2015 defines 90 requirements concerning the SWID tag lifecycle. Specifically, when a 91 software product is installed on an endpoint, that product's SWID tag 92 is also installed. Likewise, when the product is uninstalled or 93 replaced, the SWID tag is deleted or replaced, as appropriate. As a 94 result, ISO-19770-2:2015 describes a system wherein there is a 95 correspondence between the set of installed software products on an 96 endpoint, and the presence on that endpoint of the SWID tags 97 corresponding to those products. 99 SWID tags are meant to be flexible and able to express a broad set of 100 metadata about a software product. Moreover, there are multiple 101 types of SWID tags, each providing different types of information. 102 For example, a "corpus tag" is used to describe an application's 103 installation image on an installation media, while a "patch tag" is 104 meant to describe a patch that modifies some other application. 105 While there are very few required fields in SWID tags, there are many 106 optional fields that support different uses of these different types 107 of tags. While a SWID tag that consisted only of required fields 108 could be a few hundred bytes in size, a tag containing many of the 109 optional fields could be many orders of magnitude larger. 111 This document defines a more concise representation of SWID tags in 112 the Concise Binary Object Representation (CBOR) [RFC7049]. This is 113 described via the CBOR Data Definition Language (CDDL) 114 [I-D.greevenbosch-appsawg-cbor-cddl]. The resulting Concise SWID 115 data definition is interoperable with the XML schema definition of 116 ISO-19770-2:2015 [SWID]. The vocabulary, i.e., the CDDL names of the 117 types and members used in the Concise SWID data definition, is mapped 118 to more concise labels represented as small integers. The names used 119 in the CDDL and the mapping to the CBOR representation using integer 120 labels is based on the vocabulary of the XML attribute and element 121 names defined in ISO-19770-2:2015. 123 Real-world instances of SWID tags can be fairly large, and the 124 communication of SWID tags in use-applications such as those 125 described earlier can cause a large amount of data to be transported. 126 This can be larger than acceptable for constrained devices and 127 networks. Concise SWID tags significantly reduce the amount of data 128 transported as compared to a typical SWID tag. This reduction is 129 enable through the use of CBOR, which maps human-readable labels of 130 that content to more concise integer labels (indices). This allows 131 SWID tags to be part of an enterprise security solution for a wider 132 range of endpoints and environments. 134 1.1. Requirements notation 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in RFC 139 2119, BCP 14 [RFC2119]. 141 2. Concise SWID data definition 143 The following is a CDDL representation of the ISO-19770-2:2015 [SWID] 144 XML schema definition of SWID tags. This representation includes all 145 SWID tag fields and thus supports all SWID tag use cases. The 146 CamelCase notation used in the XML schema definition is changed to 147 hyphen-separated notation (e.g. ResourceCollection is named 148 resource-collection in the Concise SWID data definition). The human- 149 readable names of members are mapped to integer indices via a block 150 of rules at the bottom of the Concise SWID data definition. The 48 151 character strings of the SWID vocabulary that would have to be stored 152 or transported in full if using the original vocabulary are replaced. 154 concise-software-identity = { 155 global-attributes, 156 ? entity-entry, 157 ? evidence-entry, 158 ? link-entry, 159 ? software-meta-entry, 160 ? payload-entry, 161 ? any-element-entry, 162 ? corpus, 163 ? patch, 164 ? media, 165 swid-name, 166 ? supplemental, 167 tag-id, 168 ? tag-version, 169 ? version, 170 ? version-scheme, 171 } 173 NMTOKEN = text 174 NMTOKENS = text 176 date-time = time 177 any-uri = text 178 label = text / int 180 any-attribute = ( 181 label => text / int / [ 2* text ] / [ 2* int ] 182 ) 184 any-element-map = { 185 global-attributes, 186 * label => any-element-map / [ * any-element-map ], 187 } 188 global-attributes = ( 189 ? lang, 190 * any-attribute, 191 ) 193 resource-collection = ( 194 ? directory-entry, 195 ? file-entry, 196 ? process-entry, 197 ? resource-entry 198 ) 200 file = { 201 filesystem-item, 202 ? size, 203 ? version, 204 ? file-hash, 205 } 207 filesystem-item = ( 208 global-attributes, 209 ? key, 210 ? location, 211 fs-name, 212 ? root, 213 ) 215 directory = { 216 filesystem-item, 217 path-elements, 218 } 220 process = { 221 global-attributes, 222 process-name, 223 ? pid, 224 } 226 resource = { 227 global-attributes, 228 type, 229 } 231 entity = { 232 global-attributes, 233 meta-elements, 234 entity-name, 235 ? reg-id, 236 role, 237 ? thumbprint, 238 } 240 evidence = { 241 global-attributes, 242 resource-collection, 243 ? date, 244 ? device-id, 245 } 247 link = { 248 global-attributes, 249 ? artifact, 250 href, 251 ? media, 252 ? ownership, 253 rel, 254 ? type, 255 ? use, 256 } 258 software-meta = { 259 global-attributes, 260 ? activation-status, 261 ? channel-type, 262 ? colloquial-version, 263 ? description, 264 ? edition, 265 ? entitlement-data-required, 266 ? entitlement-key, 267 ? generator, 268 ? persistent-id, 269 ? product, 270 ? product-family, 271 ? revision, 272 ? summary, 273 ? unspsc-code, 274 ? unspsc-version, 275 } 277 payload = { 278 global-attributes, 279 resource-collection, 280 } 282 tag-id = (0: text) 283 swid-name = (1: text) 284 entity-entry = (2: entity / [ * entity ]) 285 evidence-entry = (3: evidence / [ * evidence ]) 286 link-entry = (4: link / [ * link ]) 287 software-meta-entry = (5: software-meta / [ * software-meta ]) 288 payload-entry = (6: payload / [ * payload ]) 289 any-element-entry = (7: any-element-map / [ * any-element-map ]) 290 corpus = (8: bool) 291 patch = (9: bool) 292 media = (10: text) 293 supplemental = (11: bool) 294 tag-version = (12: integer) 295 version = (13: text) 296 version-scheme = (14: NMTOKEN) 297 lang = (15: text) 298 directory-entry = (16: directory / [ * directory ]) 299 file-entry = (17: file / [ * file ]) 300 process-entry = (18: process / [ * process ]) 301 resource-entry = (19: resource / [ * resource ]) 302 size = (20: integer) 303 key = (21: bool) 304 location = (22: text) 305 fs-name = (23: text) 306 root = (24: text) 307 path-elements = (25: { ? directory-entry, 308 ? file-entry, 309 } 310 ) 311 process-name = (26: text) 312 pid = (27: integer) 313 type = (28: text) 314 meta-elements = (29: any-element-map / [ * any-element-map ]) 315 entity-name = (30: text) 316 reg-id = (31: any-uri) 317 role = (32: NMTOKENS) 318 thumbprint = (33: text) 319 date = (34: date-time) 320 device-id = (35: text) 321 artifact = (36: text) 322 href = (37: any-uri) 323 ownership = (38: "shared" / "private" / "abandon") 324 rel = (39: NMTOKEN) 325 use = (40: "optional" / "required" / "recommended") 326 activation-status = (41: text) 327 channel-type = (42: text) 328 colloquial-version = (43: text) 329 description = (44: text) 330 edition = (45: text) 331 entitlement-data-required = (46: bool) 332 entitlement-key = (47: text) 333 generator = (48: text) 334 persistent-id = (49: text) 335 product = (50: text) 336 product-family = (51: text) 337 revision = (52: text) 338 summary = (53: text) 339 unspsc-code = (54: text) 340 unspsc-version = (55: text) 341 file-hash = (56: [ hash-alg-id: int, 342 hash-value: bstr, 343 ] 344 ) 346 3. Encoding hashes for Concise SWID tags 348 Concise SWID add explicit support for the representation of file- 349 hashes using algorithms that are registered at the Named Information 350 Hash Algorithm Registry via the file-hash item (label 56). The 351 number used as a value for hash-alg-id refers the ID in the Named 352 Information Hash Algorithm table. 354 4. COSE signatures for Concise SWID tags 356 SWID tags, as defined in the ISO-19770-2:2015 XML schema, can include 357 cryptographic signatures to protect the integrity of the SWID tag. 358 In general, tags are signed by the tag creator (typically, although 359 not exclusively, the vendor of the software product that the SWID tag 360 identifies). Cryptographic signatures can make any modification of 361 the tag detectable, which is especially important if the integrity of 362 the tag is important, such as when the tag is providing golden 363 measurements for files. 365 The ISO-19770-2:2015 XML schema uses XML DSIG to support 366 cryptographic signatures. Concise SWID tags require a different 367 signature scheme than this. COSE (CBOR Encoded Message Syntax) 368 provides the required mechanism [I-D.ietf-cose-msg]. Concise SWID 369 can be wrapped in a COSE Single Signer Data Object (cose-sign1) that 370 contains a single signature. The following CDDL defines a more 371 restrictive subset of header attributes allowed by COSE tailored to 372 suit the requirements of Concise SWID. 374 signed-software-identity = #6.997(COSE-Sign1-coswid) ; see TBS7 in current COSE I-D 376 label = int / tstr ; see COSE I-D 1.4. 377 values = any ; see COSE I-D 1.4. 379 unprotected-signed-coswid-header = { 380 1 => int, ; algorithm identifier 381 3 => "application/coswid", ; request for CoAP IANA registry to become an int 382 * label => values, 383 } 385 protected-signed-coswid-header = { 386 4 => bstr, ; key identifier 387 * label => values, 388 } 390 COSE-Sign1-coswid = [ 391 protected: bstr .cbor protected-signed-coswid-header, 392 unprotected: unprotected-signed-coswid-header, 393 payload: bstr .cbor concise-software-identity, 394 signature: bstr, 395 ] 397 5. IANA considerations 399 This document will include requests to IANA: 401 o Integer indices for SWID content attributes and information 402 elements. 404 o Content-Type for CoAP to be used in COSE. 406 6. Security Considerations 408 SWID tags contain public information about software products and, as 409 such, do not need to be protected against disclosure on an endpoint. 410 Similarly, SWID tags are intended to be easily discoverable by 411 applications and users on an endpoint in order to make it easy to 412 identify and collect all of an endpoint's SWID tags. As such, any 413 security considerations regarding SWID tags focus on the application 414 of SWID tags to address security challenges, and the possible 415 disclosure of the results of those applications. 417 A signed SWID tag whose signature is intact can be relied upon to be 418 unchanged since it was signed. If the SWID tag was created by the 419 software author, this generally means that it has undergone no change 420 since the software application with which the tag is associated was 421 installed. By implication, this means that the signed tag reflects 422 the software author's understanding of the details of that software 423 product. This can be useful assurance when the information in the 424 tag needs to be trusted, such as when the tag is being used to convey 425 golden measurements. By contrast, the data contained in unsigned 426 tags cannot be trusted to be unmodified. 428 SWID tags are designed to be easily added and removed from an 429 endpoint along with the installation or removal of software products. 430 On endpoints where addition or removal of software products is 431 tightly controlled, the addition or removal of SWID tags can be 432 similarly controlled. On more open systems, where many users can 433 manage the software inventory, SWID tags may be easier to add or 434 remove. On such systems, it may be possible to add or remove SWID 435 tags in a way that does not reflect the actual presence or absence of 436 corresponding software products. Similarly, not all software 437 products automatically install SWID tags, so products may be present 438 on an endpoint without providing a corresponding SWID tag. As such, 439 any collection of SWID tags cannot automatically be assumed to 440 represent either a complete or fully accurate representation of the 441 software inventory of the endpoint. However, especially on devices 442 that more strictly control the ability to add or remove applications, 443 SWID tags are an easy way to provide an preliminary understanding of 444 that endpoint's software inventory. 446 Any report of an endpoint's SWID tag collection provides information 447 about the software inventory of that endpoint. If such a report is 448 exposed to an attacker, this can tell them which software products 449 and versions thereof are present on the endpoint. By examining this 450 list, the attacker might learn of the presence of applications that 451 are vulnerable to certain types of attacks. As noted earlier, SWID 452 tags are designed to be easily discoverable by an endpoint, but this 453 does not present a significant risk since an attacker would already 454 need to have access to the endpoint to view that information. 455 However, when the endpoint transmits its software inventory to 456 another party, or that inventory is stored on a server for later 457 analysis, this can potentially expose this information to attackers 458 who do not yet have access to the endpoint. As such, it is important 459 to protect the confidentiality of SWID tag information that has been 460 collected from an endpoint, not because those tags individually 461 contain sensitive information, but because the collection of SWID 462 tags and their association with an endpoint reveals information about 463 that endpoint's attack surface. 465 Finally, both the ISO-19770-2:2015 XML schema definition and the 466 Concise SWID data definition allow for the construction of "infinite" 467 SWID tags or SWID tags that contain malicious content with the intend 468 if creating non-deterministic states during validation or processing 469 of SWID tags. While software product vendors are unlikely to do 470 this, SWID tags can be created by any party and the SWID tags 471 collected from an endpoint could contain a mixture of vendor and non- 472 vendor created tags. For this reason, tools that consume SWID tags 473 ought to treat the tag contents as potentially malicious and should 474 employ input sanitizing on the tags they ingest. 476 7. Acknowledgements 478 8. Change Log 480 Changes since adopted as a WG I-D -00: 482 o Removed redundant any-attributes originating from the ISO- 483 19770-2:2015 XML schema definition 485 o Fixed broken multi-map members 487 o Introduced a more restrictive item (any-element-map) to represent 488 custom maps, increased restriction on types for the any-attribute, 489 accordingly 491 o Fixed X.1520 reference 493 o Minor type changes of some attributes (e.g. NMTOKENS) 495 o Added semantic differentiation of various name types (e,g. fs- 496 name) 498 Changes from version 00 to version 01: 500 o Ambiguity between evidence and payload eliminated by introducing 501 explicit members (while still allowing for "empty" swid tags) 503 o Added a relatively restrictive COSE envelope using cose_sign1 to 504 define signed coswids (single signer only, at the moment) 506 o Added a defintion how to encode hashes that can be stored in the 507 any-member using existing IANA tables to reference hash-algorithms 509 First version -00 511 9. Contributors 512 10. References 514 10.1. Normative References 516 [I-D.ietf-cose-msg] 517 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 518 draft-ietf-cose-msg-24 (work in progress), November 2016. 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, 522 DOI 10.17487/RFC2119, March 1997, 523 . 525 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 526 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 527 October 2013, . 529 [SAM] "Information technology - Software asset management - Part 530 5: Overview and vocabulary", ISO/IEC 19770-5:2013, 531 November 2013. 533 [SWID] "Information technology - Software asset management - Part 534 2: Software identification tag'", ISO/IEC 19770-2:2015, 535 October 2015. 537 [X.1520] "Recommendation ITU-T X.1520 (2014), Common 538 vulnerabilities and exposures", April 2011. 540 10.2. Informative References 542 [I-D-birkholz-tuda] 543 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 544 "Time-Based Uni-Directional Attestation", draft-birkholz- 545 tuda-03 (work in progress), January 2017. 547 [I-D.greevenbosch-appsawg-cbor-cddl] 548 Vigano, C. and H. Birkholz, "CBOR data definition language 549 (CDDL): a notational convention to express CBOR data 550 structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work 551 in progress), September 2016. 553 Authors' Addresses 554 Henk Birkholz 555 Fraunhofer SIT 556 Rheinstrasse 75 557 Darmstadt 64295 558 Germany 560 Email: henk.birkholz@sit.fraunhofer.de 562 Jessica Fitzgerald-McKay 563 Department of Defense 564 9800 Savage Road 565 Ft. Meade, Maryland 566 USA 568 Email: jmfitz2@nsa.gov 570 Charles Schmidt 571 The MITRE Corporation 572 202 Burlington Road 573 Bedford, Maryland 01730 574 USA 576 Email: cmschmidt@mitre.org 578 David Waltermire 579 National Institute of Standards and Technology 580 100 Bureau Drive 581 Gaithersburg, Maryland 20877 582 USA 584 Email: david.waltermire@nist.gov