Subject: [OPSAWG] some comments and thoughts on mud-sbom and sbom-type

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Jul 2020 11:22:19 -0400

Hi Eliot,

0) PLEASE ADOPT THIS DOCUMENT.
   (Also I have some other MUD related documents which await the chairs' attention)

As I said in the meeting, I don't really understand sbom-local.
I asked this online, but let me repeat.

1) It seems that just putting coaps:///.well-known/sbom in the URI might work as well.
   If necessary, then maybe: coaps://127.0.0.1/.well-known/sbom or https://[::1]/.well-known/sbom
   CoAP does have a Content-Type for returned content, but it is true that
   there isn't as much negotiation by default in the form of Accept:

2) I think that I'm interested in what the format of the sbom is than I am
   about how to get it.

3) I think that, in general, that the SBOMs will seldom be hosted on a
   constrained device that is capable of being described by MUD.
   {that is, devices that can self-host an SBOM, will tend to be servers,
   desktops,    etc. that are not easily described by MUD}

   So I am not convinced that this is use case is reasonable.

Alternative paths:

a) There is also a draft,  draft-moran-suit-mud-00
       Strong Assertions of IoT Network Access Requirements

   which would provide a MUD URL as part of a Software Update process.
   It will be at secdispatch on Thursday.

b) There is a draft:       draft-birkholz-rats-mud-00
   which uses a MUD file to point to a list of appraisal evidence (ras-uris),
   a list of RIM CoSWID (SBOM!), and edt-uri (endorsements of Roots of Trust)

These are *not* mutually exclusive, and we should have multiple paths for
different ecosystems.

---

For those that are not aware there are some SBOM efforts at:
1) https://www.ntia.gov/sbom
2) https://www.it-cisq.org/software-bill-of-materials/index.htm
3) https://cyclonedx.org/
4) https://spdx.dev/

with multiple weekly calls.  (each are not working in isolation)

In general, SBOMs are signed by the upstream software author, packager and distributor.
Some of the standards work is how to present them all together, as current
systems do not maintain the audit trail between software author, etc.

If you run a Debian derived system (Ubuntu, Devone, etc), then you can see the
SPDX tag:value SBOM at: /var/lib/dpkg/status. That version is not signed
inside the file.  The copies at /var/lib/apt/lists/ are, such as, on my
system, have a signature in the Release file:

cat repo.skype.com_deb_dists_stable_InRelease

...
SHA256:
 58ea8846ec3a906f3217d88a0e6a1e17c2712fcf2d80ec337f2e2edf3417850b       85 main/binary-amd64/Release
 377083f077eff53ac508cb3c9f44ab40cf2b21e8ecbfa2cda45c2a6b3c1b4b53     8815 main/binary-amd64/Packages
 87eb18aa9dbaab01fb00500c3a01565fae7e2cfb553db0ad17eb92f0dadec71b     1789 main/binary-amd64/Packages.gz

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-