Note: Meeting notes has been moved to the project account's Hackmd https://hackmd.io/@EG2api1FTUudGEK6PMjvuQ/rk30ceMAyl TUF-notary meeting notes NOTE: Time Change - Starting May 9 2022, we will hold two meetings a a week to account for folks in the US, Europe and Asia times. Meetings are now: Mondays 5-6pm pacific time, 8-9pm US Eastern, 8-9am Shanghai (US Summer time) Mondays 4-5pm pacific time (US Winter time) Thursdays 9-10am pacific time, 12pm US Eastern, 5pm UK

Bi-weekly on Fridays 8:00-9:00 pacific timeSee below for the next scheduled meeting and proposed agenda Links GitHub Zoom Dial-in link Calendar/ics go-cose-community email distribution group YouTube Recordings

tags: ietf-scitt ORAS References ORAS Installer oras push | attach Snippets echo "hello world" > artifact.txt echo "vex response" > artifact.vex oras push ghcr.io/wabbit-networks/artifact:v1 \

tags: ietf-scitt Examples To support the SCITT Use Cases, the follow examples are illustrated. Integrating SCITT With a Build System Topics to cover: [ ] How to structure SCITT Feeds [ ] How to correlate each build artifact with previous versions

Feed Hierarchy and Properties SCITT defines a feed as: an identifier chosen by the Issuer for the Artifact. For every Issuer and Feed, the Registry on a Transparency Service contains a sequence of Signed Statements about the same Artifact. In COSE, Feed is a dedicated header attribute in the protected header of the Envelope. To provide more structure, we have a tracking issue: Refine Definition of Feed #11 This document outlines a potential structure for feeds, enabling submissions and queries around a specific platform and version of an artifact. Although these may be header properties, rather than a hierarchical structure.

tags: scitt List of items we'd like to discuss in the weekly IETF SCITT Working Group meetings. This is a temporary place holder until we have an IETF GitHub org to create "issues" for triaging for the meetings Note: this is the IETF Specific topics. We'll have a separate list for SCITT Community discussions that are broader than the IETF I-D's. Item Link to Doc/Issue

tags: scitt For the following scenarios, where is each artifact and/or statement persisted? The following table is a work in progress, to faciliate discussion. A target/goal would be end users download artifacts, claims/statements and supporting evidence from the same location. This isn't just a browser skin across multiple services, rather the integration of the services so users configure one set of network endpoints to get artifacts, claims/statements and evidence from the same endpoint. While we can overlay SCITT APIs on existing services, not all storage services support all content types. artifact artifact storage

tags: scitt Saturday, 5th November Note taker: Maik Sylvan Orie Antoine Cedric Yogesh

Target Audience This is for you if you are: A container image maintainer who frequently needs to fix image vulnerabilities found by scanners. Someone overwhelmed by image vulnerability scan results. Scanning images turns up a lot of vulnerabilities. A lot of vulnerabilities are unactionable, such as vulnerabilities in a base OS image that doesn't have a fix yet. A vulnerability responder who cannot determine "ownership" for fixing a detected vulnerability.

NOTE: The most recent version is published to: Proposal: Decoupling Registries from Specific Artifact Specs #91 When the distribution-spec and image-spec were created, they were uniquely focused on the container image workflows, which made sense at the time. Some generalization was built in, and it's gotten various implementations to a great steady-state. However, these are now at a point of success, where we need to consider how these efforts move forward. This proposal brings forward a recognition that: Registries are implementations of the distribution-spec Registries store more than just container images Registries, images and other artifacts are each trying to innovate and evolve independently

As cloud native development continues to automate the consumption of upstream content providers, the ability for automation to make realtime, informed decisions becomes critical to keep the automation wheels spinning. The speed of development and consumption has reached the point where cracks in the system are always present, even if not immediately seen. The ability to leverage new information against facts on artifacts already in our environments are key aspects of analysis. The time shifted analysis continually improves the hygiene of the artifacts we consume, build and distribute. Signing, Systems Bill of Materials (SBoM), Security Scanning and Registries play major roles in how you build, secure, distribute and consume artifacts. But, what are the roles and responsibilities of each? What should be included in an SBoM, and what are the expectations of signing? If you have a signed SBoM, do you even need to run security scanning software? In this article, I'll cover an opinion for the roles and responsibilities of each as security is an always evolving standard, with multiple lines of defense. Side note: the SPDX and MITRE groups use Systems Bill of Materials, as opposed to Software Bill of Materials to reflect IoT and other hardware based device scenarios. Systems Bill of Materials (SBoM) & Tacos You're planning a party for the end of COVID-19. Some of your friends are gluten-free and some are vegetarians. The menu is Tacos, 'cause who doesn't love tacos? You order gluten-free corn and flour tortillas, a variety of vegetables, and of course, avocados to make fresh guacamole. You even plan separate serving areas and utensils to not cross contaminate.

Notary v2, Alpha 1 enabled: [x] Offline signature creation [x] Signatures attesting to authenticity and/or certification [x] Maintain the original artifact digest and collection of associated tags, supporting existing dev through deployment workflows [x] Multiple signatures per artifact, enabling the originating vendor signature, public registry certification and user/environment signatures [x] Signature persistance within an OCI distribution-spec based registry, with oras artifacts spec enhancements [x] Air-gapped environments, where the originating registry of content is not accessible [x] Artifact and signature copying within and across OCI distribution-spec based registries, with oras artifacts spec enhancements [x] Verification of signatures, through a configuration based policy

# OCI Artifact Signing - Scenarios As containers become the [common unit of deployment](https://stevelasker.blog/2016/05/26/docker-containers-as-the-new-binaries-of-deployment/), users want to know the artifacts in their private registries and the artifacts deployed are the same artifacts that were initially published. The [OCI TOB][oci-tob] has adopted [OCI Artifacts][artifacts-repo], generalizing container images as one of many types of artifacts that may be stored in a registry. Other artif