# SCITT AGENDA   {#scitt-agenda}

Slot: Tuesday Session II 13:00 - 15:00

Minute taker: Hannes Tschofenig & Kay Williams

## Welcome & WG Status Update (Jon Geater,Hannes Tschofenig, 5 mins)   {#welcome--wg-status-update-jon-geaterhannes-tschofenig-5-mins}

Jon goes through the chair slides.

Hannes & Jon will send out a Doodle poll to query preferences regarding
the conference call meeting time slots and regarding the cadence.

## Context Recap (Henk Birkholtz, 10 minutes)   {#context-recap-henk-birkholtz-10-minutes}

Henk explains that merkle tree proofs are not SCITT specific and hence
there is some work proposed in COSE. A report will be given later (by
Ori, see agenda item below).

Henk reports about the large number of comments received on the
terminology PR. This resulted in a number of new issues and changes in
the terms used in the architecture.

Henk goes through a list of some of the most important terms - as a
refresher.

## Detailed Software Supply Chain Uses Cases for SCITT (Kay Williams, 20 mins)   {#detailed-software-supply-chain-uses-cases-for-scitt-kay-williams-20-mins}

https://datatracker.ietf.org/doc/draft-ietf-scitt-software-use-cases/

Kay goes through her slides talking about use cases. There are 9 classes
of use cases that are included in the WG document.

In her presentation she covered concepts like

*   issuers (e.g. developers, auditor)
*   statements (e.g. description about software)
*   Objects ('thing' the statement is made about, such as source files,
    binaries, firmware images)
*   statement consumers (e.g. individual evaluating software, end
    customers)

## Experience from the hackathon (Jon Geater, 10 minutes)   {#experience-from-the-hackathon-jon-geater-10-minutes}

Jon reports about the hackathon, which took place the weekend before the
start of the IETF meeting.

Implementation work focused on receiving a receipt via the defined
interfaces.

Hackathon involved 10 or so people.

A few take-aways:

*   There is a need for multiple tree algorithms
*   Uses JSON for cross-boundary communication
*   Challenges with the countersigning (based on the use of different
    identities and how it is represented in the COSE structure).

## An Architecture for Trustworthy and Transparent Digital Supply Chains   {#an-architecture-for-trustworthy-and-transparent-digital-supply-chains}

(Cedric Fournet, Steve Lasker, Henk Birkholz, 50mins)  
https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/

Cedric starts the presentation on the architecture and summarizes some
of the key concepts.

Statement issuance requires a stable long-term identifier. For this
purpose DIDs are used.

Henk: The feed is currently just a string for the artifact. The idea is
that feed is a structured, composite identifier. This still has to be
worked out.

Statement registration: Submission of the signed statement.

Mike: It opens a can of worms when you talk about registration policy
standardization.

Cedric: We currently have something really simple.

Henk: There were also discussions about COSE profiles and policy
languages. If we have to standardize something, I am not entirely sure
whether we want to do this.

Henk spots inconsistencies in the figures in the slides.

Hannes suggests to postpone the standardization of the registration
policy.

Roy: There are two types of policies:

*   policies for the identity, and
*   policies for the content (e.g. SBOM)

Validation & Audit: Verifying receipts

Scalability: Focused on registration and verification.

Henk: Can you clarify the "batches"?

You get a receipt for every signed statement

Haiguang Wang: Who will be the verifier?

Cedric: The consumer of the artifact, e.g. you receive a device driver
and you want to verify it. Another class would be the auditor.

Mike: The RP can verify receipts off-line but it can also do an online
verification.

Jon: There are two verification scenarios:

*   audit (off-line/slow)
*   automating the software supply chain (real-time decision making)

Liu Xiang: The transparency service is very important in the
architecture and it has to be trusted by all the stakeholders. In what
matter will it be organized? Centralized or distributed

Credric: The TS is designed such that everyone can see what it is doing.
The idea is to make it easy for auditors to verify it. How to make the
implementation of the TS trustworthy is outside the scope of the
standard but using trusted hardware and a replication will help.

Hannes: Important to consider the distributed nature of the transparency
service - those tend to scale not as well as batch signing data.

Henk: Regarding trustworthy hardware --> RATS WG. The transparency
service can be an attester and it can include an attestation result.
Every statement issuer can be an attester and to find its verifier it
could ask the transparency service but the information may be stored in
there.

## Countersigning COSE Envelopes in Transparency Services (Orie Steele, 10 mins)   {#countersigning-cose-envelopes-in-transparency-services-orie-steele-10-mins}

https://datatracker.ietf.org/doc/draft-birkholz-scitt-receipts/

Orie talks about the evolution of the work.

Orie explains the relationship to countersignatures.

New document: draft-steele-cose-merkle-tree-proofs  
(very early version)

Mike: Do you foresee non-merkle proofs in the future?

Orie: The intention is that the TS maintains the content. There are
other cryptographic structures that could be used. So far, we have
focused on Merkle Tree.

Henk: SCITT will profile the generic "thing" to become the SCITT receipt
structure.

Cedric: There use cases where you need additional privacy properties and
there are other structures (more complex structures).

Jon: Yes, there are other technologies. Is the COSE draft going to have
different versions or will those be different specs?

Orie: I am not aware of discussions about this topic.

## AOB + Open Mic (10 minutes)   {#aob--open-mic-10-minutes}

## Next Steps (Jon Geater,Hannes Tschofenig, 5 mins)   {#next-steps-jon-geaterhannes-tschofenig-5-mins}

*   Poll for interims will be distributed after the meeting.
*   Will also determine a suitable timeslot.

Roy: If you write implementations please let us know so that we can
connect you to others implementers.

Reviewers: Thomas Hardjono, Shigeya Suzuki and Avri Doria