Interim 21st August 2023

Agenda

Standing items

• Review open PRs
• Update and discussion on Feed structure
• Progress of emulator reflecting -117 results
• Progress of SCRAPI

Agenda hacked items

• Update on DBOM
• Cassie Crossley intoduction

Minutes

Open PRs

Hannes ran throuh his new PRs - several areas where clarification of
terms would be very useful. General agreement uttered by Jon and Dick
but no specific resolutions - need time to think.

One issue picked up by Jon and Yogesh was 'client' vs 'issuer'. Issuer
is confusing if you come from an identity or PKI background, and client
needs to be more specific as we develop SCRAPI. Need to add a richer
glossary? A richer diagram?

Client and Issuer are not the same role, for good reasons. But Hannes
feels that's not very clear.

DBOM

• Mehdi has replied, is happy to present to the group.
• Jon to respond and schedule in for regular interim second week in
  September and notify the list well in advance (Jon has now asked
  Mehdi and updated the interim agenda on Datatracker - will update
  the group if this doesn't work).
• Ray would like a bit of an update ahead of their presentation to get
  up to speed on who is using it, use cases, traction etc. Does it
  relate to the VRF/API work (either contributing or as a peer?)

Hannes asks Ray whether he has made progress on the API/Vendor Response
File (VRF).
Ray: Only preliminary discussions and prepared a working document to
gather information about needs of various use cases. I am calling this
API because the VRF from Dick was a very specific idea that is best
viewed as input for furhter refinement.

• API for SCITT --
  https://docs.google.com/document/d/1zXlj4XW_LKZJHcgZ2lNQ1viyHUUlSdLmSs8tKcZCZ9E/edit?usp=sharing
• This document is simply gathering input at this point. Plese
  contribute any ideas by commenting in the document or sharing on the
  scitt email list. I will be functioning as the editor of this
  higher-level API. The idea is to at least generate a concept of the
  higher-level API and perhaps having a reference implementation while
  still allowing market differentiation.

Henk supports inviting the DBOM group.

Hannes quickly went though the issues he filed asking for feedback.
https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/89

https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/90

https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/93

Cassie Crossly introduction

Dick points to ongoing work on terminology, he thanks Cassie for joining
the call, and thanks Ray for getting started with the VRF.

Hannes also thanks Cassie for joining.

Cassie introduced herself, very experienced in use and generation of
SBOMs and now interested in getting into the more detailed areas of
trust, transparency, provenance etc. 'The Next Layer'.

Cassie is interested in actually implementing SCITT, DBOM and so on and
seeing how they work in real life.

Hannes asks if Cassie might provide a use case for the next hackathon.

Jon will send the videos from -117 hackathon to help Cassie get up to
speed.

Issuer vs. Client

Yogesh pointed out that the client might require
authentication/authorization and the client might be different from the
issuer. Hannes noted that there is text missing that explains the
relationship between the client and the issue.

Jon explained the reason for the diffrerence and a good solution could
be to move 'client' to the SCRAPI document and flesh out 'issuer' in the
architecture.

Auditor

Neal says that the document says it would be useful to distinguish
auditors or monitors (are those distinct terms used in Certificate
Transparency?) who check logs to make sure they are behaving correctly,
from what I'll call "relying parties" who are concerned with verifying a
specific claim (leveraging the work of the auditors to ensure that the
log itself is well-behaved)?

Neal added comments to
https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/89

Yogesh volunteered to work with Henk on the text.

Henk: We have to be careful to avoid overloading terms.

Ray: I believe there are two layers - the lower level APIs and the high
high-level APIs. The lower layer will not care about the end entities.

Yogesh suggests a guidance document for implementers.

Neal: If nobody is watching the log, it does not offer its security
properties. We need to capture this.

Ray also likes the guidance document.

SEC Regulation and relationship with SCITT

Roman asked the question about the relationship between SCITT and the
regulatory developments.
Biggest change in software supply chain. This is bigger than the SBOM
work. The question will be what SCITT will play. We don't have an answer
yet but the trust registry will serve a role. I see potential here.

Dick states: The SEC regulations have significant implication here in
the US, with some impact to foreign entities. Here is an article about
the SEC regulations that go into effect in December 2023:
https://energycentral.com/c/um/preparing-cyber-caremark-lawsuit-lessons-home-depot-derivative-complaint-carlton

Conclusions

Next meeting agenda:

• Update and discussion on Feed structure
• Progress of SCRAPI
• Progress of emulator reflecting -117 results
• Continue discussion on PRs/open issues