By a formal review do you mean submission to IANA for registration, per sections 3.1 and 5.1 of RFC8615? Does that need to wait until the updated HTTPS specification
is approved by the TC and published by OASIS?
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: Tuesday, August 3, 2021 10:51 AM
To: Lemire, Dave (HII-TSD) <
david.lemire@hii-tsd.com>
Cc:
d.kemp@cyber.nsa.gov; duncan sfractal.com <
duncan@sfractal.com>; TC OpenC2 (
openc2@lists.oasis-open.org) <
openc2@lists.oasis-open.org>
Subject: EXT :Re: EXT :Re: EXT :[openc2] RE: EXT :[openc2] RE: 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 3 Aug 2021, at 15:55, Lemire, Dave (HII-TSD) <
david.lemire@hii-tsd.com > wrote:
Eliot,
The PR has now been updated to use /.well-known/openc2 per
RFC 8615. See
https://github.com/oasis-tcs/openc2-impl-https/pull/114 Looking at your SBOM Access draft, you have the following:
URI suffix: "openc2"
Change controller: "IETF"
Specification document: This memo
Related information: OpenC2 Project
I m wondering if the Specification Document should be the forthcoming version of the OASIS OpenC2 HTTPS Transfer specification? Your draft currently cites the
July 2019 version as an informative reference. That s the current and correct document, but it doesn t include this new requirement for the path. I hope to publish an updated version sometime this autumn that will include the new requirement.
Ok, what has to happen is a formal review. I will raise this question. At the end of the day, I m not sure it much matters, but it really does make more sense for that to happen in your document. If you want, what I can do is help you
through that review process.
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 (elear) [ mailto:
elear@cisco.com ]
Sent: Thursday, July 29, 2021 4:16 AM
To:
d.kemp@cyber.nsa.gov Cc: Lemire, Dave (HII-TSD) <
david.lemire@hii-tsd.com >; duncan sfractal.com <
duncan@sfractal.com >;
TC OpenC2 (
openc2@lists.oasis-open.org ) <
openc2@lists.oasis-open.org >
Subject: EXT :Re: EXT :[openc2] RE: EXT :[openc2] RE: 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.
My apologies. I didn t see this one.
On 28 Jul 2021, at 21:32,
d.kemp@cyber.nsa.gov wrote:
Eliot,
Hot off the press there was support for using .well-known at today s working meeting. PR #114 linked below was on the agenda for discussion today, and based on the discussion I expect it will be updated to use /.well-known/openc2 (without trailing slash)
when it goes up for approval next week.
There doesn t seem to be a downside to adding a few characters to the URL, and we can squat on the name until we register it with IANA (i.e., registration is not a blocker for proceeding with this approach.)
Duncan and Dave, let me know if I mis-characterized today s discussion.
Dave
From: Lemire,
Dave (HII-TSD) <
david.lemire@hii-tsd.com >
Sent: Tuesday, July 27, 2021 3:04 PM
To: Lemire, Dave (HII-TSD) <
david.lemire@hii-tsd.com >; Dave Kemp (GOV) <
d.kemp@cyber.nsa.gov >;
Eliot Lear <
elear@cisco.com >; duncan sfractal.com <
duncan@sfractal.com >
Cc: TC OpenC2 (
openc2@lists.oasis-open.org ) <
openc2@lists.oasis-open.org >
Subject: RE: EXT :[openc2] RE: EXT :[openc2] RE: Updates to SBOM sharing draft
Eliot,
One update: there s now a PR to address the HTTP endpoint
path ambiguity issue :
https://github.com/oasis-tcs/openc2-impl-https/pull/114 It specifies /openc2/ as the path portion of the URI. There wasn t much support in the TC working meeting discussions or our on-line issue discussion to use
the /.well-known/ mechanism.
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 Lemire, Dave (HII-TSD)
Sent: Wednesday, July 14, 2021 2:26 PM
To:
d.kemp@cyber.nsa.gov ; Eliot Lear <
elear@cisco.com >; duncan sfractal.com <
duncan@sfractal.com >
Cc: TC OpenC2 (
openc2@lists.oasis-open.org ) <
openc2@lists.oasis-open.org >
Subject: EXT :[openc2] RE: EXT :[openc2] RE: 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.
We do have a repository for an SBOM AP, but unfortunately the editor has had higher priorities so it lacks any recent updates. However, if you pick
up reading here [github.com] in the editor s fork, you can get an impression of at least the initial approach being suggested (no point in reading beyond the end of section 2 right now [i.e., through 2.3.3.1]).
A work item for the HTTPS
Transfer Spec [github.com] (link to working version on GH) is to standardize on the path; there an open
issue [github.com] on GitHub for that. I d been thinking that we would simply use /openc2 for
the path. I hadn t consider the use of the .well-known approach
(something I d only learned of recently) but there s no reason we couldn t go that route instead.
Regarding MQTT, our transfer
spec for that [github.com] is nearly ready to go to public review. The default topic structure for sending commands is documented in section
2.2 [github.com] ; for this purpose the topic would be oc2/cmd/ap/sbom (+/-
some other considerations) to listen for SBOM retrieval commands.
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
d.kemp@cyber.nsa.gov Sent: Wednesday, July 14, 2021 1:36 PM
To: Eliot Lear <
elear@cisco.com >; duncan sfractal.com <
duncan@sfractal.com >
Cc: TC OpenC2 (
openc2@lists.oasis-open.org ) <
openc2@lists.oasis-open.org >
Subject: EXT :[openc2] RE: 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.
The OpenC2 HTTPS Transfer Specification
https://github.com/oasis-tcs/openc2-impl-https/blob/working/open-impl-https.md shows an example OpenC2 [github.com] message in Annex B:
POST /openc2 HTTP/1.1
Content-type: application/openc2+json;version=1.0
Date: Wed, 19 Dec 2018 22:15:00 GMT
X-Request-ID: d1ac0489-ed51-4345-9175-f3078f30afe5
{
"headers": {
"request_id": "d1ac0489-ed51-4345-9175-f3078f30afe5"
"created": 1545257700000,
"from": " oc2producer.company.net ",
"to": [" oc2consumer.company.net "]
},
"body": {
"openc2": {
"request": {
"action": ...
"target": ...
"args": ...
}
}
}
}
The OpenC2 Language Specification
https://github.com/oasis-tcs/openc2-oc2ls/blob/working/oc2ls.md section 3.3.1 [github.com] defines the value of the request property an OpenC2-Command, and the possible values for action . Fetching an SBOM would use the query action ( initiate a request for
information ). The target field of the query and the response format would be defined in an SBOM actuator profile document, not yet written, but the target would identify the particular SBOM to receive and the desired formats. The response would be one or
more SBOMs in the requested format(s), either as blobs uninterpreted by OpenC2 or as information objects translated to the serialization used by OpenC2. (For example if the SBOM were in SPDX tag-value format, the device could send it as-is text or convert
it to JSON in the SPDX JSON format. Presumably IoT devices would send blobs. More capable services could do the reserialization.)
After writing that I realize that OpenC2 is not very reader-friendly just to get started you need to read the language spec, a transfer spec, and an SBOM profile. We are chartered to keep it modular, but there is a barrier to entry by doing so. Our future
work is to write the SBOM profile with complete examples that could be the single document you could reference.
Dave
From: Eliot
Lear <
elear@cisco.com >
Sent: Friday, July 9, 2021 9:20 AM
To: duncan sfractal.com <
duncan@sfractal.com >
Cc: TC OpenC2 (
openc2@lists.oasis-open.org ) <
openc2@lists.oasis-open.org >;
Dave Kemp (GOV) <
d.kemp@cyber.nsa.gov >
Subject: Re: Updates to SBOM sharing draft
This deserves elaboration:
There are three mentions of OpenC2 in draft-ietf-opsawg-sbom-access. Two involve modes that would be listed in the discovery mechanism for SBOMs and VEXes (CSAF files) respectively.
The 3rd is the use of .well-known. I can happily try to register such an endpoint for OpenC2 in this draft. The value is simply that people can go to
https://{host}/.well-known/openc2 [%7bhost%7d] and make use of the HTTP binding. That s not a problem. What s more of a problem is that I don t really know where to point people in the OpenC2 spec to retrieve an SBOM or a VEX.
In addition, if you want the MQTT binding in, after some thought, I think we can do that, but I need to make some model changes. Specifically, there need to be enough parameters
passed so that the network management system can subscribe to the correct topic (I think). I m not an MQTT expert, but this doesn t seem impossible.
If you like, I can meet with the team during the 1st week of August, and I will be happy to code up any changes both in the draft and in the generation tool. All changes to
the draft are subject to IETF working group consensus, but so long as we re doing our level best to keep it secure, nobody s going to jump up and down (I don t think).
Eliot
On 9 Jul 2021, at 15:05, duncan sfractal.com
[gcc02.safelinks.protection.outlook.com] <
duncan@sfractal.com > wrote:
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 [gcc02.safelinks.protection.outlook.com] 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 [gcc02.safelinks.protection.outlook.com] . This will probably get merged over the weekend into the master branch (which at some point will be renamed main ).
Eliot
<ATT0002><draft-ietf-opsawg-sbom-access.txt>