idnits 2.17.1 draft-ietf-opsawg-sbom-access-03.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 == Line 271 has weird spacing: '...on-info str...' -- The document date (24 October 2021) is 908 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) == Unused Reference: 'RFC6991' is defined on line 735, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track S. Rose 5 Expires: 27 April 2022 NIST 6 24 October 2021 8 Discovering and Retrieving Software Transparency and Vulnerability 9 Information 10 draft-ietf-opsawg-sbom-access-03 12 Abstract 14 To improve cybersecurity posture, automation is necessary to locate 15 what software is running on a device, whether that software has known 16 vulnerabilities, and what, if any recommendations suppliers may have. 17 This memo specifies a model to provide access to this information. 18 It may optionally be discovered through manufacturer usage 19 descriptions. 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 https://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 27 April 2022. 38 Copyright Notice 40 Copyright (c) 2021 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Cases Not Addressed . . . . . . . . . . . . . . . . . . . 4 56 1.2. How This Information Is Retrieved . . . . . . . . . . . . 5 57 1.3. Formats . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.4. Discussion points . . . . . . . . . . . . . . . . . . . . 5 59 2. The .well-known/transparency endpoint set . . . . . . . . . . 6 60 3. The mud-transparency extension model extension . . . . . . . 6 61 4. The mud-sbom augmentation to the MUD YANG model . . . . . . . 7 62 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 5.1. Without ACLS . . . . . . . . . . . . . . . . . . . . . . 10 64 5.2. SBOM Located on the Device . . . . . . . . . . . . . . . 12 65 5.3. Further contact required. . . . . . . . . . . . . . . . . 13 66 5.4. With ACLS . . . . . . . . . . . . . . . . . . . . . . . . 14 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 7.1. MUD Extension . . . . . . . . . . . . . . . . . . . . . . 17 70 7.2. Well-Known Prefix . . . . . . . . . . . . . . . . . . . . 17 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 73 8.2. Informative References . . . . . . . . . . . . . . . . . 18 74 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 18 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 77 1. Introduction 79 A number of activities have been working to improve visibility to 80 what software is running on a system, and what vulnerabilities that 81 software may have. 83 Put simply, we seek to answer two classes of questions *at scale*: 85 * Is this system vulnerable to a particular vulnerability? 87 * Which devices in a particular environment contain vulnerabilities 88 that require some action? 90 Software bills of materials (SBOMs) are descriptions of what 91 software, including versioning and dependencies, a device contains. 92 There are different SBOM formats such as Software Package Data 93 Exchange [SPDX] or CycloneDX[CycloneDX12]. 95 System vulnerabilities may similarly be described using several data 96 formats, including the aforementioned CycloneDX, Common Vulnerability 97 Reporting Framework [CVRF], the Common Security Advisory Format 98 [CSAF]. This information is typically used to report to customers 99 the state of a system. 101 These two classes of information can be used in concert. For 102 instance, a network management tool may discover that a system makes 103 use of a particular software component that has a known 104 vulnerability, and a vulnerability report may be used to indicate 105 what if any versions of software correct that vulnerability, or 106 whether the system exercises the vulnerable code at all. 108 Both classes of information elements are optional under the model 109 specified in this memo. One can provide only an SBOM, only 110 vulnerability information, or both an SBOM and vulnerability 111 information. 113 Note that SBOM formats may also carry other information, the most 114 common being any licensing terms. Because this specification is 115 neutral regarding content, it is left for format developers such as 116 the Linux Foundation, OASIS, and ISO to decide what attributes they 117 will support. 119 This specification does not allow for vulnerability information to be 120 retrieved directly from the endpoint. That's because vulnerability 121 information changes occur at different rates to software updates. 123 SBOMs and vulnerability information are advertised and retrieved 124 through the use of a YANG augmentation of the Manufacturer User 125 Description (MUD) model [RFC8520]. Note that the schema creates a 126 grouping that can also be used independently of MUD. Moreover, other 127 MUD features, such as access controls, needn't be present. 129 The mechanisms specified in this document are meant to satisfy 130 several use cases: 132 * A network-layer management system retrieving information from an 133 IoT device as part of its ongoing lifecycle. Such devices may or 134 may not have query interfaces available. 136 * An application-layer management system retrieving vulnerability or 137 SBOM information in order to evaluate the posture of an 138 application server of some form. These application servers may 139 themselves be containers or hypervisors. Discovery of the 140 topology of a server is beyond the scope of this memo. 142 To satisfy these two key use cases, objects may be found in one of 143 three ways: 145 * on devices themselves 147 * on a web site (e.g., via URI) 149 * through some form of out-of-band contact with the supplier. 151 In the first case, devices will have interfaces that permit direct 152 retrieval. Examples of these interfaces might be an HTTP, COAP or 153 [OpenC2] endpoint for retrieval. There may also be private 154 interfaces as well. 156 In the second case, when a device does not have an appropriate 157 retrieval interface, but one is directly available from the 158 manufacturer, a URI to that information must be discovered. 160 In the third case, a supplier may wish to make an SBOM or 161 vulnerability information available under certain circumstances, and 162 may need to individually evaluate requests. The result of that 163 evaluation might be the SBOM or vulnerability itself or a restricted 164 URL or no access. 166 To enable application-layer discovery, this memo defines a well-known 167 URI [RFC8615]. Management or orchestration tools can query this 168 well-known URI to retrieve a system's SBOM or vulnerability 169 information. Further queries may be necessary based on the content 170 and structure of the response. 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 1.1. Cases Not Addressed 180 [ This section to be removed prior to publication ] 182 A separate use case may be addressed in future versions of this 183 document: 185 * Related to the application layer, software as a service may 186 involve multiple backend systems, depending on many factors. One 187 example might be a large cloud-based service that offers 188 spreadsheets, email, and document authoring and management. 189 Depending on what service is being used, a different set of back 190 end services may in turn be invoking different software that 191 should be listed. 193 The reason why this use case isn't addressed here is that it may be 194 better addressed inline within HTML. Further discussion is required. 196 1.2. How This Information Is Retrieved 198 For devices that can emit a URL or can establish a well-known URI, 199 the mechanism may be highly automated. For devices that have a URL 200 in either their documentation or within a QR code on a box, the 201 mechanism is semi-automated (someone has to scan the QR code or enter 202 the URL). 204 Note that vulnerability and SBOM information is likely to change at 205 different rates. The MUD semantics provide a way for manufacturers 206 to control how often tooling should check for those changes through 207 the cache-validity node. 209 1.3. Formats 211 There are multiple ways to express both SBOMs and vulnerability 212 information. When these are retrieved either directly from the 213 device or directly from a web server, tools will need to observe the 214 content-type header to determine precisely which format is being 215 transmitted. Because IoT devices in particular have limited 216 capabilities, use of a specific Accept: header in HTTP or the Accept 217 Option in CoAP is NOT RECOMMENDED. Instead, backend tooling is 218 encouraged to support all known formats, and SHOULD silently discard 219 SBOM information sent with a media type that is not understood. 221 Some formats may support both vulnerability and software inventory 222 information. When both vulnerability and software inventory 223 information is available from the same location, both sbom and vuln 224 nodes MUST indicate that. Network management systems retrieving this 225 information MUST take note that the identical resource is being 226 retrieved rather than retrieving it twice. 228 1.4. Discussion points 230 The following is discussion to be removed at time of RFC publication. 232 * Is the model structured correctly? 233 * Are there other retrieval mechanisms that need to be specified? 235 * Do we need to be more specific in how to authenticate and retrieve 236 SBOMs? 238 * What are the implications if the MUD URL is an extension in a 239 certificate (e.g. an IDevID cert)? 241 2. The .well-known/transparency endpoint set 243 Two well known endpoints are defined: 245 * "/.well-known/sbom" retrieves an SBOM. 247 * "/.well-known/openc2" is the HTTPS binding to OpenC2. 249 As discussed previously, the precise format of a response is based on 250 the Content-type provided. 252 3. The mud-transparency extension model extension 254 We now formally define this extension. This is done in two parts. 255 First, the extension name "transparency" is listed in the 256 "extensions" array of the MUD file. N.B., this schema extension is 257 intended to be used wherever it might be appropriate (e.g., not just 258 MUD). 260 Second, the "mud" container is augmented with a list of SBOM sources. 262 This is done as follows: 264 module: ietf-mud-transparency 266 augment /mud:mud: 267 +--rw transparency 268 +--rw (sbom-retrieval-method)? 269 | +--:(cloud) 270 | | +--rw sboms* [version-info] 271 | | +--rw version-info string 272 | | +--rw sbom-url? inet:uri 273 | +--:(local-well-known) 274 | | +--rw sbom-local-well-known? enumeration 275 | +--:(sbom-contact-info) 276 | +--rw sbom-contact-uri inet:uri 277 +--rw (vuln-retrieval-method)? 278 +--:(cloud) 279 | +--rw vuln-url? inet:uri 280 +--:(vuln-contact-info) 281 +--rw contact-uri inet:uri 283 4. The mud-sbom augmentation to the MUD YANG model 285 286 file "ietf-mud-transparency@2021-10-22.yang" 287 module ietf-mud-transparency { 288 yang-version 1.1; 289 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-transparency"; 290 prefix mud-transparency; 292 import ietf-inet-types { 293 prefix inet; 294 reference "RFC 6991"; 295 } 296 import ietf-mud { 297 prefix mud; 298 reference "RFC 8520"; 299 } 301 organization 302 "IETF OPSAWG (Ops Area) Working Group"; 303 contact 304 "WG Web: http://tools.ietf.org/wg/opsawg/ 305 WG List: opsawg@ietf.org 307 Editor: Eliot Lear lear@cisco.com 308 Editor: Scott Rose scott.rose@nist.gov"; 309 description 310 "This YANG module augments the ietf-mud model to provide for 311 reporting of SBOMs. 313 Copyright (c) 2020 IETF Trust and the persons identified as 314 authors of the code. All rights reserved. 316 Redistribution and use in source and binary forms, with or 317 without modification, is permitted pursuant to, and subject to 318 the license terms contained in, the Simplified BSD License set 319 forth in Section 4.c of the IETF Trust's Legal Provisions 320 Relating to IETF Documents 321 (https://trustee.ietf.org/license-info). 323 This version of this YANG module is part of RFC XXXX 324 (https://www.rfc-editor.org/info/rfcXXXX); 325 see the RFC itself for full legal notices. 327 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 328 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 329 'MAY', and 'OPTIONAL' in this document are to be interpreted as 330 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 331 they appear in all capitals, as shown here. "; 333 revision 2021-07-06 { 334 description 335 "Initial proposed standard."; 336 reference 337 "RFC XXXX: Extension for software transparency"; 338 } 340 grouping transparency-extension { 341 description 342 "Transparency extension grouping"; 343 container transparency { 344 description 345 "container of methods to get an SBOM."; 346 choice sbom-retrieval-method { 347 description 348 "How to find SBOM information"; 349 case cloud { 350 list sboms { 351 key "version-info"; 352 description 353 "A list of SBOMs tied to different s/w 354 or h/w versions."; 355 leaf version-info { 356 type string; 357 description 358 "The version to which this SBOM refers."; 359 } 360 leaf sbom-url { 361 type inet:uri; 362 description 363 "A statically located URI."; 364 } 365 } 366 } 367 case local-well-known { 368 leaf sbom-local-well-known { 369 type enumeration { 370 enum http { 371 description 372 "Use http (insecure) to retrieve 373 SBOM information."; 374 } 375 enum https { 376 description 377 "Use https (secure) to retrieve SBOM information."; 378 } 379 enum coap { 380 description 381 "Use COAP (insecure) to retrieve SBOM"; 382 } 383 enum coaps { 384 description 385 "Use COAPS (secure) to retrieve SBOM"; 386 } 387 enum openc2 { 388 description 389 "Use OpenC2 endpoint. 390 This is https://{host}/.well-known/openc2"; 391 } 392 } 393 description 394 "Which communication protocol to choose."; 395 } 396 } 397 case sbom-contact-info { 398 leaf sbom-contact-uri { 399 type inet:uri; 400 mandatory true; 401 description 402 "This MUST be either a tel, http, https, or 403 mailto uri schema that customers can use to 404 contact someone for SBOM information."; 405 } 406 } 407 } 408 choice vuln-retrieval-method { 409 description 410 "How to find vulnerability information"; 411 case cloud { 412 leaf vuln-url { 413 type inet:uri; 414 description 415 "A statically located URL."; 416 } 417 } 418 case vuln-contact-info { 419 leaf contact-uri { 420 type inet:uri; 421 mandatory true; 422 description 423 "This MUST be either a tel, http, https, or 424 mailto uri schema that customers can use to 425 contact someone for vulnerability information."; 426 } 427 } 428 } 429 } 430 } 432 augment "/mud:mud" { 433 description 434 "Add extension for software transparency."; 435 uses transparency-extension; 436 } 437 } 438 440 5. Examples 442 In this example MUD file that uses a cloud service, the modelX 443 presents a location of the SBOM in a URL. Note, the ACLs in a MUD 444 file are NOT required, although they are a very good idea for IP- 445 based devices. 447 5.1. Without ACLS 449 This first MUD file demonstrates how to get SBOM and vulnerability 450 information without ACLs. 452 { 453 "ietf-mud:mud": { 454 "mud-version": 1, 455 "extensions": [ 456 "transparency" 457 ], 458 "ietf-mud-transparency:transparency": { 459 "sboms": [ 460 { 461 "version-info": "ExOS1.1", 462 "sbom-url": "https://iot.example.com/info/modelX/sbom.json" 463 } 464 ], 465 "vuln-url": "https://iot.example.com/info/modelX/csaf.json" 466 }, 467 "mud-url": "https://iot.example.com/modelX.json", 468 "mud-signature": "https://iot.example.com/modelX.p7s", 469 "last-update": "2021-07-09T05:57:58+00:00", 470 "cache-validity": 48, 471 "is-supported": true, 472 "systeminfo": "retrieving vuln and SBOM info via a cloud service", 473 "mfg-name": "Example, Inc.", 474 "documentation": "https://iot.example.com/doc/modelX", 475 "model-name": "modelX" 476 } 477 } 479 The second example demonstrates that just SBOM information is 480 included. 482 { 483 "ietf-mud:mud": { 484 "mud-version": 1, 485 "extensions": [ 486 "transparency" 487 ], 488 "ietf-mud-transparency:transparency": { 489 "sboms": [ 490 { 491 "version-info": "ExOS1.1", 492 "sbom-url": "https://iot.example.com/info/modelX/sbom.json" 493 } 494 ] 495 }, 496 "mud-url": "https://iot.example.com/modelX.json", 497 "mud-signature": "https://iot.example.com/modelX.p7s", 498 "last-update": "2021-07-09T06:03:21+00:00", 499 "cache-validity": 48, 500 "is-supported": true, 501 "systeminfo": "retrieving vuln and SBOM info via a cloud service", 502 "mfg-name": "Example, Inc.", 503 "documentation": "https://iot.example.com/doc/modelX", 504 "model-name": "modelX" 505 } 506 } 508 5.2. SBOM Located on the Device 510 In this example, the SBOM is retrieved from the device, while 511 vulnerability information is available from the cloud. This is 512 likely a common case, because vendors may learn of vulnerability 513 information more frequently than they update software. 515 { 516 "ietf-mud:mud": { 517 "mud-version": 1, 518 "extensions": [ 519 "ol", 520 "transparency" 521 ], 522 "ol": { 523 "owners": [ 524 "Copyright (c) Example, Inc. 2021. All Rights Reserved" 525 ], 526 "spdx-tag": "0BSD" 527 }, 528 "ietf-mud-transparency:transparency": { 529 "sbom-local-well-known": "https", 530 "vuln-url": "https://iot-device.example.com/info/modelX/csaf.json" 531 }, 532 "mud-url": "https://iot-device.example.com/modelX.json", 533 "mud-signature": "https://iot-device.example.com/modelX.p7s", 534 "last-update": "2021-07-09T06:06:13+00:00", 535 "cache-validity": 48, 536 "is-supported": true, 537 "systeminfo": "retrieving vuln and SBOM info via a cloud service", 538 "mfg-name": "Example, Inc.", 539 "documentation": "https://iot-device.example.com/doc/modelX", 540 "model-name": "modelX" 541 } 542 } 544 5.3. Further contact required. 546 In this example, the network manager must take further steps to 547 retrieve SBOM information. Vulnerability information is still 548 available. 550 { 551 "ietf-mud:mud": { 552 "mud-version": 1, 553 "extensions": [ 554 "transparency" 555 ], 556 "ietf-mud-transparency:transparency": { 557 "contact-info": "https://iot-device.example.com/contact-info.html", 558 "vuln-url": "https://iot-device.example.com/info/modelX/csaf.json" 559 }, 560 "mud-url": "https://iot-device.example.com/modelX.json", 561 "mud-signature": "https://iot-device.example.com/modelX.p7s", 562 "last-update": "2021-07-09T06:16:42+00:00", 563 "cache-validity": 48, 564 "is-supported": true, 565 "systeminfo": "retrieving vuln and SBOM info via a cloud service", 566 "mfg-name": "Example, Inc.", 567 "documentation": "https://iot-device.example.com/doc/modelX", 568 "model-name": "modelX" 569 } 570 } 572 5.4. With ACLS 574 Finally, here is a complete example where the device provides SBOM 575 and vulnerability information, as well as access-control information. 577 { 578 "ietf-mud:mud": { 579 "mud-version": 1, 580 "extensions": [ 581 "transparency" 582 ], 583 "ietf-mud-transparency:transparency": { 584 "sboms": [ 585 { 586 "version-info": "ExOS1.1", 587 "sbom-url": "https://iot.example.com/info/modelX/sbom.json" 588 } 589 ], 590 "vuln-url": "https://iot.example.com/info/modelX/csaf.json" 591 }, 592 "mud-url": "https://iot.example.com/modelX.json", 593 "mud-signature": "https://iot.example.com/modelX.p7s", 594 "last-update": "2021-07-09T06:19:39+00:00", 595 "cache-validity": 48, 596 "is-supported": true, 597 "systeminfo": "retrieving vuln and SBOM info via a cloud service", 598 "mfg-name": "Example, Inc.", 599 "documentation": "https://iot.example.com/doc/modelX", 600 "model-name": "modelX", 601 "from-device-policy": { 602 "access-lists": { 603 "access-list": [ 604 { 605 "name": "mud-15060-v4fr" 606 } 607 ] 608 } 609 }, 610 "to-device-policy": { 611 "access-lists": { 612 "access-list": [ 613 { 614 "name": "mud-15060-v4to" 615 } 616 ] 617 } 618 } 619 }, 620 "ietf-access-control-list:acls": { 621 "acl": [ 622 { 623 "name": "mud-15060-v4to", 624 "type": "ipv4-acl-type", 625 "aces": { 626 "ace": [ 627 { 628 "name": "cl0-todev", 629 "matches": { 630 "ipv4": { 631 "ietf-acldns:src-dnsname": "cloud.example.com" 632 } 633 }, 634 "actions": { 635 "forwarding": "accept" 636 } 637 } 638 ] 639 } 640 }, 641 { 642 "name": "mud-15060-v4fr", 643 "type": "ipv4-acl-type", 644 "aces": { 645 "ace": [ 646 { 647 "name": "cl0-frdev", 648 "matches": { 649 "ipv4": { 650 "ietf-acldns:dst-dnsname": "cloud.example.com" 651 } 652 }, 653 "actions": { 654 "forwarding": "accept" 655 } 656 } 657 ] 658 } 659 } 660 ] 661 } 662 } 664 At this point, the management system can attempt to retrieve the 665 SBOM, and determine which format is in use through the content-type 666 header on the response to a GET request, independently repeat the 667 process for vulnerability information, and apply ACLs, as 668 appropriate. 670 6. Security Considerations 672 SBOMs provide an inventory of software. If firmware is available to 673 an attacker, the attacker may well already be able to derive this 674 very same software inventory. Manufacturers MAY restrict access to 675 SBOM information using appropriate authorization semantics within 676 HTTP. In particular, if a system attempts to retrieve an SBOM via 677 HTTP and the client is not authorized, the server MUST produce an 678 appropriate error, with instructions on how to register a particular 679 client. One example may be to issue a certificate to the client for 680 this purpose after a registration process has taken place. Another 681 example would involve the use of OAUTH in combination with a 682 federations of SBOM servers. 684 Another risk is a skew in the SBOM listing and the actual software 685 inventory of a device/container. For example, a manufacturer may 686 update the SBOM on its server, but an individual device has not been 687 upgraded yet. This may result in an incorrect policy being applied 688 to a device. A unique mapping of a device's firmware version and its 689 SBOM can minimize this risk. 691 To further mitigate attacks against a device, manufacturers SHOULD 692 recommend access controls through the normal MUD mechanism. 694 Vulnerability information is generally made available to such 695 databases as NIST's National Vulnerability Database. It is possible 696 that vendor may wish to release information early to some customers. 697 We do not discuss here whether that is a good idea, but if it is 698 employed, then appropriate access controls and authorization would be 699 applied to the vulnerability resource. 701 7. IANA Considerations 703 7.1. MUD Extension 705 The IANA is requested to add "transparency" to the MUD extensions 706 registry as follows: 708 Extension Name: transparency 709 Standard reference: This document 711 7.2. Well-Known Prefix 713 The following well known URIs are requested in accordance with 714 [RFC8615]: 716 URI suffix: "sbom" 717 Change controller: "IETF" 718 Specification document: This memo 719 Related information: See ISO/IEC 19970-2 and SPDX.org 721 URI suffix: "openc2" 722 Change controller: "IETF" 723 Specification document: This memo 724 Related information: OpenC2 Project 726 8. References 728 8.1. Normative References 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, 732 DOI 10.17487/RFC2119, March 1997, 733 . 735 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 736 RFC 6991, DOI 10.17487/RFC6991, July 2013, 737 . 739 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 740 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 741 May 2017, . 743 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 744 Description Specification", RFC 8520, 745 DOI 10.17487/RFC8520, March 2019, 746 . 748 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 749 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 750 . 752 8.2. Informative References 754 [CSAF] OASIS, "Common Security Advisory Format", July 2021, 755 . 757 [CVRF] Santos, O., Ed., "Common Vulnerability Reporting Framework 758 (CVRF) Version 1.2", September 2017, . 761 [CycloneDX12] 762 cylonedx.org, "CycloneDX XML Reference v1.2", May 2020. 764 [OpenC2] Lemire, D., Ed., "Specification for Transfer of OpenC2 765 Messages via HTTPS Version 1.0", July 2019, 766 . 769 [SPDX] The Linux Foundation, "SPDX Specification 2.1", 2016. 771 Appendix A. Changes from Earlier Versions 773 Draft -02: 775 * include vulnerability information 777 Draft -01: 779 * some modest changes 781 Draft -00: 783 * Initial revision 785 Authors' Addresses 786 Eliot Lear 787 Cisco Systems 788 Richtistrasse 7 789 CH-8304 Wallisellen 790 Switzerland 792 Phone: +41 44 878 9200 793 Email: lear@cisco.com 795 Scott Rose 796 NIST 797 100 Bureau Dr 798 Gaithersburg MD, 20899 799 United States of America 801 Phone: +1 301-975-8439 802 Email: scott.rose@nist.gov