[OPSAWG] definining a /.well-known value for an SBOM

[Michael Richardson <[e-mail]>]

Relating to: draft-lear-opsawg-sbom-access-00.txt

Eliot Lear <[e-mail]> wrote:
    >>> My request is that we discuss this in the WG, and then consider it for
    >>> adoption, understanding that it has a bit of a road to travel still.
    >>
    >> I'm not sure that I understand why you are using the term "layer" in
    >> "application-layer management system"?  Or maybe it is "application"
    >> That section reads poorly, even though I eventually understood it.

    > Yeah, edits welcome.  Imagine a pool of applications servers that
    > you’re managing with a cloud orchestration system.  That’s the use
    > case.

I found the github at: https://github.com/elear/mud-sbom.git and I'll see if
I can reword.

BUT, I think that we've gotten to .well-known for SBOM from "MUD" in a kind
of roundabout way.

I think that having an SBOM for service.example at https://service.example/.well-known/sbom
(or some such), it entirely a good idea.
{Okay, there are a whole planet-full of lawyers waiting for us here. (Planet-L)
Some entities, will not want to disclose, but others will find that they are
obligated to.  Not our problem to make them do something, just to explain how
to do it in a standard way.}

As far as I can tell, we got here because in the self-hosted SBOM,
the MUD file would like to be able to reference a well known thing.

It seems that this problem is not very related to SBOM by MUD.
It ought to be just be a new draft.  Maybe something the SACM would want to adopt.

    >> Anyway, I thought that you were going to use a template for local-uri,
    >> instead of having the enumeration of scheme?

    > I got an opinion that either we go with .well-known OR we go with a
    > schema, but not both.  I think this is still an open issue, tho.

I say, either the SBOM is at some specified URL on a manufacturer web site
(with possible access control on it).  Or, it's at .well-known.
That probably is a simple enum.

While I can imagine writing an RFC8520 MUD file for some kind of https
interface application server: while it might be running a common OS (or live
in a container), it has a very limited number of functions.
Probably incoming port 443 from "controller", and outgoing port-443-to-update-server only.

    >> While the set of SBOM formats is far from set in stone,  and I think that
    >> each will have a MIME type, I want to suggest that this document make it
    >> clear that HTTP content negotiation should be used to get the format
    >> one wants and/or that the type returned will be tagged via Content-Type.

    > Agree.

The above .well-known URL for SBOM document could register MIME types the
currently known SBOM formats (SPDX-* and CycloneDX).
Each have multiple serialization formats, so likely there are many to register.
I'm not sure if the various groups have registered anything yet.
There is an OCT.22 NTIA/SBOM meeting next week, and I'll bring this up.

    >> Should the MUD file contain a text description of what content-type(s) are
    >> available?   Avoiding for now, any kind if enumeration, aiming just for
    >> human consumption?

    > I guess I would want to explore the use case a bit.

Rose, Scott W. \(Fed\) <scott.rose=[e-mail]> wrote:
    >> On 14 Oct 2020, at 21:41, Michael Richardson <[e-mail]> wrote:

    mcr> Should the MUD file contain a text description of what content-type(s) are
    mcr> available?   Avoiding for now, any kind if enumeration, aiming just for
    mcr> human consumption?

    eliot> I guess I would want to explore the use case a bit.

    scott> Might be helpful.  The format would be helpful too but would
    scott> require a registry (and a process to add formats).  Plus there may
    scott> end up being a lot of abandoned formats.

My idea is that the MUD file would just have a textual description for now,
no registry.  If the format has a MIME type, it could say that, but the
target audience is humans, not machines.  That way, when you reach out with a
list of Accept: headers and get nothing, one might have a clue why.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide