Hi Michael > On 28 Jul 2020, at 17:22, Michael Richardson <[email protected]> wrote: > > Signed PGP part > > Hi Eliot, > > 0) PLEASE ADOPT THIS DOCUMENT. > (Also I have some other MUD related documents which await the chairs' > attention)
+1, but let’s not expect a rush on approval. Lots of work needed. > > 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: I don’t think /// is a real construct. There are two issues. We don’t know the hostname and we don’t know the scheme. But the MUD manager does know the hostname, and we need to be provided the scheme. There is no convention for ME without a pre-existing context. That might be something to work on, but it would hav to happen in coordination with the COAP and HTTP working groups, and I don’t know how big a job it would be. Thus what’s there. > > 2) I think that I'm interested in what the format of the sbom is than I am > about how to get it. Well, you have your choice of at least three different classes and multiple encoding variants. Nice thing about standards, eh? > > 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. Perhaps. I can’t say. We’re going to need some operational experience. There are a number of use cases in the IoT field where you plug in different components that require different software loads. One aspect of SBOM, by the way, that hasn’t been explored is the difference between software being installed and the code being placed in service. Particularly drivers and supporting user-level software. > > 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. How did this go? > > > 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) Indeed. > > These are *not* mutually exclusive, and we should have multiple paths for > different ecosystems. > Righto. Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
