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