# SCITT at UETF 118 {#scitt-at-uetf-118} ## Agenda {#agenda} * Welcome and Introduction (5 min): Chairs * Why SCITT is COOL (5 mins): Henk Birkholz * Recap since 117 (5 mins): Henk Birkholz * Registration Policies (15 mins): Jon/Cedric * API & Receipt Updates (15 mins): Orie Steele * Hackathon Report (15 min): Jon * Next Steps and WG operations for 119 (15 min): Chairs * AOB Open Mic (20 min – BE CONCISE!): All * Wrap-up and Conclusion (5 min): Chairs ## Notes {#notes} * Recording: https://www.youtube.com/watch?v=zEGob4oqca4 * Chair Finish brief introduction. * Why SCITT is COOL (5 mins): Henk Birkholz * Need authenticity *over time*: things change, key material gets lost, ... * Importance to maintain authenticity over time * CBOR usage introduction for SCITT, together with CDDL and COSE * issuer created statements are always opaqe, and stored in an append-only log, which can be queried and audited later * Applications interact with SCITT * A receipt, issued from the Transparency Service, as a result of registration, provides proof * Issuers sign statements, and the Transparency Service verifies the identity of the signed statment and notarizes them with a counter singnature if the signed statement is registered. * Recap since 117 (5 mins): Henk Birkholz * Recap of the PRs since 117: weekly meeting about use cases and architecture document contents, hackathon preparation, new Feed definition... * Mike Jones: CWT Claims and headers finished last call * Use Case Working Group Last Call this week, please provide feedback via scitt@ietf.org * Orie, AJ and MCR have volunteered to read the Use Case docs * Registration Policies (15 mins): Jon/Cedric * A simple set of rules to be evaluated by the Transparency Service to determine admissibility of a Statement * A small number of requirements * Payload agnostic to make it interoperable * Can't predict all use cases or payloads as it's up to the application layer as they develop * Stored data structure needs extensibility * General access control concerns: API, Anti-spamming and issuer must be authenticated and identifiable to submit/register a signed statement * SCITT enables entities (issuers) to make statements about things (artifacts) * The collection of statements are associated through a `CTW_Claims.sub` * The SCITT structures provide these primitives to facilitate interoperablility * Recent breaktrhoughs in the spec are specific to registration policies. * Cedric Fournet: * Recap of registration process, where an issuer signs a statement, submits to the transparency service, and a registration policy evaluates, using a registration policy * https://scitt-community.github.io/scitt-api-emulator/registration\_policies.html * Registry policies are configurations * Configurations can be updated * The statement will have a registration policy (config) statement id that identifies which regisgration policy was enforced for this specific statement * Verifiers can validate the receipt, even if they can't connect to the Transparency Service * Several open questions * Terminology on registration and/or configuration * Application profiles? * Sequence of signed statements for configuration * API & Receipt Updates (15 mins): Orie Steele * 2 parts: CBOR definition for statements and receipt, the transport aware API for these messages * transparent statement = signed statement with a receipt * Learning CDDL is super helpful at understanding COSE and SCITT * Recap of the CBOR & SCITT specific headers * REST API * Roman: IETF does support APIs * Explination of Feeds, using an example of making soup - not to be confused with an SBOM documentation * Roman: while we're discussing soup, the scope of SCITT is currently using Software Supply Chain * Back to software and firmware - they're like soup * Dan Druta: catch 22 with the questions and answers - how can I create a template for what questions will be asked * Orie: a registration policy can specify the type of requirements that are needed to be registered * Discussion if the `sub` in the example should be LDevID or IDevID. These are examples of how an issuerer can specify whatever they'd like to group a collection of statements. * In a software supply chain domain, you may see specific artifactTypes, such as SPDX SBOM, Cyclone SBOMs, SLSA, VEX, Vendor Response Files, or an updated VEX as new information is learned * Hackathon Report (15 min): Jon * Strong participation at the hackathon * Spec focused, with some code * A lot of focus on the registration policies, with a client/server type relationship * Intermixing of Config and Registration information, as both are needed to be known in relation to what was evaluated, or configured when the signed statement was registered. The receipt will indicate all configurations and registrations * Had explored specifying a registration configuration format. * We decided to make it a transparency service specific implementation. * Furthered work on federation * Furthered work on API access control * https://scitt-community.github.io/scitt-api-emulator/oidc.html * Proved out DID resolution and verification * RKVST implementation eliminated need for translation proxy  * Begun collecting illustrative examples to help know when the building blocks satisfy the use cases * Federation POC from John Andersen * Uses Activity Pub from W3C * Exmple at: https://asciinema.org/a/619517 * Additional examples: * https://github.com/scitt-community/scitt-api-emulator * https://github.com/scitt-community/scitt-examples * Next Steps and WG operations for 119 (15 min): Chairs * Suggestion that weekly meetings are too many * More important to work in the mailing list, with topics and PRs * Thank you to Hannes for his contributions over the last year as Chair * AOB Open Mic (20 min – BE CONCISE!): All * Henk: The Countersigning COSE Envelopes will go away as we'll focus on Cometer. SCITT will frost over other specs * Timestamps are available within the CWT\_Claims * Simon: Friedberger: what's missing is a mapping of the metadata to the use cases. There seems to be a contridiction as we speak to content being opaque. * Jon: The group wants to be careful to not re-discuss/document specific content types, like SPDX and CycloneDX * Orie: Involved in other use cases at IETF, including Post Quantum. SCITT uses COSE to enable the different types of algorythms. * Massimiliano Pala: Are you considering of problem for tracking crypto, such as software upgrades. * Steve: the new content types, such as PQ are great exmaples of SCITT being content type agnostic, to support all these new content types that issuers may want to express on artifacts * Manu Fontaine: suggest symetric signature and symetric cryptography to solve the integrity of the agent. The agent can use symetirc keys. * Daniel: Briefly mention w3c introducing a transparency log. It was brought up to build upon SCITT. Have a preliminary proposal in a WICU. Source Code Transparency - Hannes suggestion to share with the list * Ned Smith: question on whether the tomatoe is fresh * Orie: classic notary example, where the notary doesn't quantify the validity of the content. Rather the issuer valid. Do they have valid key material? * Cedric: it's not really the job of SCITT to verify "tomatoes". * Ned: compromise is the type of check they did, was put in the issuer claims (statement) * Chunchi: related to certificate transparency. There's a new model for more effecient merkle trees. * Wrap-up and Conclusion (5 min): Chairs