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