Re: [SCITT] SCITT Working Group Meeting (Dec 5th 2022)

[Kiran Karunakaran <[e-mail]>]

Hi,

Please let me know if we're OK with the topics identified below. I was out last Monday on PTO but based on the notes provided, I'm assuming the path forward is to continue with our use cases and terminology discussion:

Agenda:

Updates from the Chairs:

  1.  Update on tooling, cadence for interim Working Group meetings
  2.  Prioritization of discussion topics
     *   Working backwards from IETF116
     *   In scope vs out of scope

Use cases:

  1.  Review Dick's (see attached) SW use case and provide feedback- See attached email ([SCITT] DRAFT NEW Use Case: Software Package Authenticity and Trust)
  2.  Yogesh's pull request for reformatting (align with SUIT use case doc format) software supply chain use case ID- Sw use case rewrite by yogeshbdeshpande * Pull Request #7 * ietf-scitt/draft-birkholz-scitt-software-supply-chain-use-cases (github.com)<https://github.com/ietf-scitt/draft-birkholz-scitt-software-supply-chain-use-cases/pull/7>

Terminology Discussion:

  1.  Continue terminology discussion that's happening via email- See attached email ([SCITT] Terminology for EO\Software Supplychain.)

Kiran

From: Kiran Karunakaran
Sent: Wednesday, November 23, 2022 10:24 AM
To: Yogesh Deshpande <[e-mail]>; Birkholz, Henk <[e-mail]>; [e-mail]
Cc: Kay Williams <[e-mail]>; Hannes Tschofenig <[e-mail]>; Jon Geater <[e-mail]>
Subject: RE: SCITT Working Group Meeting (Nov 28th)

Hi Yogesh and Henk,

Hope all is well. The topic we chose for our next working group discussion ( Monday Nov 28th,2022) was 'RATS and SCITT relationship/intersection'. An issue has been already created on GitHub to track documentation (RATS and SCITT * Issue #37 * ietf-scitt/draft-birkholz-scitt-architecture (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-scitt%2Fdraft-birkholz-scitt-architecture%2Fissues%2F37&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C0114c1aee1174c75a78f08dac8dcbcd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638043147649853342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aitaGZCdmTaidTpx0fgHx7Zz%2Bi4Kx%2Bqm4yptdp%2BfYvM%3D&reserved=0>) and it would be great if you could provide a write up in there for working group members to get up to speed on the topic. I'm assuming the goal here is to align on concepts (what RATS does, what SCITT does, how do they intersect) and terminology with help of Ned Smith and other RATS working group members.

I'm sending this email on Wednesday to make sure that this in fact the topic we'd like to discuss and we have enough time to provide context around the issue for discussion.

All known working group issues are temporarily being tracked here: IETF: SCITT Backlog - HackMD<https://hackmd.io/WvkjLafURbqZCyygMa0JmA?view>. Some of these have GitHub issues opened against them in the architecture repo, some of them don't. This should get more cleaned up once we have the IETF working group org setup in GitHub, and a mechanism defined on how to prioritize the right issues for the working group. Jon and Hannes are already working on this, and we'll wait to hear from them on next steps.

Kiran


From: Kiran Karunakaran
Sent: Saturday, November 19, 2022 6:48 PM
To: '[e-mail]' <[e-mail]<mailto:[e-mail]>>
Subject: RE: SCITT Working Group Meeting

Hi,

Please see below for Monday (11/21) working group meeting agenda:

Link to doc: SCITT General Meeting Agenda and Notes - Google Docs<https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit>

Agenda:

  1.  New members introduction
  2.  Topic#1- Statements as References: Statement by reference * Issue #35 * ietf-scitt/draft-birkholz-scitt-architecture (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-scitt%2Fdraft-birkholz-scitt-architecture%2Fissues%2F35&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C0114c1aee1174c75a78f08dac8dcbcd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638043147649853342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IA7H0TmipwpgblltrXVeH4nhZxtuCOhUKxAolR7xdO0%3D&reserved=0>. (Maik)
  3.  Topic#2 (if we have time)- Terminology: Converge Claim and Statement * Issue #34 * ietf-scitt/draft-birkholz-scitt-architecture (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-scitt%2Fdraft-birkholz-scitt-architecture%2Fissues%2F34&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C0114c1aee1174c75a78f08dac8dcbcd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638043147649853342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Npajxgffa5emEmeuscWILvid4nEQafFsD989%2Fq6dDy0%3D&reserved=0> and Refine definition of feed * Issue #36 * ietf-scitt/draft-birkholz-scitt-architecture (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-scitt%2Fdraft-birkholz-scitt-architecture%2Fissues%2F36&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C0114c1aee1174c75a78f08dac8dcbcd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638043147649853342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CsdT6zFREdCW7DFLjnq7JrYPpOmywaIPEARkDQqoigI%3D&reserved=0>.

Proposed topics for the following week:


  1.  Software supply chain use case: https://github.com/ietf-scitt/draft-birkholz-scitt-software-supply-chain-use-cases/issues/6<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-scitt%2Fdraft-birkholz-scitt-software-supply-chain-use-cases%2Fissues%2F6&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C0114c1aee1174c75a78f08dac8dcbcd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638043147649853342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y%2FEIt8vHS15IlKjbbW%2Fgh1KRvqC1fniXNOVcdRzAFSk%3D&reserved=0>. Re-write software supply chain use case to be only focused on requirements without reference to the solution (Ref: draft-ietf-ace-usecases-05<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-usecases-05&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C0114c1aee1174c75a78f08dac8dcbcd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638043147649853342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PqkqOuxSBH0oVRcA0qgWklF6pPnw3gtGVKuR97z%2B8S0%3D&reserved=0>).
  2.  SCITT and RATS intersection: RATS and SCITT * Issue #37 * ietf-scitt/draft-birkholz-scitt-architecture (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-scitt%2Fdraft-birkholz-scitt-architecture%2Fissues%2F37&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C0114c1aee1174c75a78f08dac8dcbcd1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638043147649853342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aitaGZCdmTaidTpx0fgHx7Zz%2Bi4Kx%2Bqm4yptdp%2BfYvM%3D&reserved=0>. We need documentation around SCITT and RATS focusing on how they interact, overlap and what specific problems they solve to avoid any future confusion. Should this be part of the use case document or should this be defined within the architecture?


Kiran

From: Kiran Karunakaran
Sent: Sunday, November 13, 2022 8:10 PM
To: '[e-mail]' <[e-mail]<mailto:[e-mail]>>
Subject: RE: SCITT Community Meeting

Hi,

Please see below for Monday (11/14) community meeting's agenda:

Link to doc: SCITT General Meeting Agenda and Notes - Google Docs<https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit>
Agenda:

  *   IETF hackathon and SCITT session recap
  *   Next steps for working group
     *   RFCs
     *   Migration to IETF tools
     *   SCITT open source implementations and projects


Video link SCITT session: https://www.youtube.com/watch?v=hZcrq2d6aac
Chat Link: https://zulip.ietf.org/#narrow/stream/scitt

Kiran

From: Kiran Karunakaran
Sent: Sunday, October 23, 2022 10:23 PM
To: [e-mail]<mailto:[e-mail]>
Subject: RE: SCITT Community Meeting

Hi,

Please see below for Monday (10/24) community meeting's agenda:

Link to doc: SCITT General Meeting Agenda and Notes - Google Docs<https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit>

Agenda:


  *   IETF115
     *   Internet Drafts- Oct 24th deadline
        *   Architecture draft: ietf-scitt/draft-birkholz-scitt-architecture: A specification including, problem statement, use cases, requirements, and architectural constituents for a Transparency Service in support of Supply Chain Integrity, Transparency, and Trust (github.com)<https://github.com/ietf-scitt/draft-birkholz-scitt-architecture>
        *   Receipt draft: ietf-scitt/draft-birkholz-scitt-receipts: A countersign variant to express trust assertions in conducted merkle tree operations using COSE (github.com)<https://github.com/ietf-scitt/draft-birkholz-scitt-receipts>
           *   COSE: Header parameter for RFC 3161 Time-Stamp Tokens (ietf-scitt.github.io)<https://ietf-scitt.github.io/draft-birkholz-cose-tsa-tst-header-parameter/draft-birkholz-cose-tsa-tst-header-parameter.html>?
        *   SBOM use case draft: Detailed Software Supply Chain Uses Case for SCITT (ietf-scitt.github.io)<https://ietf-scitt.github.io/draft-birkholz-scitt-software-supply-chain-use-cases/draft-birkholz-scitt-software-supply-chain-use-cases.html>
  *   Use case discussion
     *   Firmware use case: use-cases/devicefirmware.md at main * ietf-scitt/use-cases (github.com)<https://github.com/ietf-scitt/use-cases/blob/main/devicefirmware.md>
     *   Election data use case (DRAFT): https://docs.google.com/document/d/1Wg1187YW9f_MadLTmspLpikKXOk7TYrzX5d_Ta2Pex4/edit?usp=sharing
     *   SCITT components

Thanks,
Kiran



From: Kiran Karunakaran
Sent: Sunday, October 16, 2022 8:19 PM
To: [e-mail]<mailto:[e-mail]>
Subject: RE: SCITT Community Meeting

Hi,

Please see below for Monday (10/17) community meeting's agenda:

Link to doc: SCITT General Meeting Agenda and Notes - Google Docs<https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit>

Agenda:


  *   Charter and Working Group status
  *   IETF SCITT website
     *   scitt-ietf.io
     *   scitt-ietf.dev
     *   scitt.software
     *   scitt.engineering
     *   scitt.io (Big thanks to Jon and RKVST for grabbing this domain earlier and offering it to IETF)
     *   scitt.space
     *   scitt.services
  *   IETF115
     *   Schedule and agenda
     *   Internet Drafts- Oct 24th deadline
        *   Architecture draft
        *   Receipt draft
        *   SBOM use case draft
  *   Use case discussion
     *   Firmware use case: use-cases/devicefirmware.md at main * ietf-scitt/use-cases (github.com)<https://github.com/ietf-scitt/use-cases/blob/main/devicefirmware.md>
     *   Election data use case (DRAFT): https://docs.google.com/document/d/1Wg1187YW9f_MadLTmspLpikKXOk7TYrzX5d_Ta2Pex4/edit?usp=sharing


From: Kiran Karunakaran
Sent: Sunday, October 9, 2022 4:08 PM
To: [e-mail]<mailto:[e-mail]>
Subject: RE: SCITT Community Meeting

Hi,

Please see below for Monday (10/10) community meeting's agenda:

Link to doc: SCITT General Meeting Agenda and Notes - Google Docs<https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit>
Agenda:


  1.  Charter status update
     *   Link to Ballot<https://datatracker.ietf.org/doc/charter-ietf-scitt/ballot/>
     *   Target approval date



  1.  Continue discussion (topics)
     *   SW supply chain use case
     *   Hashing Algorithm alignment
     *   SCITT receipts as COSE V2 countersignatures
     *   IETF115

Kiran

From: Kiran Karunakaran
Sent: Friday, September 30, 2022 11:06 AM
To: [e-mail]<mailto:[e-mail]>
Subject: RE: SCITT Community Meeting

Hi,

Please see below for Monday (10/03) community meeting's agenda:

Link to doc: SCITT General Meeting Agenda and Notes - Google Docs<https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit>

Agenda:


  1.  Speaker- Russ Housley (Russ Housley - ICANNWiki<https://icannwiki.org/Russ_Housley>)
     *   Are SCITT Receipts Countersignatures?
     *   Kicking Off Discussion on 'Creative signature bstr use'



  1.  Continue SW supply chain discussion
     *   Scope: Hashable digital artifact
     *   Feedback on Dick's SCITT implementation scenario diagram (see below)

                                                               i.      Other visual representations

     *   Other use cases


[cid:image001.png@01D9056F.79F18380]


Thanks,
Kiran
From: Kiran Karunakaran
Sent: Sunday, September 25, 2022 8:45 PM
To: [e-mail]<mailto:[e-mail]>
Subject: RE: SCITT Community Meeting

Hi,

Please see below for tomorrow (09/26) meeting's agenda:

Link to doc: SCITT General Meeting Agenda and Notes - Google Docs<https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit>

Agenda:

  *   Charter status update- Henk
  *   Use Case discussion
     *   SW/HW intersection use case- Monty
     *   Specific Use Case Discussion: How to stop Authentic Actors from making False Claims?
     *   SW supply chain use case discussion (continued)- Dick



Other topics:

  *   RATS architecture presentation- Hannes/Yogesh to provide an update on when this can be scheduled. Ideally, it will be covered during the Thursday SCITT technical meeting
  *   Threat Model Discussion - Yogesh, Cedric and Antoine


Thanks,
Kiran

From: Kiran Karunakaran
Sent: Sunday, September 18, 2022 8:43 PM
To: [e-mail]<mailto:[e-mail]>
Subject: RE: SCITT Community Meeting

Hi everyone,

Please see below for tomorrow (09/19) meeting's agenda:

Link to doc: SCITT General Meeting Agenda and Notes - Google Docs<https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit>

1.                   Threat Model Discussions - Yogesh, Cedric and Antoine

2.                   SCITT Use Cases

     *   Tracker on Github:  Issues * ietf-scitt/use-cases (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-scitt%2Fuse-cases%2Fissues&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C060039c7048f4171998108da9662c301%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637987649361125467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=iPkbwsp%2FUtzSByhnj%2BSUzRdIgr%2F7EnASNp57v5CvcTM%3D&reserved=0>
     *   Specific Use Case Discussion: How to stop Authentic Actors from making False Claims ?
     *   Continue software supply chain use case discussion

Thanks,
Kiran

From: Kiran Karunakaran
Sent: Friday, September 9, 2022 12:13 PM
To: [e-mail]<mailto:[e-mail]>
Subject: RE: SCITT Community Meeting

Agenda for 09/12 meeting

Link to doc: SCITT General Meeting Agenda and Notes - Google Docs<https://docs.google.com/document/d/1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg/edit>

Agenda:


  1.  Quick update on charter (Henk and Yogesh)
     *   charter/ietf-scitt-charter.md at master * ietf-scitt/charter (github.com)<https://github.com/ietf-scitt/charter/blob/master/ietf-scitt-charter.md>



  1.  SBOM use case review (Dick Brooks): SBOM Use Case strawman - based on CISA ICT_SCRM Task Force DRAFT - HackMD<https://hackmd.io/QuqKhy_bQ1qG9yyyBuEABg?view>. See references below
a.       https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1
b.       https://www.nist.gov/document/software-supply-chain-security-guidance-under-executive-order-eo-14028-section-4e
c.       Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (nist.gov)<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161r1.pdf>

  1.  Other use case discussions
     *   Use Case Tracker on Github: Issues * ietf-scitt/use-cases (github.com)<https://github.com/ietf-scitt/use-cases/issues>

From: Kiran Karunakaran
Sent: Friday, August 26, 2022 4:11 PM
To: [e-mail]<mailto:[e-mail]>
Subject: RE: SCITT Community Meeting

Hi,

Agenda for 08/29 meeting.


  1.  Charter proposal
     *   Github link: https://github.com/ietf-scitt/charter/pull/18/files
     *   Please input all comments/changes/suggestions (Session Transcript for SCITT Charter Iteration - HackMD<https://hackmd.io/T7GsPcJmRtC9IhVbXjUbCg>) before 08/30/2022
     *   Target Charter Proposal publish date: 09/05/2022
  2.  SBOM use case discussion
     *   Draft link: SBOM Use Case strawman - based on CISA ICT_SCRM Task Force DRAFT - HackMD<https://hackmd.io/QuqKhy_bQ1qG9yyyBuEABg?view>
     *   Other SBOM use cases

Thanks,
Kiran

-----Original Appointment-----
From: Yogesh Deshpande <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 18, 2022 2:13 PM
To: Yogesh Deshpande; Kay Williams; Roy Williams (COSINE); Steve Lasker; Birkholz, Henk; Hannes Tschofenig; [e-mail]<mailto:[e-mail]>; Eliot Lear
Cc: Aeva Black; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Bhuvaneshwari Krishnamurthi; [e-mail]<mailto:[e-mail]>; Sylvan Clebsch; EDGS Platform LT; [e-mail]<mailto:[e-mail]>; Brian Knight; [e-mail]<mailto:[e-mail]>; Entezari, Mehdi; Robert A Martin; [e-mail]<mailto:[e-mail]>; Nabanita Sen; Stephen Provine; Orie Steele; Travis Jones; Kellie Eickmeyer; Bhuvaneshwari Krishnamurthi; Shilpa Shastri; Kiran Karunakaran
Subject: SCITT Community Meeting
When: Monday, August 29, 2022 4:00 PM-5:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London.
Where: https://armltd.zoom.us/j/99133885299?pwd=b0w4aGorRkpjL3ZHa2NPSmRiNHpXUT09


Place Holder SCITT Meeting on behalf of Kay Williams, till we finally land ourselves in IETF Meeting tools.
Here's the link to the notes: SCITT General Meeting Agenda and Notes - Google Docs<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1vf-EliXByhg5HZfgVbTqZhfaJFCmvMdQuZ4tC-Eq6wg%2Fedit&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C7f24bfc16c4b4ac132a608da795ad9ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637955728414190607%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZUJdwWNDp7MesjiBlA3X7fY5oiuegYxlmOyADPlQeU4%3D&reserved=0>

@Kay Williams<mailto:[e-mail]>: Request please forward the Invite to those I missed in the thread.

Join Zoom Meeting
https://armltd.zoom.us/j/99133885299?pwd=b0w4aGorRkpjL3ZHa2NPSmRiNHpXUT09<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Farmltd.zoom.us%2Fj%2F99133885299%3Fpwd%3Db0w4aGorRkpjL3ZHa2NPSmRiNHpXUT09&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C7f24bfc16c4b4ac132a608da795ad9ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637955728414190607%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sOkJqNZA%2FzBRBHryjSrtY5d7Sfvir5%2BKX4iEYvg8TLU%3D&reserved=0>

Meeting ID: 991 3388 5299
Passcode: 531470
One tap mobile
[phone],,99133885299#,,,,*531470# United Kingdom

Dial by your location
        [phone] United Kingdom
        [phone] US (Houston)
        [phone] US (San Jose)
        [phone] US (New York)
        [phone] India
        [phone] India
        [phone] India
        [phone] India
        [phone] Hong Kong SAR
        [phone] Sweden
        [phone] Norway
        [phone] Israel
        [phone] Ireland
        [phone] Hungary
        [phone] Germany
        [phone] France
        [phone] Finland
        [phone] Denmark
        [phone] Canada
        [phone] Korea, Republic of
        [phone] Singapore
        [phone] South Africa
        [phone] Belgium
        [phone] Poland
        [phone] Slovenia
        [phone] Malaysia
        [phone] Taiwan
        [phone] Japan
Meeting ID: 991 3388 5299
Passcode: 531470
Find your local number: https://armltd.zoom.us/u/auABE2oPq<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Farmltd.zoom.us%2Fu%2FauABE2oPq&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C7f24bfc16c4b4ac132a608da795ad9ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637955728414190607%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SjEuVbChZ2I9XVXcAzGztMRnRrQFqT%2FD3zaZvJ0YTQQ%3D&reserved=0>

Join by SIP
[e-mail]<mailto:[e-mail]>

Join by H.323
162.255.37.11 (US West)
162.255.36.11 (US East)
115.114.131.7 (India Mumbai)
115.114.115.7 (India Hyderabad)
213.19.144.110 (Amsterdam Netherlands)
213.244.140.110 (Germany)
103.122.166.55 (Australia Sydney)
103.122.167.55 (Australia Melbourne)
209.9.211.110 (Hong Kong SAR)
149.137.40.110 (Singapore)
64.211.144.160 (Brazil)
69.174.57.160 (Canada Toronto)
65.39.152.160 (Canada Vancouver)
207.226.132.110 (Japan Tokyo)
149.137.24.110 (Japan Osaka)
Meeting ID: 991 3388 5299
Passcode: 531470

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--- Begin Message ---

REVISED USE CASE: Addressing Kay’s comment:



Added “An automated risk assessment control/application may be used by a consumer for this purpose. “





Software Package Authenticity and Trust



Software consumers frequently obtain software packages from downloadable locations on the Internet, i.e., GitHub, App Stores, watering holes such as WordPress and other well-known sites. Prior to installing a software package, Consumers will want to verify that the software package/app is trustworthy enough to install into their digital ecosystems, including smart devices, i.e., smart phones. Trust in software involves multiple dimensions that must be evaluated in order to determine if a software package should be trusted enough to install.



Software supply chain risk assessment has been identified as a key “risk management control” by NIST in SP 800-161 and other guidance intended to identify software supply chain risk for Executive Order 14028. But there are many dimensions of risk that need to be evaluated during a software risk assessment in order to determine the “trustworthiness” of a software package. Does the software contain malware, is the software supplier trustworthy, does the software have any known, exploitable vulnerabilities, is the software digitally signed. These are just a few of the factors that contribute to the calculus applied by consumers when determining trustworthiness in a software package/app within an app store.



This use case focuses on one dimension/factor used to ascertain trust in a software package; Authentication of the parties involved in a software package supply chain and verifying the trust bond among a software supplier, a software package and the party that signs a software package.



The main interest of software consumer is to establish the trustworthiness of a software package/app before installation into a smart device or other system within a digital ecosystem. An automated risk assessment control/application may be used by a consumer for this purpose.





Authorization Problems Summary



1.  The consumer needs to verify the identity of the software supplier of an app/software package

2.  The consumer needs to verify the signing party on a digital signature applied to a software package/app

3.  The consumer needs to verify the integrity of a software package is free of tampering

4.  The consumer needs to verify the trust bond between the software supplier, digitally signed software package/app and the party that signed the software package to decide that these parties are the rightful, authorized parties for the software package.





Thanks,



Dick Brooks



Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership



Never trust software, always verify and report!<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freliableenergyanalytics.com%2Fproducts&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C3c89c91b3a554192de1e08dad20b15da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638053242322857996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CqBDxUQGZJ1OKg2Q0qZuV%2BRaYL6zdzyKJZq2QWHu6wQ%3D&reserved=0> ™

http://www.reliableenergyanalytics.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliableenergyanalytics.com%2F&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C3c89c91b3a554192de1e08dad20b15da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638053242322857996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iszbJUzwhMFQQSyZc%2F8mNKOh3T%2Bz7SNRHI7D53P%2F6XE%3D&reserved=0>

Email: [e-mail]<mailto:[e-mail]>

Tel: [phone]



From: SCITT <[e-mail]> On Behalf Of Dick Brooks
Sent: Tuesday, November 29, 2022 7:53 AM
To: 'Kay Williams' <[e-mail]>; [e-mail]
Subject: Re: [SCITT] DRAFT NEW Use Case: Software Package Authenticity and Trust



Thanks Kay. I’ll make that change.



Thanks,



Dick Brooks



Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership



Never trust software, always verify and report!<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freliableenergyanalytics.com%2Fproducts&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C3c89c91b3a554192de1e08dad20b15da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638053242322857996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CqBDxUQGZJ1OKg2Q0qZuV%2BRaYL6zdzyKJZq2QWHu6wQ%3D&reserved=0> ™

http://www.reliableenergyanalytics.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliableenergyanalytics.com%2F&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C3c89c91b3a554192de1e08dad20b15da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638053242322857996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iszbJUzwhMFQQSyZc%2F8mNKOh3T%2Bz7SNRHI7D53P%2F6XE%3D&reserved=0>

Email: [e-mail]<mailto:[e-mail]>

Tel: [phone]



From: Kay Williams <[e-mail]<mailto:[e-mail]>>
Sent: Monday, November 28, 2022 11:06 PM
To: Richard Brooks <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [SCITT] DRAFT NEW Use Case: Software Package Authenticity and Trust



Hi Dick,



This use case looks good, thank you for updating and sharing.



One suggestion is to clarify that the ‘consumer’ described in the use case might be a software application rather than a human, e.g a software package installer that performs verifications prior to installation.



Kay



From: SCITT <[e-mail]<mailto:[e-mail]>> On Behalf Of Dick Brooks
Sent: Monday, November 28, 2022 12:31 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [SCITT] DRAFT NEW Use Case: Software Package Authenticity and Trust



Hello Everyone,



Thanks for the discussion today and for providing the guidance needed to produce this use case.



Here is a new use case based on the guidance provided by Yogesh. I’m looking for comment/feedback on the following:



*       Is this a viable use case for SCITT
*       Is the use case understandable and represents a practical business need today
*       What areas are ambiguous and need further clarity



If we reach a general consensus that this use case is germane to SCITT, then I’ll update the issue to include this use case.



Thanks for your help.



Software Package Authenticity and Trust



Software consumers frequently obtain software packages from downloadable locations on the Internet, i.e., GitHub, App Stores, watering holes such as WordPress and other well-known sites. Prior to installing a software package, Consumers will want to verify that the software package/app is trustworthy enough to install into their digital ecosystems, including smart devices, i.e., smart phones. Trust in software involves multiple dimensions that must be evaluated in order to determine if a software package should be trusted enough to install.



Software supply chain risk assessment has been identified as a key “risk management control” by NIST in SP 800-161 and other guidance intended to identify software supply chain risk for Executive Order 14028. But there are many dimensions of risk that need to be evaluated during a software risk assessment in order to determine the “trustworthiness” of a software package. Does the software contain malware, is the software supplier trustworthy, does the software have any known, exploitable vulnerabilities, is the software digitally signed. These are just a few of the factors that contribute to the calculus applied by consumers when determining trustworthiness in a software package/app within an app store.



This use case focuses on one dimension/factor used to ascertain trust in a software package; Authentication of the parties involved in a software package supply chain and verifying the trust bond among a software supplier, a software package and the party that signs a software package.



The main interest of a software consumer is to establish the trustworthiness of a software package/app before installation into a smart device or other system within a digital ecosystem. This use case only represents one of the “checks” that a consumer performs to ascertain trustworthiness of software epackage.





Authorization Problems Summary



1.      The consumer needs to verify the identity of the software supplier of an app/software package
2.      The consumer needs to verify the signing party on a digital signature applied to a software package/app
3.      The consumer needs to verify the integrity of a software package is free of tampering
4.      The consumer needs to verify the trust bond between the software supplier, digitally signed software package/app and the party that signed the software package to decide that these parties are the rightful, authorized parties for the software package.







Thanks,



Dick Brooks



Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership



Never trust software, always verify and report!<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freliableenergyanalytics.com%2Fproducts&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C3c89c91b3a554192de1e08dad20b15da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638053242322857996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CqBDxUQGZJ1OKg2Q0qZuV%2BRaYL6zdzyKJZq2QWHu6wQ%3D&reserved=0> ™

http://www.reliableenergyanalytics.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.reliableenergyanalytics.com%2F&data=05%7C01%7Ckkarunakaran%40microsoft.com%7C3c89c91b3a554192de1e08dad20b15da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638053242322857996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iszbJUzwhMFQQSyZc%2F8mNKOh3T%2Bz7SNRHI7D53P%2F6XE%3D&reserved=0>

Email: [e-mail]<mailto:[e-mail]>

Tel: [phone]

--- End Message ---

--- Begin Message ---

In the general meeting on Monday, we circled back to terminology and what it might look like for sharing terms with RATS and leveraging new ones where they don’t intersect.  This missed dealing with terminology intersections with each vertical use of SCITT.  Thus, why the comment by Jon to look back at the software use case.  This basically fits with a model of laying out one or more of the use cases and what terminology naturally works for it.  I will try to lay out the terminology I see for Software\EO use case and I hope others can write up other verticals.  We don’t require 100% accuracy to make progress.   The types below can be general classification where there may be more than one “content-type” or form of the data.


EO\Software components.


Software Bill of Materials


Software Bill of Materials (SBOM) lists the contents of the product package, License information, dependency information (OSS contributions) and what VDRs are already addressed.  The latter is to support distro’s that have cherrypicked solutions to known VDRs.


Production Evidence


This is raw serialized data that might contain configuration data (ruleset) in addition to results.  A build configuration request is itself evidence, but static analysis data would be RuleSet to apply, and SARIF output.


Postproduction Evidence


This can be continuous new data like antimalware scans (plus thumbprint of signatures to look for), or fuzzing results which from 3 days of runs, 5 days of permutations, or n days of permutations.


Compliance Claims


These are SSDF mappings from the evidence above to specific government requirements.  This is where SLSA fits in.  It is insufficient to have just claims as policy may alter over the lifetime of a product a re-evaluation of claims based on capture evidence may be necessary.


Vulnerability Disclosure Reports


A Vulnerability Disclosure Report or VDR is an attestation, per NIST recommendations (ref bullet 2) by a software vendor showing that each component in a software product SBOM has been checked for vulnerabilities prior to release of the product (or later) and outlines discovered vulnerabilities.


Endorsements


Endorsements are made by reviewers, or auditors that state that a product meets some criteria, does not meet criteria, is in a questionable state, or has decided to make no decision.  The format of this needs to be designed and one of the things I had suggested be part of the working group.  The concept spans multiple verticals in my mind.  An endorsement should not be something that points at reasons for a decision as doing so maps what is looked at and potentially what is ignored.



This then gets us to the terminology of all content submitted to a SCITT system.  For all intent and purposes, the eNotary portion of the system is oblivious to the contents.  The portion handed to the eNotary must be a COSE single signed (sign1) or counter signed “thing”.  From a generation point of view, I can see the terminology following:  A “thing” is deemed important and thus being sent to SCITT.  This is a statement. The statement must then be signed (detached or embedded) and this as a whole is called a signed statement. Cedric Fournet raised concerns with signed statements and wanted Signed Claim as it is more precise, but that causes conflict with claims above (did I capture your issue accurately here).



In a detached signed case, it is possible to think that only the detached portion of a signed statement is transmitted across the “wire” to the service.  The job of the eNotary is to validate the identity used to sign the “signed statement” is “true” and conforms to identity policy.  If “signed statement” meets policy, the eNotary will counter sign the “signed statement”.  We have been calling this counter signed statement a “receipt”.



As mentioned above, a receipt can also be submitted to the SCITT eNotary component and in that case at a minimum the eNotary validates the counter signature and tests if it meets identity policy.  It could optionally re-evaluate the original signature identity but that runs into problems due to some of the identity certificate may no longer be time valid.



Since everything submitted to SCITT is a “signed statement” the distinction blends into the woodwork.  Similar to the chemical composition of air, most people don’t think in terms of percentages of Nitrogen, Oxygen, and so forth.  It is just air.  This then leads to the terminology of:


SCITT Primitive Terminology.


Statement


Structured or Unstructured data in a serialized document that is pertinent to some product for retention.




Signed Statement


Is a statement that is embedded in a COSE signed construct or a statement with a detached COSE signed signature.




Receipt


Is a counter signed COSE wrapper around either the COSE signed wrapped statement or the COSE signed detached signature.

--- End Message ---