Minutes interim-2023-scitt-07: Mon 16:00
minutes-interim-2023-scitt-07-202302201600-00

= SCITT Interim Meeting 20.Feb.2023

Chair: Hannes Tschofenig and Jon Geater

Minute taker: Hannes Tschofenig

== Use Case

Yogesh: Included Monty's use case about firmware
I reviewed the document. The order of the use cases could be improved.
I could open an open issue.

Henk: We already treat the document as a working group document.

Bob: I looked through it. It is a good basis for going forward.

Dick: Agree with Bob. It is good enough to get us on a path.

Ray: Maybe state during the call for adoption that further changes can
be made.

Hannes: We will start a call for adoption (for 2 weeks).
Jon agrees.

Neal: What is the process?

Hannes: Explains the IeTF document process

Neal: What is a good use case document?

Hannes: Document informs the architecture.

Henk: Refers to comments about the use case document and some parts of
the use cases might be out of scope right now (which for Henk is okay).

Dick: I hope we get an agreement on the purpose of SCITT
It has to provide benefits for someone. IMHO the consumers are the
beneficiaries: Is a piece of software trustworthy enough in an
ecosystem?

Bob: I agree with Dick but we need to remember that the real power is
among supply chain partners and not end consumers.

Neal: I want to push back on the idea that there is statement in the
SCITT registry that a piece of software is trustworthy. Instead there
will be evidence, which will help the "relying party" to decide whether
something is trustworthy.

Bob: Fully support the statement of Neal.

Ray: Reading through the email comments I sent a mail to the list in
theline of what Neal says. There are two layers: If we can put in simple
claims (evidence) and not evaluation. At the next layer there is the
evaluation of the evidence.

Yogesh: Agree with Neal and Bob. The ecosystem is not only for end users
/ end customers but also for other suppliers. Additionally, there are
auditors. The evidence layer is a bit tricky. We could have some basic
verification steps.

Cedric: I think we are largely in agreement at this point.

Steve: Many end users are delegating trust decisions to entities they
trust. An important aspect is about brand and identity of the entities
involved. There is another aspect of whether the information is current
(freshness angle), which needs to be covered as well.

Dick: Agree with Steve. The consumer of the software could be the end
user or some other party. Are we saying that the evidence is trustworthy
or whether the end product described by the evidence is trustworthy?

Neal: There is a notion of multiple SCITT registries with different
rules about who can publish statements. The question is: How do you find
the SCITT instance that describes the software we care about? Do we have
some use cases supporting this?

Henk: Summarizes the discussions so far. We have never spoken about
semantic interoperability. We minimal is what Neal said: the basis for
decision making. If you include a virus scan you could also include an
attestation result into the SCITT registry. The complexity of the SCITT
message varies (as well as the audience, ranging from consumers as Dick
highlighted to Supply Chain entities as Bob highlighted) and some of
this may be subject for future work. For now everything on a
Transparency Services are opque statement payloads and the notirization
capabilites of SCITT are the primary focus.

Bob: When I give a talk about SCITT I refer to 5 different registries.
Software developers would use one private registry that contains scans,
tests, sbom, and other statements/claims about the software.
There may be a different registry about the companies and the
developers. Then, there is a different registy to make public statements
about the software they release.

Jon: While Dick's request is a great application, my understanding is
the simple that all of the facts are available and we make sure that
those who publish the statements are identifyable. Then, you make up
your conclusions based on the published statements. There is a request
of where this is useful. For the UK public sector and US DoD we have
done projects of large collaborative systems (e.g self-driving vehicles)
where there are lots of moving parts (e.g. AI models, software, security
researchers). It is up to the risk holder to decide whether they care
about the results / findings of the security researchers regarding their
software.

On the build side, we publish vulnerability reports of our front-end
(mostly JavaScript). We can publish a build artifact that we ran a
certain tool and it told us we have no vulnerabilities, but that doesn't
mean it's actually true: it just means we're held accountable for
problems that arise when the supply chain discivers we were lying.

We are trying to make an improvement rather than trying to make things
100% bullet-proof.

Steve: We talked about the multiple instances in the past. There are
different ecosystem players (software developers, hardware
manufacturers, etc.). We are also getting information from third
parties. I can think of multiple instances of SCITT registries and I
could make tools that use data from different SCITT registries and
aggregate this information, if needed.

Cedric: The basic design for me is that there is one statement for one
specific issuer in one specific SCITT instance. There will be more
registries in the future for more complex scenarios.

Neal: In the SigStore model there is one single registry. I hear that
different companies will run their own SCITT registry. I would prefer if
there are ways to prevent spam and a smaller number of SCITT registries.

It might help to reflect a use case where different "relying parties"
query the SCITT registry and come up with different conclusions.

Dick: We could make good progress if we state what the "trust statement"
in the registry is. (What the entry in the registy means?) What are the
semantics of statements in an append-only log?

Steve: The statement probably varies to the industry and the relying
party.
Is there a definition of the format of the statement? I don't think it
is up to the SCITT WG to decide what the statement format is. It could
be an SBOM, VEX, ...

On the multiple instance question: different
organizations/governments/companies will just deploy different
registries.
It is natural how distribution systems work. Some organizations may
cooperate and setup one registry.

Henk: I echo Jon's concern if we try to model semantic interoperability.
There has to be a minimal amount of "understanding". The SigStore folks
have some core semantics and pulling this in might be an option. It
would be a low-hanging fruit for interoperability. For now we start with
the assumption that everything is opaque. In a PoC we have to answer
questions like Dick is asking.

Neal: Agree with Henk.

Yogesh: Agree with Jon & Henk. We try to make the issuer of the
statement accountable for the statement they make. The SCITT registry
cannot by default make a statement trustworthy. What we can say is that
a certain statement is present and there is a cryptographic proof. The
relying party then has to process the statement and make a decision.

Ray: Worried about the confidentiality of SCITT registry.