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:
elear@cisco.com]
Sent: Friday, July 9, 2021 10:12 AM
To: Lemire, Dave (HII-TSD) <
david.lemire@hii-tsd.com>
Cc: duncan sfractal.com <
duncan@sfractal.com>; TC OpenC2 (
openc2@lists.oasis-open.org) <
openc2@lists.oasis-open.org>; David Kemp <
d.kemp@cyber.nsa.gov>
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) <
david.lemire@hii-tsd.com > 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
opsawg@ietf.org .
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:
openc2@lists.oasis-open.org [ mailto:
openc2@lists.oasis-open.org ] On
Behalf Of duncan sfractal.com
Sent: Friday, July 9, 2021 9:05 AM
To: TC OpenC2 (
openc2@lists.oasis-open.org ) <
openc2@lists.oasis-open.org >;
David Kemp <
d.kemp@cyber.nsa.gov >
Cc: Eliot Lear (elear) <
elear@cisco.com >
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=
sfractal.com@cert.org < ntia-sbom-framing-bounces+duncan=
sfractal.com@cert.org >
on behalf of Eliot Lear via ntia-sbom-framing <
ntia-sbom-framing@cert.org >
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 <
lear@cisco.com > 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