OASIS Open Command and Control (OpenC2) TC

 View Only

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

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

    Posted 08-03-2021 13:55




    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.
     

    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>