Minute taker: Hannes Tschofenig
Much discussion over several weeks in SCITT has circled around complex
issues of Registration Policies which has started to hamper progress.
Sub-issues such as Identities, security guarantees, and Feed integrity
have all been brought into this which in turn has begun to threaten the
clean architectural layering of SCITT.
Proposal: vastly simplifying normative content around registration
policies and semantic data handling will satisfy all camps better than
trying to embed every use case in a generic data layer.
Cedric: We want to be selective about what we want to be normative.
Currently we have very little normative. At the same time, for practical
systems there will be a registration policy. Because it will be specific
to a given application domain it will be difficult to be more
prescriptive. Currently we are not putting a lot of pressure on
implementations because some policies might require sophisticated
checks.
There is a registration info header, which is provided as input by the
client. I see this as an example.
RBAC is an accident.
Jon: This makes a lot of sense. I would like to clean up a number of the
sections and, while not normative, it can be confusing. I want to make
it very clear that those are examples.
Cedric: The registration info policy is security relevant.
Roy: I don't understand how to present the identity information in the
registration.
I didn't got this from the text.
Jon: This is not what I have been looking at. The content of the
identity in the receipt registration is important.
Jon: Every feed includes statement with signed statements from the
platform. [Describes the system level solution].
Roy worries about the interoperability of federated deployments of
different systems (like SCITT, Sigstore, etc.).
Hannes: What should we do to get the draft updated?
Jon: I am fine with your text. I can write text about the feed scope.
Cedric: Jon's and Roy's examples are instances of a registration policy.
Dick: Supporting what Roy said. We have to trust the registries. We have
real world example of how this works today. It is up to us to define how
to define how these registries are supposed to work.
Ray: I am in favor of keeping things simple. We have to try this out and
get something working.
Mitja: Which is the version being submitted on Monday?
Hannes pointed to the Github repo.
Ray points to the term "feed". It has a different meaning for me.
Henk: The feed is a topic (similiar to pubsub model) is about a product.
The minimal registration policy is about issuer's identity.
Orie: Who is allowed me to send signed statements? Is there any metadata
in the signed statement that would be useful? I could have a policy that
says that this issuer is only allowed to post statements about fish.
Roy: How does a feed fix this problem?
Orie: The feed is just one part of the solution. The registration policy
is a different part of the solution. Different domains will have their
own policies.
Roy: We have SBOMs etc. for a product. How do I detect when a
configuration has changed? How do I know when the TS has changed the
settings?
Orie: You cannot detect those changes today.
Hannes suggested to Roy to document this issue in the tracker.
Roy: Struggling to deal with cases where the policy changes.
Dick: There is effort under way on how to identify software. You have to
have a unique way to identify software.
Henk: We tried to reach out a few times to the KEYTRANS group, which was
not super successful. At the next IETF meeting we have to talk to the
proponents in person. We have to make sure that we are not creating
parallel structures. I cannot see anything in the charter that would
prevent this.
Cedric: Would be useful how to use key transparency as a supply chain
for public keys.
They need different merkle trees (labeled trees.)
Postponed.