SCITT Virtual Interim Meeting - 12.06.2023

Agenda

• Registration Policies

Notes

• Ray working on air-gap environment contribution/doc
• Jon Geater has now committed working end-to-end code for t116
  hackathon with a live service (RKVST back end) alongside the
  MS-contrbuted emulator. Code currently on a branch (will make a PR
  once docs are updated. The code is done:
  https://github.com/scitt-community/scitt-api-emulator/tree/116-hackathon-rkvst-implementation)

Registration Policies

• Open Issues in the GitHub Issues: Tagged Registration Policy
• Henk: believes we need at least trust anchors.
• Jon: Arch Doc currently uses Registration policies as gatekeeping
  entries. Believes we need to be more flexible, using identity
  relationships
• Jon: There are two challenges from discussions in the past: Formally
  specifying identities (e.g. DIDs). Registration policies covering
  contextual aspects (and having a semantic understanding of the
  payload itself).
• Capturing the registration policy, at the time a registration was
  made
• Orie: The primary complication is the dependency between different
  envelope formats. For example, if you are storing your policy in the
  TS and you want to reflect the policy at which the transparent
  statement was produced. You can include the policy in the
  transparent statement. This can get complicated.
• You need to discover the keys for the issuers.
• Hannes: Can we simplify the design?
• Orie: Yes, we initially didn't have the policies in scope. We can
  also just reference policies and later worry about the details.
• Yogesh: A bit of registration policy could be an implementation
  issue. Just focus on validate the issuer - focus on what to do (with
  verification of identities) rather than how to do it.
• Ray: I agree with Yogesh. The TS is acting like a proxy to what
  would be the other side of a TLS connection.
• Roy: A product build with SCITT, the ledger portion includes the
  identity providers youre going to evaluate. Need to know what the
  policy bar is, before you accept the receipt. Anything we have a
  receipt for, must have passed a policy, but what policy was
  evaluated? Need to capture these.
• Henk: Everyone agrees that we need a list of public keys (=trust
  anchor). How are these represented? Where to store it/ where to find
  this information? How to find it (identifers)?
• Neal: Relying parties will have to make decisions. Try to simplify
  as much as possible. I see Sigstore as a great example making simple
  decisions. Just restricting statements to specific issuers ignores
  situations where issuers are compromised. Using TUF to deal with
  revocation and key rollover is a good, well-vetted approach, so TUF
  could be considered a useful example of a registration policy.
• Yogesh: Entity X registers with TS and has 5 products. It can use
  any key to sign the statement but it does not need to be a
  registered key.
• Roy: The transport mechanism isn't that important.
• Ray: Compares it with Let's Encrypt and the domain verification it
  provides.
• Charlie: Totally agree with Yogesh. If I know the party, I don't
  need a bunch of verifications.
• Edoardo: I understand to keep it simple. Removing policies entirely
  might remove some use cases.
• Charlie: My use case is a medical device that has software/hardware
  and that there is a way to track the parts, ownership, etc. I would
  like to spend more time on the payload, compared to the
  infrastucture, suppliers, ownership, companies of origin. Things
  I'll have to be concerned about whent the regulators show up.
• Ray: The payload is better done in schema.org. Maybe do what RATS
  did with their verifier and we provide the mechanism for people to
  use and not to detail how exactly it is done.
• Roy: The definition of SBOMs, etc. is done in other groups, outside
  the IETF. The difficult with RATS is: how do you know when things
  have changed?
• Ray: Please explain us how this works.
• Charlie: We haven't spent much time on how to use the SBOMs
• Hannes asks Roy to start a discussion about this topic on the
  mailing list.

Hackathon

Voting Topic