idnits 2.17.1 draft-ietf-sacm-coswid-02.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 4 instances of too long lines in the document, the longest one being 19 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 date (July 04, 2017) is 2486 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) == Outdated reference: A later version (-15) exists of draft-ietf-ace-cbor-web-token-07 ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Downref: Normative reference to an Informational RFC: RFC 7228 -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SWID' == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-10 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-12 Summary: 4 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: January 5, 2018 Department of Defense 6 C. Schmidt 7 The MITRE Corporation 8 D. Waltermire 9 NIST 10 July 04, 2017 12 Concise Software Identifiers 13 draft-ietf-sacm-coswid-02 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 and augmented for application 20 in Constrained-Node Networks. Next to the inherent capability of 21 SWID tags to express arbitrary context information, CoSWID support 22 the definition of additional semantics via well-defined data 23 definitions incorporated by extension points. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 5, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Concise SWID Extensions . . . . . . . . . . . . . . . . . 4 61 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 62 2. Concise SWID Data Definition . . . . . . . . . . . . . . . . 4 63 3. Description of the SWID Attribute Vocabulary Definition . . . 9 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 67 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 9.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Appendix A. Explicit file-hash Type Used in Concise SWID Tags 73 (label 56) . . . . . . . . . . . . . . . . . . . . . 13 74 Appendix B. CoSWID Attributes for Firmware (label 57) . . . . . 14 75 Appendix C. Signed Concise SWID Tags using COSE . . . . . . . . 16 76 Appendix D. CoSWID used as Reference Integrity Measurements 77 (CoSWID RIM) . . . . . . . . . . . . . . . . . . . . 17 78 Appendix E. CBOR Web Token for Concise SWID Tags . . . . . . . . 18 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 81 1. Introduction 83 SWID tags have several use-applications including but not limited to: 85 o Software Inventory Management, a part of the Software Asset 86 Management [SAM] process, which requires an accurate list of 87 discernible deployed software components. 89 o Vulnerability Assessment, which requires a semantic link between 90 standardized vulnerability descriptions and IT-assets [X.1520]. 92 o Remote Attestation, which requires a link between reference 93 integrity measurements (RIM) and security logs of measured 94 software components [I-D.birkholz-tuda]. 96 SWID tags, as defined in ISO-19770-2:2015 [SWID], provide a 97 standardized format for a record that identifies and describes a 98 specific release of a software product. Different software products, 99 and even different releases of a particular software product, each 100 have a different SWID tag record associated with them. In addition 101 to defining the format of these records, ISO-19770-2:2015 defines 102 requirements concerning the SWID tag life-cycle. Specifically, when 103 a software product is installed on an endpoint, that product's SWID 104 tag is also installed. Likewise, when the product is uninstalled or 105 replaced, the SWID tag is deleted or replaced, as appropriate. As a 106 result, ISO-19770-2:2015 describes a system wherein there is a 107 correspondence between the set of installed software products on an 108 endpoint, and the presence on that endpoint of the SWID tags 109 corresponding to those products. 111 SWID tags are meant to be flexible and able to express a broad set of 112 metadata about a software product. Moreover, there are multiple 113 types of SWID tags, each providing different types of information. 114 For example, a "corpus tag" is used to describe an application's 115 installation image on an installation media, while a "patch tag" is 116 meant to describe a patch that modifies some other application. 117 While there are very few required fields in SWID tags, there are many 118 optional fields that support different uses of these different types 119 of tags. While a SWID tag that consisted only of required fields 120 could be a few hundred bytes in size, a tag containing many of the 121 optional fields could be many orders of magnitude larger. 123 This document defines a more concise representation of SWID tags in 124 the Concise Binary Object Representation (CBOR) [RFC7049]. This is 125 described via the Concise Data Definition Language (CDDL) 126 [I-D.greevenbosch-appsawg-cbor-cddl]. The resulting Concise SWID 127 data definition is interoperable with the XML schema definition of 128 ISO-19770-2:2015 [SWID]. The vocabulary, i.e., the CDDL names of the 129 types and members used in the CoSWID data definition, is mapped to 130 more concise labels represented as small integers. The names used in 131 the CDDL data definition and the mapping to the CBOR representation 132 using integer labels is based on the vocabulary of the XML attribute 133 and element names defined in ISO-19770-2:2015. 135 Real-world instances of SWID tags can be fairly large, and the 136 communication of SWID tags in use-applications such as those 137 described earlier can cause a large amount of data to be transported. 138 This can be larger than acceptable for constrained devices and 139 networks. CoSWID tags significantly reduce the amount of data 140 transported as compared to a typical SWID tag. This reduction is 141 enable through the use of CBOR, which maps human-readable labels of 142 that content to more concise integer labels (indices). This allows 143 SWID tags to be part of an enterprise security solution for a wider 144 range of endpoints and environments. 146 1.1. Concise SWID Extensions 148 This document specifies a standard equivalent to the ISO-19770-2:2015 149 standard. The corresponding CoSWID data definition includes two 150 kinds of augmentation. 152 o the explicit definition of types for attributes that are typically 153 stored in the "any attribute" of an ISO-19770-2:2015 in XML 154 representation. These are covered in the main body of this 155 document. 157 o the inclusion of extension points in the CoSWID data definition 158 that allow for additional uses of CoSWID tags that go beyond the 159 original scope of ISO-19770-2:2015 tags. These are covered in 160 appendices to this document. 162 1.2. Requirements Notation 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in RFC 167 2119, BCP 14 [RFC2119]. 169 2. Concise SWID Data Definition 171 The following is a CDDL representation of the ISO-19770-2:2015 [SWID] 172 XML schema definition of SWID tags. This representation includes 173 every SWID tag fields and attribute and thus supports all SWID tag 174 use cases. The CamelCase notation used in the XML schema definition 175 is changed to a hyphen-separated notation (e.g. ResourceCollection 176 is named resource-collection in the CoSWID data definition). This 177 deviation from the original notation used in the XML representation 178 reduces ambiguity when referencing certain attributes in 179 corresponding textual descriptions. An attribute referred by its 180 name in CamelCase notation explicitly relates to XML SWID tags, an 181 attribute referred by its name in hyphen-separated notation 182 explicitly relates to CoSWID tags. This approach simplifies the 183 composition of further work that reference both XML SWID and CoSWID 184 documents. 186 Human-readable names of members in the CDDL data definition are 187 mapped to integer indices via a block of rules at the bottom of the 188 definition. The 66 character strings of the SWID vocabulary that 189 would have to be stored or transported in full if using the original 190 vocabulary are replaced. 192 Concise Software Identifiers are tailored to be used in the domain of 193 constrained-node networks. A typical endpoint is capable of storing 194 the CoSWID tag of installed software, a constrained-node might lack 195 that capability. CoSWID address these constraints and the 196 corresponding specification is augmented to retain their usefulness 197 in the thing-2-thing domain. Specific examples include, but are not 198 limited to limiting the scope of hash algorithms to the IANA Named 199 Information tables or including firmware attributes addressing 200 devices that do not necessarily provide a file-system to store a 201 CoSWID tag in. 203 In order to create a valid CoSWID document the structure of the 204 corresponding CBOR message MUST adhere to the following CDDL data 205 definition. 207 208 concise-software-identity = { 209 global-attributes, 210 ? entity-entry, 211 ? evidence-entry, 212 ? link-entry, 213 ? software-meta-entry, 214 ? payload-entry, 215 ? any-element-entry, 216 ? corpus, 217 ? patch, 218 ? media, 219 swid-name, 220 ? supplemental, 221 tag-id, 222 ? tag-version, 223 ? version, 224 ? version-scheme, 225 } 227 any-uri = text 228 label = text / int 230 any-attribute = ( 231 label => text / int / [ 2* text ] / [ 2* int ] 232 ) 234 any-element-map = { 235 global-attributes, 236 * label => any-element-map / [ 2* any-element-map ], 237 } 239 global-attributes = ( 240 ? lang, 241 * any-attribute, 242 ) 244 resource-collection = ( 245 ? directory-entry, 246 ? file-entry, 247 ? process-entry, 248 ? resource-entry 249 * $$resource-extension 250 ) 252 file = { 253 filesystem-item, 254 ? size, 255 ? version, 256 ? file-hash, 257 } 259 filesystem-item = ( 260 global-attributes, 261 ? key, 262 ? location, 263 fs-name, 264 ? root, 265 ) 267 directory = { 268 filesystem-item, 269 path-elements, 270 } 272 process = { 273 global-attributes, 274 process-name, 275 ? pid, 276 } 278 resource = { 279 global-attributes, 280 type, 281 } 283 entity = { 284 global-attributes, 285 extended-data, 286 entity-name, 287 ? reg-id, 288 role, 289 ? thumbprint, 290 } 292 evidence = { 293 global-attributes, 294 resource-collection, 295 ? date, 296 ? device-id, 297 } 299 link = { 300 global-attributes, 301 ? artifact, 302 href, 303 ? media, 304 ? ownership, 305 rel, 306 ? type, 307 ? use, 308 } 310 software-meta = { 311 global-attributes, 312 ? activation-status, 313 ? channel-type, 314 ? colloquial-version, 315 ? description, 316 ? edition, 317 ? entitlement-data-required, 318 ? entitlement-key, 319 ? generator, 320 ? persistent-id, 321 ? product, 322 ? product-family, 323 ? revision, 324 ? summary, 325 ? unspsc-code, 326 ? unspsc-version, 327 } 329 payload = { 330 global-attributes, 331 resource-collection, 332 } 334 tag-id = (0: text) 335 swid-name = (1: text) 336 entity-entry = (2: entity / [ 2* entity ]) 337 evidence-entry = (3: evidence) 338 link-entry = (4: link / [ 2* link ]) 339 software-meta-entry = (5: software-meta / [ 2* software-meta ]) 340 payload-entry = (6: payload) 341 any-element-entry = (7: any-element-map / [ 2* any-element-map ]) 342 corpus = (8: bool) 343 patch = (9: bool) 344 media = (10: text) 345 supplemental = (11: bool) 346 tag-version = (12: integer) 347 version = (13: text) 348 version-scheme = (14: text) 349 lang = (15: text) 350 directory-entry = (16: directory / [ 2* directory ]) 351 file-entry = (17: file / [ 2* file ]) 352 process-entry = (18: process / [ 2* process ]) 353 resource-entry = (19: resource / [ 2* resource ]) 354 size = (20: integer) 355 key = (21: bool) 356 location = (22: text) 357 fs-name = (23: text) 358 root = (24: text) 359 path-elements = (25: { * file-entry, 360 * directory-entry, 361 } 362 ) 363 process-name = (26: text) 364 pid = (27: integer) 365 type = (28: text) 366 extended-data = (29: any-element-map / [ 2* any-element-map ]) 367 entity-name = (30: text) 368 reg-id = (31: any-uri) 369 role = (32: text / [2* text]) 370 thumbprint = (33: text) 371 date = (34: time) 372 device-id = (35: text) 373 artifact = (36: text) 374 href = (37: any-uri) 375 ownership = (38: "shared" / "private" / "abandon") 376 rel = (39: text) 377 use = (40: "optional" / "required" / "recommended") 378 activation-status = (41: text) 379 channel-type = (42: text) 380 colloquial-version = (43: text) 381 description = (44: text) 382 edition = (45: text) 383 entitlement-data-required = (46: bool) 384 entitlement-key = (47: text) 385 generator = (48: text) 386 persistent-id = (49: text) 387 product = (50: text) 388 product-family = (51: text) 389 revision = (52: text) 390 summary = (53: text) 391 unspsc-code = (54: text) 392 unspsc-version = (55: text) 393 file-hash = (56: [ hash-alg-id: int, 394 hash-value: bstr, 395 ] 396 ) 397 399 3. Description of the SWID Attribute Vocabulary Definition 401 Yet to be written still... 403 4. IANA Considerations 405 This document will include requests to IANA: 407 o Integer indices for SWID content attributes and information 408 elements. 410 o Content-Type for CoAP to be used in COSE. 412 5. Security Considerations 414 SWID tags contain public information about software products and, as 415 such, do not need to be protected against disclosure on an endpoint. 416 Similarly, SWID tags are intended to be easily discoverable by 417 applications and users on an endpoint in order to make it easy to 418 identify and collect all of an endpoint's SWID tags. As such, any 419 security considerations regarding SWID tags focus on the application 420 of SWID tags to address security challenges, and the possible 421 disclosure of the results of those applications. 423 A signed SWID tag whose signature is intact can be relied upon to be 424 unchanged since it was signed. If the SWID tag was created by the 425 software author, this generally means that it has undergone no change 426 since the software application with which the tag is associated was 427 installed. By implication, this means that the signed tag reflects 428 the software author's understanding of the details of that software 429 product. This can be useful assurance when the information in the 430 tag needs to be trusted, such as when the tag is being used to convey 431 golden measurements. By contrast, the data contained in unsigned 432 tags cannot be trusted to be unmodified. 434 SWID tags are designed to be easily added and removed from an 435 endpoint along with the installation or removal of software products. 436 On endpoints where addition or removal of software products is 437 tightly controlled, the addition or removal of SWID tags can be 438 similarly controlled. On more open systems, where many users can 439 manage the software inventory, SWID tags may be easier to add or 440 remove. On such systems, it may be possible to add or remove SWID 441 tags in a way that does not reflect the actual presence or absence of 442 corresponding software products. Similarly, not all software 443 products automatically install SWID tags, so products may be present 444 on an endpoint without providing a corresponding SWID tag. As such, 445 any collection of SWID tags cannot automatically be assumed to 446 represent either a complete or fully accurate representation of the 447 software inventory of the endpoint. However, especially on devices 448 that more strictly control the ability to add or remove applications, 449 SWID tags are an easy way to provide an preliminary understanding of 450 that endpoint's software inventory. 452 Any report of an endpoint's SWID tag collection provides information 453 about the software inventory of that endpoint. If such a report is 454 exposed to an attacker, this can tell them which software products 455 and versions thereof are present on the endpoint. By examining this 456 list, the attacker might learn of the presence of applications that 457 are vulnerable to certain types of attacks. As noted earlier, SWID 458 tags are designed to be easily discoverable by an endpoint, but this 459 does not present a significant risk since an attacker would already 460 need to have access to the endpoint to view that information. 461 However, when the endpoint transmits its software inventory to 462 another party, or that inventory is stored on a server for later 463 analysis, this can potentially expose this information to attackers 464 who do not yet have access to the endpoint. As such, it is important 465 to protect the confidentiality of SWID tag information that has been 466 collected from an endpoint, not because those tags individually 467 contain sensitive information, but because the collection of SWID 468 tags and their association with an endpoint reveals information about 469 that endpoint's attack surface. 471 Finally, both the ISO-19770-2:2015 XML schema definition and the 472 Concise SWID data definition allow for the construction of "infinite" 473 SWID tags or SWID tags that contain malicious content with the intend 474 if creating non-deterministic states during validation or processing 475 of SWID tags. While software product vendors are unlikely to do 476 this, SWID tags can be created by any party and the SWID tags 477 collected from an endpoint could contain a mixture of vendor and non- 478 vendor created tags. For this reason, tools that consume SWID tags 479 ought to treat the tag contents as potentially malicious and should 480 employ input sanitizing on the tags they ingest. 482 6. Acknowledgements 484 7. Change Log 486 Changes from version 00 to version 01: 488 o Added CWT usage for absolute SWID paths on a device 490 o Fixed cardinality of type-choices including arrays 492 o Included first iteration of firmware resource-collection 494 Changes since adopted as a WG I-D -00: 496 o Removed redundant any-attributes originating from the ISO- 497 19770-2:2015 XML schema definition 499 o Fixed broken multi-map members 501 o Introduced a more restrictive item (any-element-map) to represent 502 custom maps, increased restriction on types for the any-attribute, 503 accordingly 505 o Fixed X.1520 reference 507 o Minor type changes of some attributes (e.g. NMTOKENS) 509 o Added semantic differentiation of various name types (e,g. fs- 510 name) 512 Changes from version 00 to version 01: 514 o Ambiguity between evidence and payload eliminated by introducing 515 explicit members (while still 517 o allowing for "empty" SWID tags) 519 o Added a relatively restrictive COSE envelope using cose_sign1 to 520 define signed CoSWID (single signer only, at the moment) 522 o Added a definition how to encode hashes that can be stored in the 523 any-member using existing IANA tables to reference hash-algorithms 525 Changes from version 01 to version 02: 527 o Enforced a more strict separation between the core CoSWID 528 definition and additional usage by moving content to corresponding 529 appendices. 531 o Removed artifacts inherited from the reference schema provided by 532 ISO (e.g. NMTOKEN(S)) 534 o Simplified the core data definition by removing group and type 535 choices where possible 537 o Minor reordering of map members 539 o Added a first extension point to address requested flexibility for 540 extensions beyond the any-element 542 8. Contributors 544 9. References 546 9.1. Normative References 548 [I-D.ietf-ace-cbor-web-token] 549 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 550 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-07 551 (work in progress), July 2017. 553 [I-D.ietf-cose-msg] 554 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 555 draft-ietf-cose-msg-24 (work in progress), November 2016. 557 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 558 Requirement Levels", BCP 14, RFC 2119, 559 DOI 10.17487/RFC2119, March 1997, 560 . 562 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 563 Protect Firmware Packages", RFC 4108, 564 DOI 10.17487/RFC4108, August 2005, 565 . 567 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 568 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 569 . 571 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 572 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 573 October 2013, . 575 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 576 Constrained-Node Networks", RFC 7228, 577 DOI 10.17487/RFC7228, May 2014, 578 . 580 [SAM] "Information technology - Software asset management - Part 581 5: Overview and vocabulary", ISO/IEC 19770-5:2013, 582 November 2013. 584 [SWID] "Information technology - Software asset management - Part 585 2: Software identification tag'", ISO/IEC 19770-2:2015, 586 October 2015. 588 [X.1520] "Recommendation ITU-T X.1520 (2014), Common 589 vulnerabilities and exposures", April 2011. 591 9.2. Informative References 593 [I-D.banghart-sacm-rolie-softwaredescriptor] 594 Waltermire, D. and S. Banghart, "Definition of the ROLIE 595 Software Descriptor Extension", draft-banghart-sacm-rolie- 596 softwaredescriptor-01 (work in progress), May 2017. 598 [I-D.birkholz-tuda] 599 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 600 "Time-Based Uni-Directional Attestation", draft-birkholz- 601 tuda-04 (work in progress), March 2017. 603 [I-D.greevenbosch-appsawg-cbor-cddl] 604 Birkholz, H., Vigano, C., and C. Bormann, "CBOR data 605 definition language (CDDL): a notational convention to 606 express CBOR data structures", draft-greevenbosch-appsawg- 607 cbor-cddl-10 (work in progress), March 2017. 609 [I-D.ietf-sacm-terminology] 610 Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget, 611 "Security Automation and Continuous Monitoring (SACM) 612 Terminology", draft-ietf-sacm-terminology-12 (work in 613 progress), March 2017. 615 Appendix A. Explicit file-hash Type Used in Concise SWID Tags (label 616 56) 618 CoSWID add explicit support for the representation of file-hashes 619 using algorithms that are registered at the Named Information Hash 620 Algorithm Registry via the file-hash member (label 56). 622 file-hash = (56: [ hash-alg-id: int, hash-value: bstr ] ) 623 The number used as a value for hash-alg-id MUST refer the ID in the 624 Named Information Hash Algorithm table; other hash algorithms MUST 625 NOT be used. The hash-value MUST represent the raw hash value of the 626 file-entry the file-hash type is included in. 628 Appendix B. CoSWID Attributes for Firmware (label 57) 630 The ISO-19770-2:2015 specification of SWID tags assumes the existence 631 of a file system a software component is installed and stored in. In 632 the case of constrained-node networks [RFC7228] or network equipment 633 this assumption might not apply. Concise software instances in the 634 form of (modular) firmware are often stored directly on a block 635 device that is a hardware component of the constrained-node or 636 network equipment. Multiple differentiable block devices or 637 segmented block devices that contain parts of modular firmware 638 components (potentially each with their own instance version) are 639 already common at the time of this writing. 641 The optional attributes that annotate a firmware package address 642 specific characteristics of pieces of firmware stored directly on a 643 block-device in contrast to software deployed in a file-system. In 644 essence, trees of relative path-elements expressed by the directory 645 and file structure in CoSWID tags are typically unable to represent 646 the location of a firmware on a constrained-node (small thing). The 647 composite nature of firmware and also the actual composition of small 648 things require a set of attributes to address the identification of 649 the correct component in a composite thing for each individual piece 650 of firmware. A single component also potentially requires a number 651 of distinct firmware parts that might depend on each other 652 (versions). These dependencies can be limited to the scope of the 653 component itself or extend to the scope of a larger composite device. 654 In addition, it might not be possible (or feasible) to store a CoSWID 655 tag document (permanently) on a small thing along with the 656 corresponding piece of firmware. 658 To address the specific characteristics of firmware, the extension 659 point "$$resource-extension" is used to allow for an additional type 660 of resource description--firmware-entry--thereby increasing the self- 661 descriptiveness and flexibility of CoSWID. The optional use of the 662 extension point "$$resource-extension" in respect to firmware MUST 663 adhere to the following CDDL data definition. 665 666 $$resource-extension //= (firmware-entry,) 668 firmware = { 669 firmware-name, ; inherited from RFC4108 670 ? firmware-version, 671 ? firmware-package-identifier, ; inherited from RFC4108 672 ? dependency, ; inherited from RFC4108 673 ? component-index, ; equivalent to RFC4108 fwPkgType 674 ? block-device-identifier, 675 ? target-hardware-identifier, ; an RFC4108 alternative to model-label 676 model-label, 677 ? firmware-hash, ; a hash for a single, incl. NI hash-algo index 678 ? cms-firmware-package, ; RCF4108, experimental, this is an actual firmware blob! 679 } 681 firmware-entry = (57: firmware / [ 2* firmware ]) 682 firmware-hash = (58: [ hash-alg-id: int, 683 hash-value: bstr, 684 ] 685 ) 686 firmware-name = (59 : text) 687 firmware-version = (60 : text / int) 688 component-index = (61 : int) 689 model-label = (62: text / int) 690 block-device-identifier = (63 : text / int) 691 cms-firmware-package = (64: bstr) 692 firmware-package-identifier = (65: text) 693 target-hardware-identifier = (66: text) 694 dependency = (67: { ? firmware-name, 695 ? firmware-version, 696 ? firmware-package-identifier, 697 } 698 ) 699 701 The members of the firmware group that constitutes the content of the 702 firmware-entry is based on the metadata about firmware defined in 703 [RFC4108]. As with every semantic differentiation that is supported 704 by the resource-collection type, the use of firmware-entry is 705 optional. It is REQUIRED not to instantiate more than one firmware- 706 entry, as the firmware group is used in a map and therefore only 707 allows for unique labels. 709 The optional cms-firmware-package member allows to include the actual 710 firmware in the CoSWID tag that also expresses its metadata as a 711 byte-string. This option enables a CoSWID tag to be used as a 712 container or wrapper that composes both firmware and its metadata in 713 a single document (which again can be signed, encrypted and/or 714 compressed). In consequence, a CoSWID tag about firmware can be 715 conveyed as an identifying document across endpoints or used as a 716 reference integrity measurement as usual. Alternatively, it can also 717 convey an actual piece of firmware, serve its intended purpose as a 718 SWID tag and then - due to the lack of a location to store it - be 719 discarded. 721 Appendix C. Signed Concise SWID Tags using COSE 723 SWID tags, as defined in the ISO-19770-2:2015 XML schema, can include 724 cryptographic signatures to protect the integrity of the SWID tag. 725 In general, tags are signed by the tag creator (typically, although 726 not exclusively, the vendor of the software product that the SWID tag 727 identifies). Cryptographic signatures can make any modification of 728 the tag detectable, which is especially important if the integrity of 729 the tag is important, such as when the tag is providing reference 730 integrity measurments for files. 732 The ISO-19770-2:2015 XML schema uses XML DSIG to support 733 cryptographic signatures. CoSWID tags require a different signature 734 scheme than this. COSE (CBOR Object Signing and Encryption) provides 735 the required mechanism [I-D.ietf-cose-msg]. Concise SWID can be 736 wrapped in a COSE Single Signer Data Object (cose-sign1) that 737 contains a single signature. The following CDDL defines a more 738 restrictive subset of header attributes allowed by COSE tailored to 739 suit the requirements of Concise SWID. 741 742 signed-coswid = #6.997(COSE-Sign1-coswid) ; see TBS7 in current COSE I-D 744 label = int / tstr ; see COSE I-D 1.4. 745 values = any ; see COSE I-D 1.4. 747 unprotected-signed-coswid-header = { 748 1 => int, ; algorithm identifier 749 3 => "application/coswid", ; request for CoAP IANA registry to become an int 750 * label => values, 751 } 753 protected-signed-coswid-header = { 754 4 => bstr, ; key identifier 755 * label => values, 756 } 758 COSE-Sign1-coswid = [ 759 protected: bstr .cbor protected-signed-coswid-header, 760 unprotected: unprotected-signed-coswid-header, 761 payload: bstr .cbor concise-software-identity, 762 signature: bstr, 763 ] 764 766 Appendix D. CoSWID used as Reference Integrity Measurements (CoSWID 767 RIM) 769 A vendor supplied signed CoSWID tag that includes hash-values for the 770 files that compose a software component can be used as a RIM 771 (reference integrity measurement). A RIM is a type of declarative 772 guidance that can be used to assert the compliance of an endpoint by 773 assessing the installed software. In the context of remote 774 attestation based on an attestation via hardware rooted trust, a 775 verifier can appraise the integrity of the conveyed measurements of 776 software components using a CoSWID RIM provided by a source, such as 777 [I-D.banghart-sacm-rolie-softwaredescriptor]. 779 RIM Manifests (RIMM): A group of SWID tags about the same 780 (sub-)system, system entity, or (sub-)component (compare 781 [RFC4949]). A RIMM manifest is a distinct document that is 782 typically conveyed en-block and constitutes declarative guidance 783 in respect to a specific (target) endpoint (compare 784 [I-D.ietf-sacm-terminology]). 786 If multiple CoSWID compose a RIMM, the following CDDL data definition 787 SHOULD be used. 789 RIMM = [ + concise-software-identity / signed-coswid ] 791 Appendix E. CBOR Web Token for Concise SWID Tags 793 A typical requirement regarding specific instantiations of endpoints 794 - and, as a result, specific instantiations of software components - 795 is a representation of the absolute path of a CoSWID tag document in 796 a file system in order to derive absolute paths of files represented 797 in the corresponding CoSWID tag. The absolute path of an evidence 798 CoSWID tag can be included as a claim in the header of a CBOR Web 799 Token [I-D.ietf-ace-cbor-web-token]. Depending on the source of the 800 token, the claim can be in the protected or unprotected header 801 portion. 803 804 CDDL TBD 805 807 Authors' Addresses 809 Henk Birkholz 810 Fraunhofer SIT 811 Rheinstrasse 75 812 Darmstadt 64295 813 Germany 815 Email: henk.birkholz@sit.fraunhofer.de 817 Jessica Fitzgerald-McKay 818 Department of Defense 819 9800 Savage Road 820 Ft. Meade, Maryland 821 USA 823 Email: jmfitz2@nsa.gov 825 Charles Schmidt 826 The MITRE Corporation 827 202 Burlington Road 828 Bedford, Maryland 01730 829 USA 831 Email: cmschmidt@mitre.org 832 David Waltermire 833 National Institute of Standards and Technology 834 100 Bureau Drive 835 Gaithersburg, Maryland 20877 836 USA 838 Email: david.waltermire@nist.gov