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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 .... SHA256: 58ea8846ec3a906f3217d88a0e6a1e17c2712fcf2d80ec337f2e2edf3417850b 85 main/binary-amd64/Release 377083f077eff53ac508cb3c9f44ab40cf2b21e8ecbfa2cda45c2a6b3c1b4b53 8815 main/binary-amd64/Packages 87eb18aa9dbaab01fb00500c3a01565fae7e2cfb553db0ad17eb92f0dadec71b 1789 main/binary-amd64/Packages.gz -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
