doc: Add RFC documents

1 files changed, 956 insertions, 0 deletions

diff --git a/doc/rfc/rfc9472.txt b/doc/rfc/rfc9472.txt
new file mode 100644
index 0000000..93ebc9f
--- /dev/null
+++ b/doc/rfc/rfc9472.txt
@@ -0,0 +1,956 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                           E. Lear
+Request for Comments: 9472                                 Cisco Systems
+Category: Standards Track                                        S. Rose
+ISSN: 2070-1721                                                     NIST
+                                                            October 2023
+
+
+A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and
+                       Vulnerability Information
+
+Abstract
+
+   To improve cybersecurity posture, automation is necessary to locate
+   the software a device is using, whether that software has known
+   vulnerabilities, and what, if any, recommendations suppliers may
+   have.  This memo extends the Manufacturer User Description (MUD) YANG
+   schema to provide the locations of software bills of materials
+   (SBOMs) and vulnerability information by introducing a transparency
+   schema.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9472.
+
+Copyright Notice
+
+   Copyright (c) 2023 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Requirements Language
+     1.2.  How This Information Is Retrieved
+     1.3.  Formats
+   2.  The Well-Known Transparency Endpoint Set
+   3.  The mud-transparency Extension
+   4.  The mud-sbom Augmentation to the MUD YANG Data Model
+   5.  Examples
+     5.1.  Without ACLS
+     5.2.  SBOM Located on the Device
+     5.3.  Further Contact Required
+     5.4.  With ACLS
+   6.  Security Considerations
+   7.  IANA Considerations
+     7.1.  MUD Extension
+     7.2.  YANG Registration
+     7.3.  Well-Known Prefix
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   A number of activities have taken place to improve the visibility of
+   what software is running on a system and what vulnerabilities that
+   software may have [EO2021].
+
+   Put simply, this memo seeks to answer two classes of questions for
+   tens of thousands of devices and a large variety of device types.
+   Those questions are as follows:
+
+   *  Is this system susceptible to a particular vulnerability?
+
+   *  Which devices in a particular environment contain vulnerabilities
+      that require some action?
+
+   This memo doesn't specify the format of this information but rather
+   only how to locate and retrieve these objects.  That is, the model is
+   intended to facilitate discovery and on its own provides no access to
+   the underlying data.
+
+   Software bills of materials (SBOMs) are descriptions of what
+   software, including versioning and dependencies, a device contains.
+   There are different SBOM formats such as Software Package Data
+   Exchange [SPDX] or CycloneDX [CycloneDX15].
+
+   System vulnerabilities may be similarly described using several data
+   formats, including the aforementioned CycloneDX, the Common
+   Vulnerability Reporting Framework [CVRF], and the Common Security
+   Advisory Format [CSAF].  This information is typically used to report
+   the state of any known vulnerabilities on a system to administrators.
+
+   SBOM and vulnerability information can be used in concert with other
+   sources of vulnerability information.  A network management tool
+   could discover that a system uses a particular set of software
+   components, searches a national vulnerability database to determine
+   known vulnerabilities, and applies information provided by the
+   manufacturer through this mechanism to produce a vulnerability
+   report.  That report may be used to indicate what, if any, versions
+   of software correct that vulnerability or whether the system
+   exercises the vulnerable code at all.
+
+   Both classes of information elements are optional under the model
+   specified in this memo.  One can provide only an SBOM, only
+   vulnerability information, or both an SBOM and vulnerability
+   information.
+
+   Note that SBOM formats may also carry other information, the most
+   common being any licensing terms.  Because this specification is
+   neutral regarding content, it is left for format developers such as
+   the Linux Foundation, OASIS, and ISO to decide what attributes they
+   will support.
+
+   This memo does not specify how vulnerability information may be
+   retrieved directly from the endpoint.  That is because vulnerability
+   information changes occur to software updates at different rates.
+   However, some SBOM formats may also contain vulnerability
+   information.
+
+   SBOMs and vulnerability information are advertised and retrieved
+   through the use of a YANG augmentation of the Manufacturer User
+   Description (MUD) model [RFC8520].  Note that the schema creates a
+   grouping that can also be used independently of MUD.  Moreover, other
+   MUD features, such as access controls, needn't be present.
+
+   The mechanisms specified in this document are meant to address two
+   use cases:
+
+   *  A network-layer management system retrieving information from an
+      Internet of Things (IoT) device as part of its ongoing life cycle.
+      Such devices may or may not have query interfaces available.
+
+   *  An application-layer management system retrieving vulnerability or
+      SBOM information in order to evaluate the posture of an
+      application server of some form.  These application servers may
+      themselves be containers or hypervisors.  Discovery of the
+      topology of a server is beyond the scope of this memo.
+
+   To satisfy these two key use cases, objects may be found in one of
+   three methods:
+
+   1.  on the devices themselves
+
+   2.  on a website (e.g., via a URI)
+
+   3.  through some form of out-of-band contact with the supplier
+
+   Using the first method, devices will have interfaces that permit
+   direct retrieval.  Examples of these interfaces might be an HTTP
+   [RFC9110] or Constrained Application Protocol (CoAP) [RFC7252]
+   endpoint for retrieval.  There may also be private interfaces as
+   well.
+
+   Using the second method, when a device does not have an appropriate
+   retrieval interface, but one is directly available from the
+   manufacturer, a URI to that information is discovered through
+   interfaces such as MUD via DHCP or bootstrapping and ownership
+   transfer mechanisms.
+
+   Using the third method, a supplier may wish to make an SBOM or
+   vulnerability information available under certain circumstances and
+   may need to individually evaluate requests.  The result of that
+   evaluation might be the SBOM, the vulnerability itself, a restricted
+   URL, or no access.
+
+   To enable application-layer discovery, this memo defines a well-known
+   URI [RFC8615].  Management or orchestration tools can query this
+   well-known URI to retrieve a system's SBOM information.  Further
+   queries may be necessary based on the content and structure of the
+   response.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+1.2.  How This Information Is Retrieved
+
+   Section 4 describes a data model to extend the MUD file format to
+   carry SBOM and vulnerability information.  Section 1.5 of [RFC8520]
+   describes mechanisms by which devices can emit a URL to point to this
+   file.  Additionally, devices can share this URL either through
+   documentation or within a QR code on a box.  Section 2 describes a
+   well-known URL from which an SBOM could be served from the local
+   device.
+
+   Note that vulnerability and SBOM information are likely to change at
+   different rates.  MUD's cache-validity node provides a way for
+   manufacturers to control how often tooling should check for those
+   changes through the cache-validity node.
+
+1.3.  Formats
+
+   There are multiple ways to express both SBOMs and vulnerability
+   information.  When these are retrieved either from the device or from
+   a remote web server, tools will need to observe the Content-Type
+   header to determine precisely which format is being transmitted.
+   Because IoT devices in particular have limited capabilities, use of a
+   specific Accept: header in HTTP or the Accept Option in CoAP is NOT
+   RECOMMENDED.  Instead, backend tooling is encouraged to support all
+   known formats and SHOULD silently discard SBOM information sent with
+   a media type that is not understood.
+
+   If multiple SBOMs are intended to be supported in the same file, the
+   media type should properly reflect that.  For example, one might make
+   use of application/{someformat}+json-seq.  It is left to those
+   supporting those formats to make the appropriate registrations in
+   this case.
+
+   Some formats may support both vulnerability and software inventory
+   information.  When both vulnerability and software inventory
+   information is available from the same URL, both sbom-url and members
+   of the vuln-url list MUST indicate that.  Network management systems
+   MUST take note of when the SBOM and vulnerability information are
+   accessible via the same resource and not retrieve the resource a
+   second time.
+
+2.  The Well-Known Transparency Endpoint Set
+
+   A well-known endpoint is defined:
+
+      "/.well-known/sbom" retrieves an SBOM
+
+   As discussed previously, the precise format of a response is based on
+   the Content-Type provided.
+
+3.  The mud-transparency Extension
+
+   We now formally define the mud-transparency extension; this is done
+   in two parts.
+
+   First, the extension name "transparency" is listed in the
+   "extensions" array of the MUD file.  Note that this schema extension
+   is intended to be used wherever it might be appropriate (e.g., not
+   just with MUD).
+
+   Second, the "mud" container is augmented with a list of SBOM sources.
+
+   This is done as follows:
+
+   module: ietf-mud-transparency
+
+     augment /mud:mud:
+       +--rw transparency
+          +--rw (sbom-retrieval-method)?
+          |  +--:(cloud)
+          |  |  +--rw sboms* [version-info]
+          |  |     +--rw version-info    string
+          |  |     +--rw sbom-url?       inet:uri
+          |  +--:(local-well-known)
+          |  |  +--rw sbom-local-well-known?   identityref
+          |  +--:(sbom-contact-info)
+          |     +--rw sbom-contact-uri?        inet:uri
+          +--rw sbom-archive-list?             inet:uri
+          +--rw (vuln-retrieval-method)?
+             +--:(cloud)
+             |  +--rw vuln-url*                inet:uri
+             +--:(vuln-contact-info)
+                +--rw vuln-contact-uri?        inet:uri
+
+   See [RFC8340] for a description of YANG trees.
+
+4.  The mud-sbom Augmentation to the MUD YANG Data Model
+
+   This YANG module references [RFC6991], [RFC7231], [RFC7252],
+   [RFC8520], and [RFC9110].
+
+   <CODE BEGINS> file "ietf-mud-transparency@2023-10-10.yang"
+   module ietf-mud-transparency {
+     yang-version 1.1;
+     namespace "urn:ietf:params:xml:ns:yang:ietf-mud-transparency";
+     prefix mudtx;
+
+     import ietf-inet-types {
+       prefix inet;
+       reference
+         "RFC 6991: Common YANG Data Types";
+     }
+     import ietf-mud {
+       prefix mud;
+       reference
+         "RFC 8520: Manufacturer Usage Description Specification";
+     }
+
+     organization
+       "IETF OPSAWG (Ops Area) Working Group";
+     contact
+       "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
+        WG List: <opsawg@ietf.org>
+
+        Editor: Eliot Lear <lear@cisco.com>
+        Editor: Scott Rose <scott.rose@nist.gov>";
+     description
+       "This YANG module augments the ietf-mud model to provide for
+        reporting of SBOMs and vulnerability information.
+
+        The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
+        NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
+        'MAY', and 'OPTIONAL' in this document are to be interpreted as
+        described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
+        they appear in all capitals, as shown here.
+
+        Copyright (c) 2023 IETF Trust and the persons identified as
+        authors of the code.  All rights reserved.
+
+        Redistribution and use in source and binary forms, with or
+        without modification, is permitted pursuant to, and subject to
+        the license terms contained in, the Revised BSD License set
+        forth in Section 4.c of the IETF Trust's Legal Provisions
+        Relating to IETF Documents
+        (https://trustee.ietf.org/license-info).
+
+        This version of this YANG module is part of RFC 9472
+        (https://www.rfc-editor.org/info/rfc9472);
+        see the RFC itself for full legal notices.";
+
+     revision 2023-10-10 {
+       description
+         "Initial proposed standard.";
+       reference
+         "RFC 9472: A YANG Data Model for Reporting Software Bills
+          of Materials (SBOMs) and Vulnerability Information";
+     }
+
+     identity local-type {
+       description
+         "Base identity for local well-known choices.";
+     }
+
+     identity http {
+       base mudtx:local-type;
+       description
+         "Use http (RFC 7231) (insecure) to retrieve SBOM information.
+           This method is NOT RECOMMENDED but may be unavoidable for
+           certain classes of deployment where TLS has not or
+           cannot be implemented.";
+         reference
+           "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1):
+            Semantics and Content";
+     }
+
+     identity https {
+       base mudtx:local-type;
+       description
+         "Use https (secure) to retrieve SBOM information.  See
+          RFC 9110.";
+         reference
+           "RFC 9110: HTTP Semantics";
+     }
+
+     identity coap {
+       base mudtx:local-type;
+       description
+         "Use COAP (RFC 7252) (insecure) to retrieve SBOM.  This method
+          is NOT RECOMMENDED, although it may be unavoidable
+          for certain classes of implementations/deployments.";
+         reference
+           "RFC 7252: The Constrained Application Protocol (CoAP)";
+     }
+
+     identity coaps {
+       base mudtx:local-type;
+       description
+         "Use COAPS (secure) to retrieve SBOM (RFC 7252).";
+     }
+
+     grouping transparency-extension {
+       description
+         "This grouping provides a means to describe the location of
+          software bills of material and vulnerability descriptions.";
+       container transparency {
+         description
+           "Container of methods to get SBOMs and vulnerability
+            information.";
+         choice sbom-retrieval-method {
+           description
+             "How to find SBOM information.";
+           case cloud {
+             list sboms {
+               key "version-info";
+               description
+                 "A list of SBOMs tied to different software
+                  or hardware versions.";
+               leaf version-info {
+                 type string;
+                 description
+                   "The version to which this SBOM refers.";
+               }
+               leaf sbom-url {
+                 type inet:uri {
+                   pattern '((coaps?)|(https?)):.*';
+                 }
+                 description
+                   "A statically located URL.";
+               }
+             }
+           }
+           case local-well-known {
+             leaf sbom-local-well-known {
+               type identityref {
+                 base mudtx:local-type;
+               }
+               description
+                 "Which communication protocol to choose.";
+             }
+           }
+           case sbom-contact-info {
+             leaf sbom-contact-uri {
+               type inet:uri {
+                 pattern '((mailto)|(https?)|(tel)):.*';
+               }
+               description
+                 "This MUST be a tel, an http, an https, or
+                  a mailto uri schema that customers can use to
+                  contact someone for SBOM information.";
+             }
+           }
+         }
+         leaf sbom-archive-list {
+           type inet:uri;
+           description
+             "This URI returns a JSON list of URLs that consist of
+              SBOMs that were previously published for this
+              device.  Publication dates can be found inside
+              the SBOMs.";
+         }
+         choice vuln-retrieval-method {
+           description
+             "How to find vulnerability information.";
+           case cloud {
+             leaf-list vuln-url {
+               type inet:uri;
+               description
+                 "List of statically located URLs that reference
+                  vulnerability information.";
+             }
+           }
+           case vuln-contact-info {
+             leaf vuln-contact-uri {
+               type inet:uri {
+                 pattern '((mailto)|(https?)|(tel)):.*';
+               }
+               description
+                 "This MUST be a tel, an http, an https, or
+                  a mailto uri schema that customers can use to
+                  contact someone for vulnerability information.";
+             }
+           }
+         }
+       }
+     }
+
+     augment "/mud:mud" {
+       description
+         "Add extension for software transparency.";
+       uses transparency-extension;
+     }
+   }
+   <CODE ENDS>
+
+5.  Examples
+
+   In this example MUD file that uses a cloud service, the modelX
+   presents a location of the SBOM in a URL.  Note that the Access
+   Control Lists (ACLs) in a MUD file are NOT required, although they
+   are a very good idea for IP-based devices.
+
+5.1.  Without ACLS
+
+   This first MUD file demonstrates how to get SBOM and vulnerability
+   information without ACLs.
+
+   {
+    "ietf-mud:mud": {
+      "mud-version": 1,
+      "extensions": [
+        "transparency"
+      ],
+      "mudtx:transparency": {
+        sboms: [ {
+        "version-info": "1.2",
+        "sbom-url": "https://iot.example.com/info/modelX/sbom.json"
+        } ],
+        "vuln-url" : [
+          "https://iotd.example.com/info/modelX/csaf.json"
+        ]
+      },
+      "mud-url": "https://iot.example.com/modelX.json",
+      "mud-signature": "https://iot.example.com/modelX.p7s",
+      "last-update": "2022-01-05T13:29:12+00:00",
+      "cache-validity": 48,
+      "is-supported": true,
+      "systeminfo": "retrieving vuln and SBOM info via a cloud service",
+      "mfg-name": "Example, Inc.",
+      "documentation": "https://iot.example.com/doc/modelX",
+      "model-name": "modelX"
+    }
+   }
+
+   The second example demonstrates that just SBOM information is
+   included from the cloud.
+
+   {
+    "ietf-mud:mud": {
+      "mud-version": 1,
+      "extensions": [
+        "transparency"
+      ],
+      "mudtx:transparency": {
+        sboms: [ {
+        "version-info": "1.2",
+        "sbom-url": "https://iot.example.com/info/modelX/sbom.json"
+        } ],
+      },
+      "mud-url": "https://iot.example.com/modelX.json",
+      "mud-signature": "https://iot.example.com/modelX.p7s",
+      "last-update": "2022-01-05T13:29:12+00:00",
+      "cache-validity": 48,
+      "is-supported": true,
+      "systeminfo": "retrieving vuln and SBOM info via a cloud service",
+      "mfg-name": "Example, Inc.",
+      "documentation": "https://iot.example.com/doc/modelX",
+      "model-name": "modelX"
+    }
+   }
+
+5.2.  SBOM Located on the Device
+
+   In the next example, the SBOM is located on the device, and there is
+   no vulnerability information provided.
+
+   {
+     "ietf-mud:mud": {
+       "mud-version": 1,
+       "extensions": [
+         "transparency"
+       ],
+       "mudtx:transparency": {
+         "sbom-local-well-known": "https"
+       },
+       "mud-url": "https://iot.example.com/modelX.json",
+       "mud-signature": "https://iot.example.com/modelX.p7s",
+       "last-update": "2022-01-05T13:29:47+00:00",
+       "cache-validity": 48,
+       "is-supported": true,
+       "systeminfo": "retrieving SBOM info from a local source",
+       "mfg-name": "Example, Inc.",
+       "documentation": "https://iot.example.com/doc/modelX",
+       "model-name": "modelX"
+     }
+   }
+
+   In this example, the SBOM is retrieved from the device, while
+   vulnerability information is available from the cloud.  This is
+   likely a common case because vendors may learn of vulnerability
+   information more frequently than they update software.
+
+   {
+    "ietf-mud:mud": {
+      "mud-version": 1,
+      "extensions": [
+        "transparency"
+      ],
+      "mudtx:transparency": {
+        "sbom-local-well-known": "https",
+        "vuln-url" : [
+          "https://iotd.example.com/info/modelX/csaf.json"
+        ]
+      },
+      "mud-url": "https://iot-device.example.com/modelX.json",
+      "mud-signature": "https://iot-device.example.com/modelX.p7s",
+      "last-update": "2022-01-05T13:25:14+00:00",
+      "cache-validity": 48,
+      "is-supported": true,
+      "systeminfo": "mixed example: SBOM on device, vuln info in cloud",
+      "mfg-name": "Example, Inc.",
+      "documentation": "https://iot-device.example.com/doc/modelX",
+      "model-name": "modelX"
+    }
+   }
+
+5.3.  Further Contact Required
+
+   In this example, the network manager must take further steps to
+   retrieve SBOM information.  Vulnerability information is still
+   available.
+
+   {
+   "ietf-mud:mud": {
+   "mud-version": 1,
+   "extensions": [
+     "transparency"
+   ],
+   "mudtx:transparency": {
+     "contact-info": "https://iot-device.example.com/contact-info.html",
+       "vuln-url" : [
+         "https://iotd.example.com/info/modelX/csaf.json"
+       ]
+   },
+   "mud-url": "https://iot-device.example.com/modelX.json",
+   "mud-signature": "https://iot-device.example.com/modelX.p7s",
+   "last-update": "2021-07-09T06:16:42+00:00",
+   "cache-validity": 48,
+   "is-supported": true,
+   "systeminfo": "retrieving vuln and SBOM info via a cloud service",
+   "mfg-name": "Example, Inc.",
+   "documentation": "https://iot-device.example.com/doc/modelX",
+   "model-name": "modelX"
+   }
+   }
+
+5.4.  With ACLS
+
+   Finally, here is a complete example where the device provides SBOM
+   and vulnerability information as well as access control information.
+
+   {
+    "ietf-mud:mud": {
+      "mud-version": 1,
+      "extensions": [
+        "transparency"
+      ],
+      "mudtx:transparency": {
+        "sbom-local-well-known": "https",
+        "vuln-url" : [
+          "https://iotd.example.com/info/modelX/csaf.json"
+        ]
+      },
+      "mud-url": "https://iot.example.com/modelX.json",
+      "mud-signature": "https://iot.example.com/modelX.p7s",
+      "last-update": "2022-01-05T13:30:31+00:00",
+      "cache-validity": 48,
+      "is-supported": true,
+      "systeminfo": "retrieving vuln and SBOM info via a cloud service",
+      "mfg-name": "Example, Inc.",
+      "documentation": "https://iot.example.com/doc/modelX",
+      "model-name": "modelX",
+      "from-device-policy": {
+        "access-lists": {
+          "access-list": [
+            {
+              "name": "mud-65443-v4fr"
+            }
+          ]
+        }
+      },
+      "to-device-policy": {
+        "access-lists": {
+          "access-list": [
+            {
+              "name": "mud-65443-v4to"
+            }
+          ]
+        }
+      }
+    },
+    "ietf-access-control-list:acls": {
+      "acl": [
+        {
+          "name": "mud-65443-v4to",
+          "type": "ipv4-acl-type",
+          "aces": {
+            "ace": [
+              {
+                "name": "cl0-todev",
+                "matches": {
+                  "ipv4": {
+                    "ietf-acldns:src-dnsname": "iotserver.example.com"
+                  }
+                },
+                "actions": {
+                  "forwarding": "accept"
+                }
+              }
+            ]
+          }
+        },
+        {
+          "name": "mud-65443-v4fr",
+          "type": "ipv4-acl-type",
+          "aces": {
+            "ace": [
+              {
+                "name": "cl0-frdev",
+                "matches": {
+                  "ipv4": {
+                    "ietf-acldns:dst-dnsname": "iotserver.example.com"
+                  }
+                },
+                "actions": {
+                  "forwarding": "accept"
+                }
+              }
+            ]
+          }
+        }
+      ]
+    }
+   }
+
+   At this point, the management system can attempt to retrieve the
+   SBOM, determine which format is in use through the Content-Type
+   header on the response to a GET request, independently repeat the
+   process for vulnerability information, and apply ACLs as appropriate.
+
+6.  Security Considerations
+
+   This document describes a schema for discovering the location of
+   information relating to software transparency and does not specify
+   the access model for the information itself.  In particular, the YANG
+   module specified in this document is not necessarily intended to be
+   accessed via regular network management protocols, such as NETCONF
+   [RFC6241] or RESTCONF [RFC8040], and hence the regular security
+   considerations for such usage are not considered here.
+
+   Below, we describe protections relating to both discovery and some
+   advice on protecting the underlying SBOM and vulnerability
+   information.
+
+   The model specifies both encrypted and unencrypted means to retrieve
+   information.  This is a matter of pragmatism.  Unencrypted
+   communications allow for manipulation of information being retrieved.
+   Therefore, it is RECOMMENDED that implementations offer a means to
+   configure endpoints so that they may make use of TLS or DTLS.
+
+   The ietf-mud-transparency module has no operational impact on the
+   element itself and is used to discover state information that may be
+   available on or off the element.  In as much as the module itself is
+   made writeable, this only indicates a change in how to retrieve read-
+   only elements.  There are no means, for instance, to upload an SBOM.
+   Additional risks are discussed below and are applicable to all nodes
+   within the transparency container.
+
+   If an attacker modifies the elements, they may misdirect automation
+   to retrieve a different set of URLs than was intended by the
+   designer.  This in turn leads to two specific sets of risks:
+
+   *  the information retrieved would be false
+
+   *  the URLs themselves point to malware
+
+   To address either of these risks or any tampering of a URL:
+
+   *  test any cloud-based URL against a reputation service
+
+   *  provide the administrator an opportunity to approve further
+      processing when the authority changes to one not known to be
+      reputable
+
+   SBOMs provide an inventory of software.  Knowledge of which specific
+   software is loaded on a system can aid an attacker in identifying an
+   appropriate exploit for a known vulnerability or guide the
+   development of novel exploit against this system.  However, if
+   software is available to an attacker, the attacker may already be
+   able to derive this very same software inventory.  When this
+   information resides on the endpoint itself, the endpoint SHOULD NOT
+   provide unrestricted access to the well-known URL by default.
+
+   Other servers that offer the data MAY restrict access to SBOM
+   information using appropriate authorization semantics within HTTP.
+   One way to do this would be to issue a certificate to the client for
+   this purpose after a registration process has taken place.  Another
+   approach would involve the use of OAuth in combination.  In
+   particular, if a system attempts to retrieve an SBOM via HTTP or CoAP
+   and the client is not authorized, the server MUST produce an
+   appropriate error with instructions on how to register a particular
+   client.
+
+   Another risk is a skew in the SBOM listing and the actual software
+   inventory of a device/container.  For example, a manufacturer may
+   update the SBOM on its server, but an individual device has not been
+   upgraded yet.  This may result in an incorrect policy being applied
+   to a device.  A unique mapping of a device's software version and its
+   SBOM can minimize this risk.
+
+   To further mitigate attacks against a device, manufacturers SHOULD
+   recommend network access controls.
+
+   Vulnerability information is generally made available to such
+   databases as NIST's National Vulnerability Database [NISTNVD].  It is
+   possible that vendors may wish to release information early to some
+   customers.  We do not discuss here whether that is a good idea, but
+   if it is employed, then appropriate access controls and authorization
+   SHOULD be applied to that information.
+
+7.  IANA Considerations
+
+7.1.  MUD Extension
+
+   IANA has added "transparency" to the "MUD Extensions" registry
+   [RFC8520] as follows:
+
+   Value:  transparency
+   Reference:  RFC 9472
+
+7.2.  YANG Registration
+
+   IANA has registered the following YANG module in the "YANG Module
+   Names" registry [RFC6020]:
+
+   Name:  ietf-mud-transparency
+   Namespace:  urn:ietf:params:xml:ns:yang:ietf-mud-transparency
+   Maintained by IANA:  N
+   Prefix:  mudtx
+   Reference:  RFC 9472
+
+   The following URI has been registered in the "IETF XML Registry"
+   [RFC3688]:
+
+   URI:  urn:ietf:params:xml:ns:yang:ietf-mud-transparency
+   Registrant Contact:  IESG
+   XML:  None.  Namespace URIs do not represent an XML specification.
+
+7.3.  Well-Known Prefix
+
+   IANA has added the following URI suffix to the "Well-Known URIs"
+   registry in accordance with [RFC8615]:
+
+   URI Suffix:  sbom
+   Change Controller:  IETF
+   Reference:  RFC 9472
+   Status:  permanent
+   Related Information:  See ISO/IEC 5962:2021 and SPDX.org
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              DOI 10.17487/RFC3688, January 2004,
+              <https://www.rfc-editor.org/info/rfc3688>.
+
+   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
+              the Network Configuration Protocol (NETCONF)", RFC 6020,
+              DOI 10.17487/RFC6020, October 2010,
+              <https://www.rfc-editor.org/info/rfc6020>.
+
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <https://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
+              RFC 6991, DOI 10.17487/RFC6991, July 2013,
+              <https://www.rfc-editor.org/info/rfc6991>.
+
+   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
+              DOI 10.17487/RFC7231, June 2014,
+              <https://www.rfc-editor.org/info/rfc7231>.
+
+   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
+              Application Protocol (CoAP)", RFC 7252,
+              DOI 10.17487/RFC7252, June 2014,
+              <https://www.rfc-editor.org/info/rfc7252>.
+
+   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
+              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
+              <https://www.rfc-editor.org/info/rfc8040>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
+              Description Specification", RFC 8520,
+              DOI 10.17487/RFC8520, March 2019,
+              <https://www.rfc-editor.org/info/rfc8520>.
+
+   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
+              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
+              <https://www.rfc-editor.org/info/rfc8615>.
+
+   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+              Ed., "HTTP Semantics", STD 97, RFC 9110,
+              DOI 10.17487/RFC9110, June 2022,
+              <https://www.rfc-editor.org/info/rfc9110>.
+
+8.2.  Informative References
+
+   [CSAF]     Rock, L., Ed., Hagen, S., Ed., and T. Schmidt, Ed.,
+              "Common Security Advisory Framework Version 2.0", OASIS
+              Standard, November 2022, <https://docs.oasis-
+              open.org/csaf/csaf/v2.0/csaf-v2.0.html>.
+
+   [CVRF]     Hagen, S., Ed., "CSAF Common Vulnerability Reporting
+              Framework (CVRF) Version 1.2", Committee Specification 01,
+              September 2017, <https://docs.oasis-open.org/csaf/csaf-
+              cvrf/v1.2/csaf-cvrf-v1.2.pdf>.
+
+   [CycloneDX15]
+              CycloneDX, "CycloneDX v1.5 JSON Reference", Version 1.5.0,
+              <https://cyclonedx.org/docs/1.5/json>.
+
+   [EO2021]   Biden, J., "Executive Order on Improving the Nation's
+              Cybersecurity", EO 14028, May 2021.
+
+   [NISTNVD]  NIST, "National Vulnerability Database",
+              <https://nvd.nist.gov>.
+
+   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
+              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
+              <https://www.rfc-editor.org/info/rfc8340>.
+
+   [SPDX]     The Linux Foundation, "The Software Package Data Exchange
+              (SPDX) Specification", Version 2.3, 2022,
+              <https://spdx.github.io/spdx-spec/v2.3/>.
+
+Acknowledgments
+
+   Thanks to Russ Housley, Dick Brooks, Tom Petch, and Nicolas Comstedt,
+   who provided review comments.
+
+Authors' Addresses
+
+   Eliot Lear
+   Cisco Systems
+   Richtistrasse 7
+   CH-8304 Wallisellen
+   Switzerland
+   Phone: +41 44 878 9200
+   Email: lear@cisco.com
+
+
+   Scott Rose
+   NIST
+   100 Bureau Dr.
+   Gaithersburg, MD 20899
+   United States of America
+   Phone: +1 301-975-8439
+   Email: scott.rose@nist.gov