idnits 2.17.1 draft-ietf-sacm-coswid-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 : ---------------------------------------------------------------------------- ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 16, 2017) is 2619 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-02 ** 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 (-01) exists of draft-banghart-sacm-rolie-softwaredescriptor-00 == 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 (~~), 6 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: August 20, 2017 Department of Defense 6 C. Schmidt 7 The MITRE Corporation 8 D. Waltermire 9 NIST 10 February 16, 2017 12 Concise Software Identifiers 13 draft-ietf-sacm-coswid-01 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. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 20, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 58 2. Concise SWID CDDL specification . . . . . . . . . . . . . . . 4 59 3. Encoding hashes for Concise SWID tags . . . . . . . . . . . . 9 60 4. CoSWID used as Reference Integrity Measurements (CoSWID RIM) 9 61 5. Firmware SWID tags . . . . . . . . . . . . . . . . . . . . . 9 62 6. COSE signatures for Concise SWID tags . . . . . . . . . . . . 10 63 7. CBOR Web Token for Concise SWID tags . . . . . . . . . . . . 11 64 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 67 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 13.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 SWID tags have several use-applications including but not limited to: 78 o Software Inventory Management, a part of the Software Asset 79 Management [SAM] process, which requires an accurate list of 80 discernible deployed software instances. 82 o Vulnerability Assessment, which requires a semantic link between 83 standardized vulnerability descriptions and IT-assets [X.1520]. 85 o Remote Attestation, which requires a link between reference 86 integrity measurements (RIM) and security logs of measured 87 software components [I-D.birkholz-tuda]. 89 SWID tags, as defined in ISO-19770-2:2015 [SWID], provide a 90 standardized format for a record that identifies and describes a 91 specific release of a software product. Different software products, 92 and even different releases of a particular software product, each 93 have a different SWID tag record associated with them. In addition 94 to defining the format of these records, ISO-19770-2:2015 defines 95 requirements concerning the SWID tag lifecycle. Specifically, when a 96 software product is installed on an endpoint, that product's SWID tag 97 is also installed. Likewise, when the product is uninstalled or 98 replaced, the SWID tag is deleted or replaced, as appropriate. As a 99 result, ISO-19770-2:2015 describes a system wherein there is a 100 correspondence between the set of installed software products on an 101 endpoint, and the presence on that endpoint of the SWID tags 102 corresponding to those products. 104 SWID tags are meant to be flexible and able to express a broad set of 105 metadata about a software product. Moreover, there are multiple 106 types of SWID tags, each providing different types of information. 107 For example, a "corpus tag" is used to describe an application's 108 installation image on an installation media, while a "patch tag" is 109 meant to describe a patch that modifies some other application. 110 While there are very few required fields in SWID tags, there are many 111 optional fields that support different uses of these different types 112 of tags. While a SWID tag that consisted only of required fields 113 could be a few hundred bytes in size, a tag containing many of the 114 optional fields could be many orders of magnitude larger. 116 This document defines a more concise representation of SWID tags in 117 the Concise Binary Object Representation (CBOR) [RFC7049]. This is 118 described via the CBOR Data Definition Language (CDDL) 119 [I-D.greevenbosch-appsawg-cbor-cddl]. The resulting Concise SWID 120 data definition is interoperable with the XML schema definition of 121 ISO-19770-2:2015 [SWID]. The vocabulary, i.e., the CDDL names of the 122 types and members used in the Concise SWID data definition, is mapped 123 to more concise labels represented as small integers. The names used 124 in the CDDL and the mapping to the CBOR representation using integer 125 labels is based on the vocabulary of the XML attribute and element 126 names defined in ISO-19770-2:2015. 128 Real-world instances of SWID tags can be fairly large, and the 129 communication of SWID tags in use-applications such as those 130 described earlier can cause a large amount of data to be transported. 131 This can be larger than acceptable for constrained devices and 132 networks. Concise SWID tags significantly reduce the amount of data 133 transported as compared to a typical SWID tag. This reduction is 134 enable through the use of CBOR, which maps human-readable labels of 135 that content to more concise integer labels (indices). This allows 136 SWID tags to be part of an enterprise security solution for a wider 137 range of endpoints and environments. 139 1.1. Requirements notation 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in RFC 144 2119, BCP 14 [RFC2119]. 146 2. Concise SWID CDDL specification 148 The following is a CDDL representation of the ISO-19770-2:2015 [SWID] 149 XML schema definition of SWID tags. This representation includes all 150 SWID tag fields and thus supports all SWID tag use cases. The 151 CamelCase notation used in the XML schema definition is changed to 152 hyphen-separated notation (e.g. ResourceCollection is named 153 resource-collection in the COSWID CDDL specification). The human- 154 readable names of members are mapped to integer indices via a block 155 of rules at the bottom of the CDDL specification. The 66 character 156 strings of the SWID vocabulary that would have to be stored or 157 transported in full if using the original vocabulary are replaced. 159 Concise Software Identifiers are tailored to be used in the domain of 160 constrained-node networks. A typical endpoint is capable of storing 161 the CoSWID tag of installed software, a constrained-node might lack 162 that capability. CoSWID address these constraints and the 163 corresponding specification is augmented to retain their usefulness 164 in the thing-2-thing domain. Specific examples include, but are not 165 limited to limiting the scope of hash algorithms to the IANA Named 166 Information tables or including firmware attributes addressing 167 devices that do not necessarily provide a file-system to store a 168 CoSWID tag in. 170 171 concise-software-identity = { 172 global-attributes, 173 ? entity-entry, 174 ? evidence-entry, 175 ? link-entry, 176 ? software-meta-entry, 177 ? payload-entry, 178 ? any-element-entry, 179 ? corpus, 180 ? patch, 181 ? media, 182 swid-name, 183 ? supplemental, 184 tag-id, 185 ? tag-version, 186 ? version, 187 ? version-scheme, 188 } 190 NMTOKEN = text 191 NMTOKENS = text 193 date-time = time 194 any-uri = text 195 label = text / int 197 any-attribute = ( 198 label => text / int / [ 2* text ] / [ 2* int ] 199 ) 201 any-element-map = { 202 global-attributes, 203 * label => any-element-map / [ 2* any-element-map ], 204 } 206 global-attributes = ( 207 ? lang, 208 * any-attribute, 209 ) 211 resource-collection = ( 212 ? directory-entry, 213 ? file-entry, 214 ? process-entry, 215 ? resource-entry 216 ? firmware-entry 217 ) 219 file = { 220 filesystem-item, 221 ? size, 222 ? version, 223 ? file-hash, 224 } 226 filesystem-item = ( 227 global-attributes, 228 ? key, 229 ? location, 230 fs-name, 231 ? root, 232 ) 234 directory = { 235 filesystem-item, 236 path-elements, 237 } 239 firmware = { 240 firmware-name, ; inherited from RFC4108 241 ? firmware-version, 242 ? firmware-package-identifier, ; inherited from RFC4108 243 ? dependency, ; inherited from RFC4108 244 ? component-index, ; equivalent to RFC4108 fwPkgType 245 ? block-device-identifier, 246 ? target-hardware-identifier, ; an RFC4108 alternative to model-label 247 model-label, 248 ? firmware-hash, ; a hash for a single, incl. NI hash-algo index 249 ? cms-firmware-package, ; RCF4108, experimental, this is an actual firmware blob! 250 } 252 process = { 253 global-attributes, 254 process-name, 255 ? pid, 256 } 258 resource = { 259 global-attributes, 260 type, 261 } 263 entity = { 264 global-attributes, 265 meta-elements, 266 entity-name, 267 ? reg-id, 268 role, 269 ? thumbprint, 270 } 272 evidence = { 273 global-attributes, 274 resource-collection, 275 ? date, 276 ? device-id, 277 } 279 link = { 280 global-attributes, 281 ? artifact, 282 href, 283 ? media, 284 ? ownership, 285 rel, 286 ? type, 287 ? use, 288 } 289 software-meta = { 290 global-attributes, 291 ? activation-status, 292 ? channel-type, 293 ? colloquial-version, 294 ? description, 295 ? edition, 296 ? entitlement-data-required, 297 ? entitlement-key, 298 ? generator, 299 ? persistent-id, 300 ? product, 301 ? product-family, 302 ? revision, 303 ? summary, 304 ? unspsc-code, 305 ? unspsc-version, 306 } 308 payload = { 309 global-attributes, 310 resource-collection, 311 } 313 tag-id = (0: text) 314 swid-name = (1: text) 315 entity-entry = (2: entity / [ 2* entity ]) 316 evidence-entry = (3: evidence / [ 2* evidence ]) 317 link-entry = (4: link / [ * link ]) 318 software-meta-entry = (5: software-meta / [ 2* software-meta ]) 319 payload-entry = (6: payload / [ 2* payload ]) 320 any-element-entry = (7: any-element-map / [ 2* any-element-map ]) 321 corpus = (8: bool) 322 patch = (9: bool) 323 media = (10: text) 324 supplemental = (11: bool) 325 tag-version = (12: integer) 326 version = (13: text) 327 version-scheme = (14: NMTOKEN) 328 lang = (15: text) 329 directory-entry = (16: directory / [ 2* directory ]) 330 file-entry = (17: file / [ 2* file ]) 331 process-entry = (18: process / [ 2* process ]) 332 resource-entry = (19: resource / [ 2* resource ]) 333 size = (20: integer) 334 key = (21: bool) 335 location = (22: text) 336 fs-name = (23: text) 337 root = (24: text) 338 path-elements = (25: { * directory-entry, 339 * file-entry, 340 } 341 ) 342 process-name = (26: text) 343 pid = (27: integer) 344 type = (28: text) 345 meta-elements = (29: any-element-map / [ 2* any-element-map ]) 346 entity-name = (30: text) 347 reg-id = (31: any-uri) 348 role = (32: NMTOKENS) 349 thumbprint = (33: text) 350 date = (34: date-time) 351 device-id = (35: text) 352 artifact = (36: text) 353 href = (37: any-uri) 354 ownership = (38: "shared" / "private" / "abandon") 355 rel = (39: NMTOKEN) 356 use = (40: "optional" / "required" / "recommended") 357 activation-status = (41: text) 358 channel-type = (42: text) 359 colloquial-version = (43: text) 360 description = (44: text) 361 edition = (45: text) 362 entitlement-data-required = (46: bool) 363 entitlement-key = (47: text) 364 generator = (48: text) 365 persistent-id = (49: text) 366 product = (50: text) 367 product-family = (51: text) 368 revision = (52: text) 369 summary = (53: text) 370 unspsc-code = (54: text) 371 unspsc-version = (55: text) 372 file-hash = (56: [ hash-alg-id: int, 373 hash-value: bstr, 374 ] 375 ) 377 firmware-entry = (57: firmware / [ 2* firmware ]) 378 firmware-hash = (58: [ hash-alg-id: int, 379 hash-value: bstr, 380 ] 381 ) 382 firmware-name = (59 : text) 383 firmware-version = (60 : text / int) 384 component-index = (61 : int) 385 model-label = (62: text / int) 386 block-device-identifier = (63 : text / int) 387 cms-firmware-package = (64: bstr) 388 firmware-package-identifier = (65: text) 389 target-hardware-identifier = (66: text) 390 dependency = (67: { ? firmware-name, 391 ? firmware-version, 392 ? firmware-package-identifier, 393 } 394 ) 395 397 3. Encoding hashes for Concise SWID tags 399 Concise SWID add explicit support for the representation of file- 400 hashes using algorithms that are registered at the Named Information 401 Hash Algorithm Registry via the file-hash item (label 56). The 402 number used as a value for hash-alg-id refers the ID in the Named 403 Information Hash Algorithm table. 405 4. CoSWID used as Reference Integrity Measurements (CoSWID RIM) 407 A vendor supplied signed CoSWID tag that includes hash-values for the 408 files that compose a software component can be used as a RIM 409 (reference integrity measurement). A RIM is a type of declarative 410 guidance that can be used to assert the compliance of an endpoint by 411 assessing the installed software. In the context of remote 412 attestation based on an attestation via a hardware security module 413 (hardware rooted trust), a verifier can appraise the integrity of the 414 conveyed measurements of software components using a CoSWID RIM 415 provided by a source, such as 416 [I-D.banghart-sacm-rolie-softwaredescriptor]. 418 5. Firmware SWID tags 420 The metadata defined in [RFC4108] is incorporated in the resource- 421 collection structure that semantically differentiates content stored 422 in a Concise Software Identifier. The optional attributes that 423 annoate a firmware package addresse specific characteristics of 424 pieces of firmware stored directly on a block-device in contrast to 425 software deployed in a file-system. Trees of relative path-elements 426 expressed by the directory and file structure in CoSWID tags are 427 typically unable to represent the location of a firmware on a 428 constrained-node (small thing). The composite nature of firmware and 429 also the actual composition of small things require a set of 430 attributes to identify the correct component in a composite thing for 431 each individual piece of firmware. A single component also 432 potentially requires a number of distinct firmware parts that might 433 depend on each other(s version). These dependencies can be limited 434 to the scope of the component itself or extend to the scope of a 435 small composite device. In addition, it might not be possible (or 436 feasible) to store a CoSWID tag document (permanently) on a small 437 thing along with the corresponding piece of firmware. Hence, CoSWID 438 tags can be used as a concise and flexible metadata document that 439 functions as a wrapper containing a (potentially compressed, signed, 440 and/or encrypted) piece of firmware and its corresponding CoSWID 441 attributes. A CoSWID tag about firmware can be transmitted as an 442 identifying document across endpoints or used as an reference 443 integrity measurement as usual. Alternatively, it can also convey an 444 actual piece of firmware, serve its intended purpose as a SWID tag 445 and then - due to the lack of a location to store it - be discarded. 447 6. COSE signatures for Concise SWID tags 449 SWID tags, as defined in the ISO-19770-2:2015 XML schema, can include 450 cryptographic signatures to protect the integrity of the SWID tag. 451 In general, tags are signed by the tag creator (typically, although 452 not exclusively, the vendor of the software product that the SWID tag 453 identifies). Cryptographic signatures can make any modification of 454 the tag detectable, which is especially important if the integrity of 455 the tag is important, such as when the tag is providing golden 456 measurements for files. 458 The ISO-19770-2:2015 XML schema uses XML DSIG to support 459 cryptographic signatures. Concise SWID tags require a different 460 signature scheme than this. COSE (CBOR Encoded Message Syntax) 461 provides the required mechanism [I-D.ietf-cose-msg]. Concise SWID 462 can be wrapped in a COSE Single Signer Data Object (cose-sign1) that 463 contains a single signature. The following CDDL defines a more 464 restrictive subset of header attributes allowed by COSE tailored to 465 suit the requirements of Concise SWID. 467 468 signed-coswid = #6.997(COSE-Sign1-coswid) ; see TBS7 in current COSE I-D 470 label = int / tstr ; see COSE I-D 1.4. 471 values = any ; see COSE I-D 1.4. 473 unprotected-signed-coswid-header = { 474 1 => int, ; algorithm identifier 475 3 => "application/coswid", ; request for CoAP IANA registry to become an int 476 * label => values, 477 } 479 protected-signed-coswid-header = { 480 4 => bstr, ; key identifier 481 * label => values, 482 } 484 COSE-Sign1-coswid = [ 485 protected: bstr .cbor protected-signed-coswid-header, 486 unprotected: unprotected-signed-coswid-header, 487 payload: bstr .cbor concise-software-identity, 488 signature: bstr, 489 ] 490 492 7. CBOR Web Token for Concise SWID tags 494 A typical requirement regarding specific instantiations of endpoints 495 - and, as a result, specific instantiations of software components - 496 is a representation of the absolute path of a CoSWID tag document in 497 a file system in order to derive absolute paths of files represented 498 in the corresponding CoSWID tag. The absolute path of an evidence 499 CoSWID tag can be included as a claim in the header of a CBOR Web 500 Token [I-D.ietf-ace-cbor-web-token]. Depending on the source of the 501 token, the claim can be in the protected or unprotected header 502 portion. 504 505 CDDL TBD 506 508 8. IANA considerations 510 This document will include requests to IANA: 512 o Integer indices for SWID content attributes and information 513 elements. 515 o Content-Type for CoAP to be used in COSE. 517 9. Security Considerations 519 SWID tags contain public information about software products and, as 520 such, do not need to be protected against disclosure on an endpoint. 521 Similarly, SWID tags are intended to be easily discoverable by 522 applications and users on an endpoint in order to make it easy to 523 identify and collect all of an endpoint's SWID tags. As such, any 524 security considerations regarding SWID tags focus on the application 525 of SWID tags to address security challenges, and the possible 526 disclosure of the results of those applications. 528 A signed SWID tag whose signature is intact can be relied upon to be 529 unchanged since it was signed. If the SWID tag was created by the 530 software author, this generally means that it has undergone no change 531 since the software application with which the tag is associated was 532 installed. By implication, this means that the signed tag reflects 533 the software author's understanding of the details of that software 534 product. This can be useful assurance when the information in the 535 tag needs to be trusted, such as when the tag is being used to convey 536 golden measurements. By contrast, the data contained in unsigned 537 tags cannot be trusted to be unmodified. 539 SWID tags are designed to be easily added and removed from an 540 endpoint along with the installation or removal of software products. 541 On endpoints where addition or removal of software products is 542 tightly controlled, the addition or removal of SWID tags can be 543 similarly controlled. On more open systems, where many users can 544 manage the software inventory, SWID tags may be easier to add or 545 remove. On such systems, it may be possible to add or remove SWID 546 tags in a way that does not reflect the actual presence or absence of 547 corresponding software products. Similarly, not all software 548 products automatically install SWID tags, so products may be present 549 on an endpoint without providing a corresponding SWID tag. As such, 550 any collection of SWID tags cannot automatically be assumed to 551 represent either a complete or fully accurate representation of the 552 software inventory of the endpoint. However, especially on devices 553 that more strictly control the ability to add or remove applications, 554 SWID tags are an easy way to provide an preliminary understanding of 555 that endpoint's software inventory. 557 Any report of an endpoint's SWID tag collection provides information 558 about the software inventory of that endpoint. If such a report is 559 exposed to an attacker, this can tell them which software products 560 and versions thereof are present on the endpoint. By examining this 561 list, the attacker might learn of the presence of applications that 562 are vulnerable to certain types of attacks. As noted earlier, SWID 563 tags are designed to be easily discoverable by an endpoint, but this 564 does not present a significant risk since an attacker would already 565 need to have access to the endpoint to view that information. 566 However, when the endpoint transmits its software inventory to 567 another party, or that inventory is stored on a server for later 568 analysis, this can potentially expose this information to attackers 569 who do not yet have access to the endpoint. As such, it is important 570 to protect the confidentiality of SWID tag information that has been 571 collected from an endpoint, not because those tags individually 572 contain sensitive information, but because the collection of SWID 573 tags and their association with an endpoint reveals information about 574 that endpoint's attack surface. 576 Finally, both the ISO-19770-2:2015 XML schema definition and the 577 Concise SWID data definition allow for the construction of "infinite" 578 SWID tags or SWID tags that contain malicious content with the intend 579 if creating non-deterministic states during validation or processing 580 of SWID tags. While software product vendors are unlikely to do 581 this, SWID tags can be created by any party and the SWID tags 582 collected from an endpoint could contain a mixture of vendor and non- 583 vendor created tags. For this reason, tools that consume SWID tags 584 ought to treat the tag contents as potentially malicious and should 585 employ input sanitizing on the tags they ingest. 587 10. Acknowledgements 589 11. Change Log 591 Changes from version 00 to version 01: 593 o Added CWT usage for absolute SWID paths on a device 595 o Fixed cardinality of type-choices including arrays 597 o Included first iteration of firmware resource-collection 599 Changes since adopted as a WG I-D -00: 601 o Removed redundant any-attributes originating from the ISO- 602 19770-2:2015 XML schema definition 604 o Fixed broken multi-map members 606 o Introduced a more restrictive item (any-element-map) to represent 607 custom maps, increased restriction on types for the any-attribute, 608 accordingly 610 o Fixed X.1520 reference 611 o Minor type changes of some attributes (e.g. NMTOKENS) 613 o Added semantic differentiation of various name types (e,g. fs- 614 name) 616 Changes from version 00 to version 01: 618 o Ambiguity between evidence and payload eliminated by introducing 619 explicit members (while still allowing for "empty" swid tags) 621 o Added a relatively restrictive COSE envelope using cose_sign1 to 622 define signed coswids (single signer only, at the moment) 624 o Added a defintion how to encode hashes that can be stored in the 625 any-member using existing IANA tables to reference hash-algorithms 627 First version -00 629 12. Contributors 631 13. References 633 13.1. Normative References 635 [I-D.ietf-ace-cbor-web-token] 636 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 637 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-02 638 (work in progress), January 2017. 640 [I-D.ietf-cose-msg] 641 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 642 draft-ietf-cose-msg-24 (work in progress), November 2016. 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, 646 DOI 10.17487/RFC2119, March 1997, 647 . 649 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 650 Protect Firmware Packages", RFC 4108, 651 DOI 10.17487/RFC4108, August 2005, 652 . 654 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 655 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 656 October 2013, . 658 [SAM] "Information technology - Software asset management - Part 659 5: Overview and vocabulary", ISO/IEC 19770-5:2013, 660 November 2013. 662 [SWID] "Information technology - Software asset management - Part 663 2: Software identification tag'", ISO/IEC 19770-2:2015, 664 October 2015. 666 [X.1520] "Recommendation ITU-T X.1520 (2014), Common 667 vulnerabilities and exposures", April 2011. 669 13.2. Informative References 671 [I-D.banghart-sacm-rolie-softwaredescriptor] 672 Waltermire, D. and S. Banghart, "Definition of the ROLIE 673 Software Descriptor Extension", draft-banghart-sacm-rolie- 674 softwaredescriptor-00 (work in progress), October 2016. 676 [I-D.birkholz-tuda] 677 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 678 "Time-Based Uni-Directional Attestation", draft-birkholz- 679 tuda-03 (work in progress), January 2017. 681 [I-D.greevenbosch-appsawg-cbor-cddl] 682 Vigano, C. and H. Birkholz, "CBOR data definition language 683 (CDDL): a notational convention to express CBOR data 684 structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work 685 in progress), September 2016. 687 Authors' Addresses 689 Henk Birkholz 690 Fraunhofer SIT 691 Rheinstrasse 75 692 Darmstadt 64295 693 Germany 695 Email: henk.birkholz@sit.fraunhofer.de 697 Jessica Fitzgerald-McKay 698 Department of Defense 699 9800 Savage Road 700 Ft. Meade, Maryland 701 USA 703 Email: jmfitz2@nsa.gov 704 Charles Schmidt 705 The MITRE Corporation 706 202 Burlington Road 707 Bedford, Maryland 01730 708 USA 710 Email: cmschmidt@mitre.org 712 David Waltermire 713 National Institute of Standards and Technology 714 100 Bureau Drive 715 Gaithersburg, Maryland 20877 716 USA 718 Email: david.waltermire@nist.gov