Subject: [OPSAWG] Fwd: New Version Notification for draft-lear-opsawg-sbom-access-00.txt

From: Eliot Lear <[email-masked]>
Date: Tue, 13 Oct 2020 21:56:08 +0200

This is the same draft that was presented some time ago to you.  However, the emphasis is changed- MUD is not the sole means by which an SBOM can be discovered.  The context will matter.

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.

Eliot

> Begin forwarded message:
> 
> From: <[email-masked] <mailto:[email-masked]>>
> Subject: New Version Notification for draft-lear-opsawg-sbom-access-00.txt
> Date: 13 October 2020 at 17:41:51 CEST
> To: Eliot Lear <[email-masked] <mailto:[email-masked]>>, Scott Rose <[email-masked] <mailto:[email-masked]>>
> 
> 
> A new version of I-D, draft-lear-opsawg-sbom-access-00.txt
> has been successfully submitted by Eliot Lear and posted to the
> IETF repository.
> 
> Name:		draft-lear-opsawg-sbom-access
> Revision:	00
> Title:		Discovering And Accessing Software Bills of Materials
> Document date:	2020-10-13
> Group:		Individual Submission
> Pages:		15
> URL:            https://www.ietf.org/archive/id/draft-lear-opsawg-sbom-access-00.txt <https://www.ietf.org/archive/id/draft-lear-opsawg-sbom-access-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-lear-opsawg-sbom-access/ <https://datatracker.ietf.org/doc/draft-lear-opsawg-sbom-access/>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lear-opsawg-sbom-access <https://datatracker.ietf.org/doc/html/draft-lear-opsawg-sbom-access>
> Htmlized:       https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 <https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00>
> 
> 
> Abstract:
>   Software bills of materials (SBOMs) are formal descriptions of what
>   pieces of software are included in a product.  This memo specifies a
>   different means for SBOMs to be retrieved.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Oct 2020 15:41:42 -0400

Eliot Lear <lear=[email-masked]> wrote:
    > This is the same draft that was presented some time ago to you.
    > However, the emphasis is changed- MUD is not the sole means by which an
    > SBOM can be discovered.  The context will matter.

okay.

    > 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.

I understand that it's an *application management system*, because it is
managing some application server.   But, I don't understand "layer" here,
which suggests "layer-7", when really the application management system
really manages all the layers?
Maybe people think of HTTP as being a kind of layer-5 or 6, rather than 7.
(But, really nothing beyond layer 4 has any meaning between OSI terminology
and reality)

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

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.

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?

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Oct 2020 17:43:15 +0200

> On 14 Oct 2020, at 21:41, Michael Richardson <[email-masked]> wrote:
> 
> 

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

> 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.

> one wants and/or that the type returned will be tagged via Content-Type.

Agree.

> available?   Avoiding for now, any kind if enumeration, aiming just for

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

Eliot

---

From: "Rose, Scott W. (Fed)" <[email-masked]>
Date: Thu, 15 Oct 2020 16:17:17 +0000

Agree.

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

Scott

---

From: Michael Richardson <[email-masked]>
Date: Fri, 16 Oct 2020 18:07:30 -0400

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

    > 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.

    > 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.

    > 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.

    >> On 14 Oct 2020, at 21:41, Michael Richardson <[email-masked]> 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.