Skip to main content

Minutes IETF115: scitt: Thu 09:30
minutes-115-scitt-202211100930-00

Meeting Minutes Supply Chain Integrity, Transparency, and Trust (scitt) WG
Date and time 2022-11-10 09:30
Title Minutes IETF115: scitt: Thu 09:30
State Active
Other versions markdown
Last updated 2022-11-10

minutes-115-scitt-202211100930-00

DRAFT SCITT Agenda, IETF 115, London, UK
Donnerstag, 10. November 2022
09:30 - 11:30 Thursday Session I

Note takers: Kay Williams, Steve Lasker

  1. Welcome and Introduction (5 min): Chairs

    • [Roman Danyliw] Introduced new chairs Hannes Tschofenig and
      Jon Geater
    • [Hannes] will send out a doodle poll for regular SCITT
      meetings
  2. Problem Statement / What Is SCITT (5 mins): Orie Steele (Transmute)

  3. Software Supply Chain Uses Case (15min): Yogesh Deshpande (ARM)

  4. Architecture (30 mins): Antoine (Microsoft)

    • Discussion on Overview Slide
    • [Dave Thaler] Terminology confusion verification, evidence
      have different meaning in RATS
    • [Antoine] Claim terminology is subject to change
      See Issue: Converge Claim and Statement #34
    • [David Thaler] It would be useful to draw comparisons to RATS
      specifications
    • [Henk Birkholz] If verifier looks into claims, then verifier
      is more like in RATS. Claim is used in a different way in RATS.
      Mapping from SCITT terminology to RATS will give a way to
      improve in the end.
    • [Yogesh Deshpande] Yes, there is some overlap in terms.
      Suggest these can co-exist as long as there is clear
      descriptions.
    • [Dan Drulta - ATT] Question 1: Is there a need for a forked
      verification process, Question 2: Who is the issuer, in the
      Log4J case, there are different issurers.
    • [Antoine] (notes nto captures)
    • [Henk] SCITT provides scalability and offline verifiability
    • [Elliot Lear] Incorporate claim in packaging. Important that
      trust anchos be in place so that trust is possible. Needs to be
      enough information so that viewer of receipt can contact the
      issuer.
    • [Antoine] Verification can happen offline
    • [Brendan Moran] In firmware case you probably don't want to
      deliver all claims to device. SCITT transparency service
      provides a standardized way to store claims.
    • [Mike Prorock] Software package fixed at some time. Being able
      to go back and have a record of what happned in time all in one
      place is valuable. Intersection of time and statements all in
      one place helps with this.
    • [Erik Nordmark] Want to track most recent version of software.
      What is scope, it could be balloon intonn something very big.
    • [Antoine] It could indeed baloon very big. Won't be a single
      transparency service for everyone. Also there will be simple
      notaries that will provide some claims. In summary, complexity
      of notaries in the wild.
    • [Wei Pan] Will Microsoft expose which employee wrote code on
      the transparency service.
    • [Antoine] Question is related to privacy. Should this
      information be released or not. In general, this is a choice of
      the notary. If you want to only partially release this
      information, you have control over information submitted to the
      registry, including access controls.
    • Discussion on Verification & Audit Slide
    • [Brendan] Is the auditor auditing the claim or the signing
      information only.
    • [Antoine] What type of audits are supported is an open
      question
    • [Orie] Three cases for audit - specific claim, set of claims,
      entire transparency registry (this last one would be very
      expensive)
    • Discussion on Security Goals Slide
    • [Dan Drula] (ATT) Issues are verifiers get replicated. How
      will inter-registry trust be implemented?
    • [Antoine] Important question and not easy. Will be addressed
      in Hackathon report
    • [Orie] Discussed inter-leger trust at Hackathon, slides and
      diagrams in Hackathon section of the deck
    • [Dave Thayler] please elaborate on ...
    • [Dave Thayler] definition of correct - same answer (correct or
      incorrect) to everyone.
    • [Jon Geater] you have to have registered your claims in the
      past, you can't selectively lie, cheat, etc. Whole system
      responsibility
    • [Diego Lopez] Transparent registry is not going to make
      additional checks because in that case the notary will become an
      issuer.
    • [Antoine] Accepting registry of a claim is a form of
      endorsement. Baseline is for registry to verify signature.
    • [Diego Lopez] Can an issuer say 'I received this and tested
      it'?
    • [Antoine] Yes
    • Summary
    • [Hannes] Call for adoption of architecture so that it can
      continue to be discussed on the mailining list. Use 'show of
      hands' tool.
    • [Hannes] Poll results - 36 for adopting, 3 against adopting
  5. SCITT Receipts (15 min): Maik Riechert (Microsoft)

    • [Hannes] Any imemdiate feedback on the receipt?
    • [Carsten] (thumbs up)
    • [Hannes] Next steps - use case document needs to be rewritten
      and approved, architecture document needs updating (including
      terminology). After that, push forward to COSE receipts)
    • [Roman] First agree on what problem we want to solve, and then
      how to solve it (e.g. Receipt)
  6. Hackathon Report (30 min): Henk Birkholz (Fraunhofer SIT) and Orie
    Steele (Transmute)

    Henk's Slides

    • [Brendan] Similar concept in SUIT
    • [Henk] Yes, but will need to be discussed in SCITT
    • [Michael Prorock] Affirm that some statements will be big.
      Also, notice conflict on terminology from slide to slide
    • [Henk] Will need to discuss in the working group, have a few
      good proposals for WG to discuss
    • [Michael Prorock] Example outside of software... in US, Food
      and Drug Agency (FDA) has specified content that must be
      provided. SCITT provides a mechanism for tracking and verifying

    Orie's Slides

    • [Erick Nordmark] FIPS not a great example
    • [Orie] (acknowledged)
    • [Mike Prorock] Did the topic of ?? come up
    • [Orie] Receipt 1 is there and can be given to anyone who
      needs. Did I answer question?
    • [Mike] No. Does author know who is requesting a claim.
    • [Antoine] Comment on idea that when you are consuming a
      receipt it is always downstream. Not always refer to depencency
      by value. Sometimes want to refer to claim by URI
    • [Orie] How do I find all receipts for a specific product (e.g.
      device driver)
    • [Yogesh/Orie] Who is using receipt is at the discretion of the
      people who hold the receipts.
    • [Carsten Bormann] Want to have choice. User does not have
      choice of which transparency service to use. In the end
      important for who system to have certain quality with regards to
      privacy. E.g. I will only work with transparency services that
      provide certain privacy guarantees.
    • [Orie] Discussion of registration policies, e.g. issuer, size
      of statement, etc. User can decide when service to submit data
      to.
    • [Carsten] Different actors may have different privacy needs.
      Can imagine transparency services that improve the guarantees of
      other transparency services (e.g. heighten privacy)
    • [Antoine] Once claim is issued there may be access control.
      Perfectly acceptable for same claim to be registered on multiple
      transparency services.
    • [Dan Druta] Like the way this is depicted. How will we
      implement in a SAAS model? You don't know what you are running
      on top of as a customer. I represent an operator. Risk
      management is an important thing. How do I mitigate risk -
      shutdown service, etc. Want to do things from the other way
      around.
    • [Orie] Yes - also want to support other direction. Start with
      final artifact and trace backwards. Make it easier to identify
      information that is relevant to risk assessment.
    • [Dan Druta] To be clear - from user and operator perspective
      want to know...
    • [Isaac Hepworth] want to know if policy changes how does that
      affect analysis of receipts
    • [Orie] discussion on need for communicating changes in policy.
      Provide a new receipt that notifies of policy changes.
    • [Isaac] Malicious operator of transparency service
    • [Orie] Multiple trees in transparency service. However,
      trusting transparency service operator to manage both trees
      appropriately. Might need to have multiple transparency
      services.
    • [Isaac] Timestamp integrity?
    • [Chris Inacio]If you don't trust transparency service 1, you
      resign? Time matters a lot. If you don't trust transparency
      service, then as an issuer you need to submit to multiple
      transparency services.
    • [Orie] if you submit to multiple transparency services then
      you will have different times at both services
    • [Henk] A transparency service is not a monolithic node.
      Discussions also under Confidential Compute Consortium (CCC),
      Remote Attestation Protocols (RATS). Didn't want to bring up
      complexity of timing in first session, but we are thinking about
      it.
    • [Antoine] Say a few words about policy and policy updates. As
      verifier want to understand policy. As issuer, may want to
      indicate what policies are applied, e.g. sequential claim.
      Declaration of policy that can be interpreted by verifiers. Also
      aspect of freshness which is important. If you are using a piece
      fo code, want to know you are using the latest version. As Orie
      mentioned, you can specialize types of receipts.
    • [Orie] One point on registration - each claim evaluated
      against registration policy of each service. Policies or aspects
      of policies can be shared across transparency services.
    • [Antoine] Also important to be able to audit that registration
      policies were enforces
    • [Yogesh] In confidential computing we talk about workload
      measurements and attestations. (to address Dan's earlier
      comment) Tho we have not explicitely put a slide that goes the
      other direction, we have not ignored that scenario.
  7. AOB (Open Mic) & Next Steps (15 min): Chairs

    • [Dan] I like this work and think it will benefit companies
      like mine immensely. Didn't hear a word about SBOM. Perhaps that
      was implied. Acknowledge fact that there are already standards.
      May come out as we are decomposing standards into atomic
      components.
    • [Yogesh] Use case slide does mention SBOMs (SPDX, CycloneDX).
      What we are providing is on top of SBOM where we are providing
      transparency suggestion
    • [Wei Pan] Example specific content. Statement may say 'refer
      to this url'
    • [Orie/all] Yes this is allowed (and covered in hackathon
      content)
  8. Wrap-up and Conclusion (5 min): Chairs