RE: EXT :Re: EXT :[openc2] Updates to SBOM sharing draft

Thanks for the clarifications, Eliot.

 

Dave

 

David Lemire

IA Systems Engineer

Technical Solutions

302 Sentinel Drive | Annapolis Junction, MD 20701

Work (301) 575-5190 |
Mobile (240) 938-9350

 

From: Eliot Lear [mailto:]

Sent: Friday, July 9, 2021 10:12 AM

To: Lemire, Dave (HII-TSD) <>

Cc: duncan sfractal.com <>; TC OpenC2 () <>; David Kemp <>

Subject: EXT :Re: EXT :[openc2] Updates to SBOM sharing draft

 

CAUTION: This email originated from
outside your organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.

 

Hi Dave

On 9 Jul 2021, at 15:51, Lemire, Dave (HII-TSD) <> wrote:

 

Iâm guessing that WGLC is an IETF process term, Iâve got no idea what it means.  More specifics on what they mean by us âcatch[ing] upâ would also be helpful.
 Who is Eliot Lear talking to?

 

WGLC = Working Group Last Call.

 

Do we know what IETF WG / charter this is under?  And their plans for progressing what appears to be an ID to an RFC?

 

I can step through the whole thing if you like.  The work is ongoing in the opsawg working group.  The draft due to be posted will be found as draft-ietf-opsawg-sbom-access-02.  The primary focus of the deliverable is to deliver
discovery information for SBOMs and secondarily VEXes, if people agree.

 

The process is as follows:

Someone writes a draft (Scott and I did that)

WG mulls it over

WG decides to adopt it (this happens)

Draft gets developed (we are here)

Draft gets discussed more

Draft then goes through Working Group Last Call (hoping for Sep/Oct)

IANA review for assigned names and numbers 

Security, Apps, Transport, General, Area review

IETF last call

IESG evaluation

Approval

RFC

 

Thereâs plenty of time for change.  In fact thereâs no fixed date to move things along, but we donât want to drag things out either.  Everyone is welcome to participate.  Just join
.

 

And Iâm happy to meet with anyone to improve the content re OpenC2.

 

Eliot

 

Dave

 

David Lemire

IA Systems Engineer

Technical Solutions

302 Sentinel Drive | Annapolis Junction, MD 20701

Work (301) 575-5190
 | Mobile (240) 938-9350

 

From:  [mailto:] On
 Behalf Of duncan sfractal.com

Sent: Friday, July 9, 2021 9:05 AM

To: TC OpenC2 () <>;
 David Kemp <>

Cc: Eliot Lear (elear) <>

Subject: EXT :[openc2] Updates to SBOM sharing draft

 

CAUTION: This email originated from outside your organization. Exercise caution
 when opening attachments or clicking links, especially from unknown senders.

 

IETF has an RFC that references using OpenC2. Attached is some work circulated to the SBOM crowd. 

 

According to IETF gurus we need to :

âOpenC2 needs to catch up to this work if they want to remain after WGLC (themâs the rules).  Iâve reinitiated a discussion with those guys.â

Iâm not sure what the means but we should do it promptly.

Dave K (or L or anyone else) Iâd appreciate help in doing this. 

 

iPhone, iTypo, iApologize

Duncan

 

From: ntia-sbom-framing-bounces+duncan= <ntia-sbom-framing-bounces+duncan=>
 on behalf of Eliot Lear via ntia-sbom-framing <>

Sent: Friday, July 9, 2021 8:06 AM

To: ntia-sbom-framing

Cc: Rose, Scott W.

Subject: Re: [ntia-sbom-framing] Updates to SBOM sharing draft 

 

This time with the draft attached. 

 

On 9 Jul 2021, at 13:57, Eliot Lear <> wrote:

 

Hi everyone, 

 

As discussed, Scott and I have updated the SBOM sharing draft.  As agreed, it handles VEX and SBOMs independently.  We need to get this posted by Monday for the draft deadline.  A few of the more salient points:

 

The intro is rewritten a bit to make clear what the key questions are.  We donât focus on licensing in this draft, though there is one sentence about them in formats and format neutrality.

There are two independent âchoicesâ in terms of how the information is retrieved- one for SBOMs and one for VEXes.  Each are roughly speaking the same.

Each maintains format neutrality.  There is also some text in there about what if the VEX and the SBOM file are the same.  Thatâs to address (obliquely) CycloneDX.

We managed to write the entire draft without using the term âVEXâ.

OpenC2 needs to catch up to this work if they want to remain after WGLC (themâs the rules).  Iâve reinitiated a discussion with those guys.

Weâve taken Patâs feedback to create separate well-known suffixes rather than to establish a tree.

Iâve updated https://mudmaker.org/test
 [mudmaker.org] with a version that does All Of This.

 

One question is just whether it should ever be expected that vulnerability information be kept on the box.  That seems like a stretch, even though the draft supports it.

 

Please see attached, and you can view the source at https://github.com/elear/mud-sbom/tree/vex
 [github.com].  This will probably get merged over the weekend into the âmasterâ branch (which at some point will be renamed âmainâ).

 

Eliot