Minutes interim-2023-scitt-04: Mon 16:00
minutes-interim-2023-scitt-04-202301301600-00

SCITT Interim Meeting

Chair: Hannes Tschofenig and Jon Geater

Note takers: Kiran Karunakaran, Kay Williams and Brian Knight

Use case document review-
https://github.com/ietf-scitt/draft-birkholz-scitt-software-supply-chain-use-cases/pull/18/files

Dick: Need to resolve the distributor role in first use case
Yogesh: Use cases for SCITT WG is more high level because we cover all
software supply chain
Use case 1: Verifiable authenticity in Sw distribution system
Roy: There are at least 3 roles?
Dick: Yes. SW producer , signing entity (authorized by supplier),one or
more distributors. Trust relationship should be established between SW
producer and signing entity
[Added later: note confusion over what it means to "sign" something]
Neal: How does a verifying party know that particular signing entity is
authorized to sign the package?
Yogesh: Addressed in the use case. Solution will be available via the
architecture doc
Neal: Why can't the supplier sign it themselves? Policy becomes a lot
complicated otherwise
Roy: EO believes self claims is a good start but not enough. Having 3rd
party endorsement is next step.
Neal: Signing authority role is somewhat opaque
Roy: Producer produces evidences and auditor provides endorsement
Mike: Solutioning is important but now we need to focus on if the roles
are properly captured and the use cases should be solid.
https://www.theregister.com/2023/01/30/opinion_eu_foss_security/.
Queueing to speak to supplier self attestation
Charlie: Auditor is a fuzzy role. Supplier should have full ownership
Yogesh: Multistakeholder evaluation use cases cover that
Dick and Henk: Roles exist but can be served by the same entity (ex:
Microsoft produces,signs and distributes). 3P and 1P attestations will
involve producers working at different capacities and roles
Mike: 1P attestation sets up trust but verify.
Neal: "Signing authority" terminology needs to be reviewed. We do not
trust one entity as a whole. We need to qualify the role (how policy is
managed)
Hannes: Additional verification is needed; not just a digital signature
for the 'signing authority' role
Dick: In the use case doc, we're talking roles and not entities. The
roles are fulfilled by entities that could be the same for all roles
Orie: People can "sign anything they have"... but there is often no
reason to trust an issuer to make claims about subjects they have not
authority over
Henk: It is about
1.) who signed
2.) what information is added by that
3.) is that entity authorized by a supply chain party
but that also already delves into solution space - we need generic use
cases and have to take care that they are mostly in the sweet-spot
between being solution/use case and specific/generic
+1 Dick, roles and entities separation
Jon: Registry will provide accountability
Ray: You can only sign for yourself. This also includes delegation
statement. We should do away with signing authority
Jon: +1 for signing only for yourself. Attestations are witness
statements. They take responsibility for a claim
Henk: +1 to Ray. We're taking account of the problem here (use case
document).
Roy: Producer's do not have complete control of who\what makes
additional claims on their product. Antimalware companies will produce
evidence and "my" company will make an endorsement as to whether or not
their employees CAN use that product.The producer does not control that
statement.
Neal: Verifiability is key (policy enabled)
Hannes: 3 use case (Jon's use case,verification use case (Neal) and
update Dick's use case)
Henk: Use the PR/issues to help update and improve the use case
Ray: The term "signing" is overloaded, and if we separate the meaning
then this will resolve this I think.