Minutes interim-2023-scitt-09: Mon 16:00
minutes-interim-2023-scitt-09-202303061600-00

= SCITT Meeting Minutes - 6. March 2023

Minute Taker: Hannes Tschofenig, Kiran Karunakaran

Agenda: Architecture Terminology

Note: last day for use case draft submission adoption so please respond
to adoption email

Ray:
https://docs.google.com/document/d/1qYljgugcraiamGjrhldQ1ZEoa4i_TkM3tzBg8yNzE_E/edit#heading=h.co0spmno33yj

PR From Henk:
https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/16

Ray explains his diagram/figure for what a SCITT registry looks
like.This is a high level overview.

Submitter side:

• Individual users and users with delegated authority to act on behalf
  of organizations, Organizations themselves
• Products and product lines
• Policies (pre-submission filter and post submission)

Registry Viewer Side

• Aggregation
• Evaluations (these are not part of registry but additional
  validation)
• Trustworthiness is established not in the ledger but through
  aggregation process
• RATS verifier
• Ledger is append only (basically a database). Ledger entry size is
  (typically) limited. There is bulk storage related to ledger and
  there is external storage
• Private storage for confidential RBAC

(Ray also mentions expectations for the RESTful API to query the
transparency service/SCITT registry.)

Roy: The behavior and contracts of external storage has yet to be
written down. Something to do

Steve: Flow diagram adds context to overall flow. It looks like left is
producer and right is consumer. Question for me: What is assumed to be
inside the SCITT registry box and what is outside? Mentions example
based on email spec vs. emails servers (real-world products). Links for
internal/external:
https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/18
carried over from the previous repo. Also refered in
https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/7#issuecomment-1456474733

Ray: You need to know who can submit to the ledger. So, you need
information about their identity. Establishing trustworthiness is
outside the scope of registry but is important

Hannes: Establishing trustworthiness should be outside the transparency
service. We should represent a minimalistic figure for this purpose.

• Boxes regarding "B2B Evaluations" and policies for "establishing
  trustworthiness of software" should be outside the box
• Users and users acting on behalf of organizations should be compiled
  into one box
• Product lines and product releases should be abstracted to
  artifacts.

Ray: Can't get rid of differentation between product lines and product
release since product line covers product info, releases cover the
release process

Charlie:

• The user part is required functionality.
• We probably don't want to solve the hierarchy of products.
• The RATS entities should be in the ledger.
• The CA is a bit of "magic here box".

Ray: The RATS entities cannot be in the ledger. The RATS verifier is not
part of the registry and would be a user of the SCITT registry.

Roy:

• There is a distinction of what is in the diagram and what is in a
  product.
• Regarding RATS, it is possible that the machines submitting the
  statements have to provide attestation information. This gives us
  evidence of where the issuers are running on.
• The CA is just there but it has to have policies on who to trust.

Jon: Keep the specifics (SW,HW) out of SCITT diagram and make it
generic.
Can we use the "feed" concept, which we have already developed.

Neal: The diagram is helpful to frame the functionality. Steve has done
a great job in the document comments to link to architecure repository
(issues) and we should go back to that document. Use this content to
frame the issues like scalability (like a feed from the architecture
related to how a user would find product lines). It would be good to
describe the scalability aspect. Can this thing scale to the extent we
envision?

What is our timing regarding the draft publication?

Henk: I understand why RATS is in the diagram. All of the boxes can
benefit from the RATS functionality but in the first iteration I would
remove the RATS functionality for clarity.

Ray: I did not try to start from the existing architecture. I did a
clean slate and went from there. I don't think you will get away from
mentioning organizations. Most software and hardware things will benefit
from product lines and product releases.

Hannes: How can we update the document to capture all email and comments
feedback?

Steve: There are 2 pieces here: technical accuracy of the terminology
and how can we convey the right message to readers. Track action item in
issues

Hannes: We have till next Monday to submit the architecure doc.

Neal: Can we accept the PR #16: Vast Terminology Overhaul ? There are
still some things to tweak in it, but it would help make the document
more readable I think. Is there a pushback here?
https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/15

PR:
https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/16

Henk: It is worthwhile to merge since otherwise it is clunky to handle
it. Some of the change request come from Orie and from Ned. Merging this
PR will include a ton of language improvements.

Hannes: Create a snapshot of the document that captures latest and
greatest understanding we have of terminology

Hannes will read through the PR and reach out to various contributors to
see whether we can merge the PR and what issues need to be recorded (if
they haven't captured already).