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][1] * \[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 [1]: https://github.com/ietf-scitt/draft-birkholz-scitt-architecture/issues/34