SCITT Interim WG Meeting (Feb 13th 2023)

Chairs: Hannes Tschofenig, Jon Geater
Note takers: Kiran Karunakaran, Neal McBurnett

Agenda Items:

Identity management, and
The submission of the use case draft.

Use Case Discussion

Yogesh: All open issues are closed.Only pending item is Firmware PR
(Monty's use case). We should be able to close this week. Call for
adoption will be next week.
Henk: Merge is pending discussion with Monty.
Steve: Link to the PR:
https://github.com/ietf-scitt/draft-birkholz-scitt-software-supply-chain-use-cases/pull/17#discussion_r110

2974621
Monty: Updating signatures in FW is expensive.Objective here is that
SCITT does not exclude 'after the fact' verification
Henk: The goal here is to ensure that all info/records are available not
just before install but long after
Steve: Are we looking at firmware use case both pre-install and post
verification?- Yes
Charlie: Who manages SCITT here? Is it the manufacturer?
Monty: Manufacturer, another source might be 3rd party verifiers
Steve: We have multiple scenarios (connected,air gap, intermittent)
within the FW use case
Dick: Can we use 3.2 (Multi stakeholder eval of a software product) to
cover this FW use case or connect them somehow?
Yogesh: Can 3.2 and 3.7 combined cover Monty's FW use case?
Ray: This covers the voting machine use case so +1
Brian: +1 to include it. This also provides an excellent avenue to
expand the charter in the future, incorporating Silicon RoT measurement,
which measures the mutable code and non-volatile configuration of bits
in the SoC.
Hannes: In conclusion, good initial version. Add the figure for supply
chain threats diagram and submit the draft this week

Identity Management

Hannes: We need some sort of an identity management that is scalable and
usable. Quality of authentication is critical. OpenID connect addresses
this
Rifaat: levels of authentication which are baked in and available via
OpenID, via e.g. AMR and ACR
AMR - Authentication Methods References
ACR - Authentication Context Class Reference
Steve: SCITT has to be configurable to what identity type is
allowed/applicable via registration policies
Cedric: Want to capture a wide range of entities. Hence the decision to
use DID. Focus for WG is not identity but the supply chain trust issues

Ray: Function of SCITT is providing semantic from hash value. Has to
have the ability for persistence and also maybe have the ability to
remove individual identity from a product
Dick: Varying levels of trust exists and will require different
requirements when it comes to publishing on SCITT instance
Charlie: Owner of SCITT instance is critical for establishing trust
Dick: agree with Charlie, a SCITT "Gatekeeper" needs to be trustworthy
and certified as valid and following defined policies that are intended
to ensure the integrity of the process and information in a registry.
Cedric: I think it is hard to assign a global meaning to an artifact.
Rather, I suggest we focus on issuers making statement about artifacts
they understand, from their viewpoint. Users should not care about
statements made about any artifact unless they recognize and trust the
claim issuer
John Andersen: Would
https://identity.foundation/credential-manifest/#input-evaluation be
helpful for facilitating insert policy?
Cedric: We can use access control on the SCITT server to reduce noise
from random issuers, but letting SCITT decide who is trustworthy is too
hard!
Ray: Collaborative OS software has complex identity that has to be
managed in SCITT
Kathleen: Software issuer or even an accreditation service would be
verified- traceable and ideally completely transparent to user but
available for audit.
Henk: "SCITT instances" are intended to be fueled by "RATS WG output" in
the future
Dick: The entities that operate a SCITT registry and the authorized
parties that can submit statements to a SCITT regitry both need to be
trustworthy and following SCITT defined standards/practices. Integrity
of the process and the SCITT registry are critical success factors in an
SCRM platform.
Rifaat: There are mechanisms or combination of mechanisms within OpenID
to satisfy identity authentication
Cedric: What is critical here is Users should not care about statements
made about any artifact unless they recognize and trust the claim issuer

Steve: Identity gives you context. Choice to trust lies on the user
Neal: The key role of authentication is that identities be reliable over
time. Users of SCITT can't rely on up upfront gatekeeping of which
identities can be trusted for what, or be sure that claims on the ledger
are trustworthy. users / relying parties will have to figure that out
for themselves. Different users will disagree on what to trust.
Henk: Systems that handle the service is trustable. There are other WG
(RATS) working on that goal