Notary v2 Meeting Notes Archive - 2020

December 7, 2020

Attendees:

  • Steve Lasker
  • David Freilich (VMware)

Agenda Items:

  • add your topics

Notes:

  • meeting minutes

November 9, 2020

Attendees:

  • Steve Lasker (Microsoft)
  • Niaz Khan (AWS)
  • Justin Cormack (Docker)
  • Garry Ing (VMware)
  • add yourself

Agenda Items:

Notes:

  • meeting minutes

November 2, 2020

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • Niaz Khan (AWS)
  • Furkat Gofurov (Ericsson)
  • Marco Franssen (Philips - Research)
  • Marina Moore (NYU)
  • Jesse Butler (AWS)
  • Ian McMillan (Microsoft)
  • add yourself

Agenda Items:

Notes:

  • meeting minutes

October 26, 2020

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • Marco Franssen (Philips - Research)
  • Trent Jones (GitHub)
  • Marina Moore (NYU)
  • Miloslav Trmač (Red Hat)
  • Jan Tilles (Ericsson)
  • Jesse Butler (aws)
  • Niaz Khan (AWS)
  • add yourself

Agenda Items:

Notes:

October 19, 2020

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • Justin Cormack (Docker)
  • Furkat Gofurov (Ericsson)
  • Marina Moore (NYU)
  • Sajay Antony (Microsoft)
  • add yourself

Agenda Items:

Notes:

  • Current prototype - supports at least one key
  • New policies would support n keys, and specific keys
  • What are the policies, and how would they be implemented (spec’d)
  • Demo Script
docker build -t wabbitnetworks.azurecr.io/net-monitor:v1 .
docker notary sign wabbitnetworks.azurecr.io/net-monitor:v1 wabbit-networks.crt
docker notary --enabled
docker push wabbitnetworks.azurecr.io/net-monitor:v1

On a different node (conceptually) with the wabbit-networks key

docker notary --enabled
docker pull wabbitnetworks.azurecr.io/net-monitor:v1

Pull fails, as the key doesn’t exist

az keyvault get-key
docker pull wabbitnetworks.azurecr.io/net-monitor:v1

• Because the key exists, pull succeeds

docker tag wabbitnetworks.azurecr.io/net-monitor:v1 acmerockets.azurecr.io/net-monitor:v1
docker notary sign acmerockets.azurecr.io/net-monitor:v1 acme-rockets.crt
docker push acmerockets.azurecr.io/net-monitor:v1
  • meeting minutes

October 12, 2020

Attendees:

  • Niaz Khan (AWS)
  • Miloslav Trmač (Red Hat)
  • Jesse Butler (AWS)
  • Furkat Gofurov (Ericsson)
  • Jan Tilles (Ericsson)
  • Samuel Karp (AWS)
  • add yourself

Agenda Items:

  • add your topics

Notes:

  • meeting minutes

October 5th, 2020

Recording

Attendees:

  • Niaz Khan (AWS)
  • Samuel Karp (AWS)
  • Steve Lasker (Azure)
  • add yourself

Agenda Items:

Notes:

  • Using TUF for root key distribution - Marina
  • Clarify signature validation mechanism - Niaz
  • Suggestions for signature verification based on package name - Niaz
  • Investigate whether public timestamping was considered for TUF and if there were any drawbacks identified - Marina
  • Focus on seom worklfows for where & how keys are acquired to enable signing and verification. Niaz to add to the key managment docs
  • Proposal to move 1 hour earlier to keep the existing attendees and add others that couldn’t make it. Steve to send info out on slack for others to comment.
  • Sounds like Friday key management meetings will merge with the Monday meetings.

September 28, 2020

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • Tero Saarni (Ericsson
  • Derek McGowan
  • Marina Moore (NYU)
  • Trishank Karthik Kuppusamy (Datadog)
  • add yourself

Agenda Items:

  • Key Management update - Niaz
  • Distribution/Artifact design/working session (adding reference and collection artifact type) - Steve, Derek
  • add your topics

Notes:

  • add a collection type that wasn’t index Separate definition - not in image-spec Which manifest type they should use The stuff in image-spec used for other things. The types are defined in a generic way, but not documented as such

Separate into the artifact types Indexes suport other indexes - some registries don’t support as they don’t expect. How many levels deef should I allow? From an image client perspective

Resuing those types is a bit confusing as other clients don’t know how to handle them? Adding config to index is a good start, but we should further seperate from the image directly. Image clients - that’s the bulk of what exists today. I’d rather not touch that part of the definition and define something that’s generic. Derek - not convinced that a signature need to be an artifact. 1:many with immutable tags, but they don’t actually have tags. Special endpoints to fetch them. Should we consider endpoints that are specific to signatures More optimial for clients Give me all the signatures for this type Does it really fit in with other artifacts. Is a signature meta-data on an artifact.

Marina The order of signature discovery Do you start with the artifact, then the signature Of the 10 signatures on an artifact, how do I know to only download the 1 I care about

Derek Are attributes a way to identify which signature (generic thing) I actually want (filter upon) Is there a general way, or a specific way to get signatures Today, we thing of tags (sometimes digests) and things that refer to it

Ordering is critical to the success How do we get the digest we trust, from the tag

Different types

  • Artifacts
  • Meta-data - data on a specific object
  • Signatures
  • are tags just special types of metadata
  • Referneces can/must be capabile of cross repo scenarios (helm chart refences wordpress and mysql)

Clear we need an extension to the distribution api - should we add a signature api?

Separate out the searching/filtering from a single repo to across repositories

Serge - do we support signatures across repos? - do we every want to rule this out? Derek - questions on security challenges Notion of cross repo mounting exists today If a user pushes a refernece to something they don’t have access, how is that evaluated

  • meeting minutes

September 21, 2020

Recording

Attendees

  • add yourself

Agenda Items:

Notes:

  • meeting minutes

September 14, 2020

Recording

Attendees:

  • Jan Tilles (Ericsson)
  • Samuel Karp (AWS)
  • Jesse Butler (AWS)
  • Furkat Gofurov (Ericsson)
  • Serge Hallyn (Cisco)

Agenda Items:

  • No specific items - will join for conversation
  • add your topics

Notes:

  • Progress has been on the distribution aspects which will enable signature persistance, but no specific updates to report in the nv2 prototype this week
  • meeting minutes

September 7, 2020 - cancelled

August 31, 2020

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • Tero Saarni (Ericsson)
  • Marina Moore (NYU)
  • add yourself

Agenda Items:

  • TUF demo (Marina)
    • Some new TUF features that address scalability concerns
    • How TUF can be used with private repositories
  • Open Discussion on progress thus far (Steve, et all)

Notes:

  • meeting minutes

August 24, 2020

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • Marina Moore (NYU)
  • Justin Cormack (Docker)
  • Samuel Karp (AWS)
  • Jesse Butler (AWS)
  • Miloslav Trmač (Red Hat)
  • add yourself

Agenda Items:

Notes:

  • Create an nv2 branch for prototypes, leaving main for the ultimate reference implementation
  • Open issues for open topics in #2 PR
  • Distribution Spec PR
    • Index reference doesn’t explictly declare no tags - needs this for clarity
    • Add a multi-arch example of signed content
  • meeting minutes

August 17, 2020

KubeCon EU Virtual

August 10, 2020

Video recording

Attendees:

  • Steve Lasker (Microsoft)
  • Justin Cormack (Docker)
  • Marina Moore (NYU)
  • Miloslav Trmač (Red Hat)
  • Varderes Barsegyan (DNAnexus)
  • add yourself

Agenda Items:

Notes:

  • Do we need Goals, Scenarios and Requirements? Seems the requirments can be merged into the scenarios - general agreement
  • For the scenarios, we have a core set of scenarios, with an additional for key managmeent. We’ll keep the key management seperate for now, enabling a streamlined working group. As they get solidified, we can merge them with the core scenarios.
  • Distribution Spec Signature proposals:
    • Seems we have some agreement OCI Index is a better model for keeping track of depdencies, as it already tracks index to manifest. Which a signature is a link to a manifest.
    • This does mean we need to continue the OCI Index supporting a config object for both persistance of the signature object, and uniquely identifying the index as a signature type. Add Index support for artifact type #25
  • Are signatures “special” enough to need a separate API?
    • For discovery API, we briefly discussed the two paging APIs. The one consistent with the distribution tag listing, and a more generic version used on standard REST APIs. Sam provided the google API design reference.
    • Do we have a signature discovery API, or a generic API for what manifests represent a given digest?
      • Provide a list of all indexes that refer to digest sha256:abc123
      • Provide a list of all indexes that refer to digest sha256:abc123 that has an artifact type of application/vnd.cncf.notary.config.v2+jwt
    • Agreed to defer this to online conversation
    • For signature upload in relation to role based access: rather than have a separate API for signature linking, that wouldn’t scale to other artifact types, should we use the standard push/upload APIs and outline role check should be done enabling a scalable and consistent model for other artifact types?
  • Steve to finish documenting WIP: distribution API proposals #2, incorporating feedback
  • Please provide some eyes on the JWT encoding staged PR

July 31, 2020

Recording

Attendees:

  • Niaz Khan (AWS)
  • Steve Lasker (Microsoft)
  • Marco Franssen (Philips - Research)
  • Marina Moore (NYU)

Agenda Items:

  • Multiple Root Keys
  • Key Revocation

Notes:

  • Key sharing service serves the purpose of multi-registry world.
    • it allows a company to define what they trust
  • Registry clients connect to key sharing service to fetch trusted roots
    • To prevent usability issues a client should be able to connect to a single key sharing service
  • Key sharing service can be used to redirect to other key sharing services or give an overview of the trusted keys
    • What are potential threads for the key sharing service?
    • How can we protect against these threads?
    • The key sharing service should also be able to run as an offline airgapped service. This allows offline/airgapped solutions to rely on this airgapped service.
  • Should the keysharing be embedded in the registry?
  • How does key revocation propagate to clients via key sharing service?
  • meeting minutes

July 27, 2020

Recording

Note: Meeting will be 7am Pacific time

Attendees:

  • Steve Lasker (Microsoft)
  • Shiwei Zhang (Microsoft)
  • Miloslav Trmač
  • add yourself

Agenda Items:

Notes:

  • Outline the multiple signature scenario better - identifying how the references could be used
  • Questions on scopying and support of TUF metadata
  • Ouline what’s in prototype phase 1, vs. future prototypes - like TUF metadata. Ralph volunteered to help - and it’s now written in history
  • meeting minutes

July 24, 2020

Recording

Attendees:

  • Niaz Khan (AWS)
  • Marco Franssen (Philips - Research)
  • Justin Cappos (NYU)
  • Marina Moore (NYU)

Agenda Items:

  • Finalize Pull Request PR

Notes:

  • Revisions for scenarios doc:
    • Define addtional personas for deployment roles and registry operators
    • Add diagrams to clarify steps in signing, uploading to registry, and deploying containers
    • Add diagrams for key rotation
    • Clarify how air-gapped regions can manage trust store
  • Root rotation now involves a third component. Does this introduce additional risk?
    • Justin to clarify risk for discussion at next week’s meeting.

July 20, 2020

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • Marina Moore (NYU)
  • Justin Cappos (NYU)
  • Miloslav Trmač (Red Hat)
  • Trishank Karthik Kuppusamy (Datadog)
  • Donald Stufft (Datadog)
  • Samuel Karp (AWS)
  • Jesse Butler (AWS)
  • Niaz Khan (AWS)
  • add yourself

Agenda Items:

  • Key management working group discussion PR (Niaz)

Notes:

  • Should we support CAs?
    • May be optional, but shouldn’t be required. If needed, an extensibility option.
    • Not clear there are benefits for CA keys, and Cappos hasn’t seen much demand.

July 17, 2020

Recording

Attendees:

  • Niaz Khan (AWS)
  • Marco Franssen (Philips Research)
  • Justin Cormack (Docker)
  • Justin Cappos (NYU)
  • Trishank Karthik Kuppusamy (Datadog)
  • add yourself

Agenda Items:

  • add your topics

Notes:

  • Some open questions
    • How to sync certificates to be known to different notary instances? (public vs private company internal)
      • Airgapped.
      • Pulling from different registries at runtime platforms
    • How to enable self managed portal for bigger organizations?
      • admins can manage creation of new targets
      • team can manage delegations themself for their targets
    • How would a CI job retrieve it’s delegation and cleanup afterwards to sign images?
      • Auto expire after 10 minutes (lifetime of CI job)
      • Auto register this CI delegation on the given target
        • Does an ACME like challenge work here?
  • Review draft of use cases for key management scenarios
    • Justin and Trishank to do this
    • Raised some potential issues on role/metadata files vs signatures directly on manifests/indices, and scalability of revocation lists vs explicit metadata on keys
    • Niaz interested in use cases such as different roots of trust in a registry: e.g., company vs individual developers
    • Niaz to add in motivation on why steps are being taken.

July 13, 2020

Attendees:

  • Justin Cormack (Docker)
  • Steve Lasker (Microsoft)
  • add yourself

Agenda Items:

  • Niaz wanted more time to incorporate feedback. Watch for an invite for this friday for key signing scenarios.
  • no agenda, agreed to defer to next week.
  • add your topics

Notes:

  • meeting minutes

July 10, 2020

Attendees:

  • Niaz Khan (AWS)
  • Steve Lasker (Microsoft)
  • Marco Franssen (Philips Research)
  • Ian Kaneshiro (Ctrl Cmd)
  • add yourself

Agenda Items:

Notes:

July 6, 2020

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • Trishank K Kuppusamy (Datadog)
  • Justin Cormack (Docker)
  • Samuel Karp (AWS)
  • Niaz Khan (AWS)
  • Omar Paul (AWS)
  • Tero Saarni (Ericsson)

Agenda Items:

  • Preliminary sharing of experience with Signy on Notary v1
  • Lessons from notary-dct-admin
    • Interested in Notary v2
    • Working with extending Notary v1, like Signy, in the meantime
    • Agnostic storage and key backends
    • One-click key revocation
    • Looking for funding (can CNCF help here?)
  • EU+Asia friendly meeting time?
    • Harbor, Philips, etc are interested
    • We should include them
  • add your topics

Notes:

  • Radu and Trishank to write an issue about lessons learned
  • meeting minutes

June 29, 2020

Recording

Attendees:

  • Niaz Khan (AWS)
  • Steve Lasker (Microsoft)
  • Samuel Karp (AWS)
  • Tero Saarni (Ericsson)
  • Serge Hallyn (Cisco)
  • add yourself

Agenda Items:

Notes:

  • meeting minutes

June 22, 2020

Recording

Attendees:

  • Niaz Khan (AWS)
  • Steve Lasker (Microsoft)
  • Marina Moore (NYU)
  • Justin Cappos (NYU)
  • Donald Stufft (Datadog)
  • Trishank Karthik Kuppusamy (Datadog)
  • Tero Saarni (Ericsson)
  • add yourself

Agenda Items:

Notes:

  • meeting minutes

June 15, 2020

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • Marina Moore (TUF)
  • Justin Cappos (TUF)
  • Trishank Karthik Kuppusamy (Datadog)
  • Niaz Khan (AWS)
  • Radu Matei (Microsoft)
  • Tero Saarni (Ericsson)
  • Evan Cordell (Red Hat)
  • Samuel Karp (AWS)
  • Derek McGowan
  • Aaron Lynch (AWS)
  • Donald Stufft (Datadog)
  • add yourself

Agenda Items:

Notes:

  • Registry/Repo RBAC -Storage - Write up a constraint/scenario such that signatures/metadata are stored alongside image data, without the need for a separate service endpoint. (Steve)
  • Need key management scenarios written up. Marina offered to make a PR with the initial key management scenarios.
  • meeting minutes

June 8, 2020

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • Niaz Khan (AWS)
  • Trishank Karthik Kuppusamy (Datadog)
  • Justin Cappos (NYU)
  • Serge Hallyn (Cisco)
  • Tero Saarni (Ericsson)
  • Miloslav Trmač (Red Hat)
  • Tue Tran
  • add yourself

Agenda Items:

Notes:

  • meeting minutes

June 1, 2020

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • Aaron Lynch (AWS)
  • Samuel Karp (AWS)
  • add yourself

Agenda Items:

Notes:

  • meeting minutes

May 25, 2020

Meeting cancelled per US Memorial Day Holiday We’ll reconvene next Monday, June 1st

May 18, 2020

Attendees:

  • Steve Lasker (Microsoft)
  • Tero Saarni (Ericsson)
  • Radu Matei (Microsoft)
  • Serge Hallyn (Cisco)
  • Stuart Hayton (IBM)
  • Samuel Karp (AWS)
  • Evan Cordell (Red Hat)
  • Niaz Khan (AWS)
  • Marina Moore (NYU)
  • add yourself

Agenda Items:

Notes:

  • meeting minutes

May 4, 2020

Attendees:

  • Steve Lasker (Microsoft)
  • Marina Moore (NYU)
  • Trishank Karthik Kuppusamy (Datadog)
  • Samuel Karp (AWS)
  • Serge Hallyn (Cisco, lurking)
  • add yourself

Agenda Items:

Notes:

  • Should a signature couple a tag and a digest to say that combination is “signed” and verifed at a given time?

  • We haven’t yet written down a “requirement” that digests and/or tags can’t change as the result of signing an artifact. Is that a requirement?

  • Attacker goals in the threat model

May 4, 2020 - nv2

Attendees:

  • Steve Lasker (Microsoft)
  • Samuel Karp (AWS)
  • Marina Moore (NYU)
  • Trishank Karthik Kuppusamy (Datadog)
  • add yourself

Agenda Items:

Notes:

  • Cappos, Moore, Kuppusamy - some feedback on the Deisgn Options
    • Option 3, does the entire SBOM have to be entireley downloaded?
    • Does the SBOM need to be signed as well
    • sam - sign an sbom of the sbom
    • What does the client request, an image, or a tag?
      • the client requests a digest or a tag
    • Discussion of option 4 having separate uploads of signed content
    • Discussion of whether a digest can or shouldn’t have to change
      • Can a naming convention be used?
      • Joey - when a signature is pushed, an entry is pushed as the orignal manifest, with a new api that links manifests and declaration.
    • Vincent - Reminder for the need to track separate ACLs
    • Cappos - can you trust a registry?
    • Joey - can pushes of linkages between docuemnts be identifiable for walking back compromises
    • Cormack - can we build a secuirty solution without reverse linkages?
  • Additional references:
  • meeting minutes

April 27, 2020 - nv2

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • add yourself

Agenda Items:

  • add your topics

Notes:

  • Justin Cormack - Doc for a minimalisitc implementation to get started. Tuf with a separate doc format for fitting in a registry to see where it goes.
  • meeting minutes

April 27, 2020

Attendees:

  • Steve Lasker (Microsoft)
  • Aaron Lynch
  • Niaz Khan (AWS)
  • add yourself

Agenda Items:

  • add your topics

Notes:

  • meeting minutes

April 22, 2020 - nv2 breakout

Attendees:

  • Steve Lasker (Microsoft)
  • Samuel Karp (AWS)
  • add yourself

Agenda Items:

  • Identify some goals of the experience.

  • Sketch out an experience for SMEs to engage within their areas.

    • Learn what’s hard that needs more investments
    • Learn what’s easy, we can just do now

  • Repos for iteration:

  • Housekeeping

    • what language will we use?
      • Golang
    • what are the apis/ux we’ll focus on?
    • what are the extension models we need to support for the nv2 client
    • What are the registry extensions do we need?
    • maintainers

  • MVP

    1. Sign an artifact
    2. Push the artifact and signature to a registry
    3. Pull an artifact from a registry, validating it’s signature

  • Needs

    1. Concrete representations for signatures
    2. API changes required on distribution, if any

  • Prototyping Order

    1. Sign & Push a signature to a registry
      • Manifest is in the registry
      • Persistence - how do we represent a signature in the registry?
    2. Pull an artifact from the registry, validating it

  • Misc discussion

    • How to manage ACLs on signatures and artifacts?
    • VBatts - should be able to sign layers
    • Justin - should we be able to sign artifacts not owned
      • Steve - customers want to sign content for different environments, which means they are signing someone elsese content
      • in-repo signatures as a first model
    • Focusing on detached signatures
      • extension proposal #111 (discussion https://hackmd.io/Ljkrt0LORmeVznREeGOWuQ?edit)
      • Push an artifact, then push another manifest that includes a signature for that artifact. It could support mulitple signatures.
      • Steve - How can we support immutable manifests so users don’t have to pull/push and the registry needs to cope with updates?
      • Sajay - the concept of a signed manifest that points to the content and the signature.
        • Tags can be updated, but the content digest doesn’t get updated.
      • Derek - how to reference signature collections, as opposed to tag listing.
      • VBatts - can unordered list be pushed, so the collection doesn’t need to be signed?
      • Need to account for deleting signatures when the artifacts are deleted.
      • Justin - additional signatures can be pushed to the registry, as a signature manifet.
      • Can we push individual index objects, each with a separate signature so we don’t have to update a single signature index?
        • There’s no existing reverse lookup for the indexes that represent a manifest
      • Sajay/Justin - could we morph Notary v1 metadata with a Notary v2 model to have tags updated with new signatures. Client can infer a naming scheme with different properites.
      • Steve - can we say Notary v2 doesn’t store different pointers for signed and unsigned content for the same tag?

  • ToDo:

    • Steve to add a comment to the distribution fork readme.md to identify it’s for collaboration on changes we might propose to the distribution spec and eventually merge back to docker/distribution.

  • add your topics

Notes:

  • meeting minutes

April 20, 2020 - Monday call

Recording

Attendees:

  • Steve Lasker (Microsoft)
  • Stuart Hayton (IBM)
  • Aaron Lynch (AWS)
  • Miloslav Trmač (Red Hat)
  • Niaz Khan (AWS)
  • Radu Matei (Microsoft)
  • Samuel Karp (AWS)
  • Tue Tran (AWS)
  • Derek McGowan (Docker)
  • add yourself

Agenda Items:

  • Scenarios Update
  • Prototype
  • add your topics

Notes:

  • Scenarios Update
  • Prototype
  • Aaron - what’s the value of the signature?
    • Discussion of signature and post validation verificaiton using TUF
  • Justin Cappos
    • Discussion of signatures being the foucs, vs. verification, which had been the trusted “annotation”. Focus on the result, that the document wasn’t tampered with.
  • Niaz
    • Layered approach, which could include additional meta-data
    • What’s a core, vs. extensibility requirement?
      • eg: Do some signatures can about names, while others may not
  • meeting minutes

April 20, 2020 - nv2 experiment

Attendees:

  • Steve Lasker (Microsoft)
  • Justin Cormack (Docker)
  • Omar Paul (AWS)
  • Stuart Hayton (IBM)
  • Aaron Lynch (AWS)
  • add yourself

Agenda Items:

  • add your topics

Notes:

  • Signing vs. Content Verifcation
  • Multiple phases
    1. What does a signed document in a registry look like
    2. Prototype this in the OSS registry
    3. Write a client that can push/pull signatures
    4. Write a client that can valiate signatures
    5. Build a more complex client, like TUF, that would layer atop the above signatures and validation
  • First we fork docker/distribution
    • Add root signature api
  • Add an nv2 client to push/pull/sign content
  • Then, we add a tuf client that uses the above interfaces
    • Tuf client takes tuf repository to a registry version, then converts it back
  • Key Managemnet
    • APIs for external key management solution
    • Solution for the 98% of others
  • Next nv2 call
    • Justin Cormack - Wednesday or Friday 9am or 10am
    • Derek - Wednesday 9 or 10
    • VBatts
    • Sam - Wednesday 10
    • Sajay
  • meeting minutes

April 13, 2020

Recording

Attendees:

  • Aaron Lynch
  • Steve Lasker (Microsoft)
  • Samuel Karp (AWS)
  • Niaz Khan (AWS)
  • Evan Cordell (Red Hat)
  • Serge Hallyn (Cisco)

Agenda Items:

  • Working group status
    • Sceanrios Feedback
      • Push/pull between signing and tuf evaluation PR# 15
      • Justin - if we over scope scenarios, we narrow the conversation
        • Focus on the goals, leaving as much as possible about the mechnisms out. ex: have to have puncture resitant tires on an ambulance removes the option to have helicopters
      • Niaz - can we assure we’re capturing the notes in the PRs.
    • Threat Model Update
      • Niaz - until we have more of a design in place, it’s hard to do a threat model analysis. At the high-level we have the threats we want to capture. Some conversations around key management.
      • “What does signing attest to”, for example.
      • Discussion about splitting up the threat model requirements, vs. an actual threat model of a design.
      • Key managment spearate from a threat model design.
  • UX flow
    • We’ll start to sketch out an experience for iterative work. There’s nothing concerete about the sketch, rather an experience to learn from, enabling folks to engage with their expertise.
  • Housekeeping
    • Niaz suggested we see if we can get a different time slot, which he’ll help coordinate for brekout meetings. We’ll chat on the Notary v2 slack channel for everyones visibility.

Notes:

April 6, 2020

Attendees:

  • Steve Lasker (Microsoft)
  • Aaron Lynch (AWS)
  • Samuel Karp (AWS)
  • Niaz Khan (AWS)
  • Tue Tran (AWS)
  • Miloslav Trmač (Red Hat)
  • Vibhav Bobade (Red Hat)
  • add yourself

Agenda Items:

  • Working group status
    • Scenarios
    • Key Management / Threat Model
    • Signature Persistance
    • UX

Notes:

  • Discussion for how to represetnt a TUF concept of a collection
  • What is the extent of design/constraints are we hitting? Is the existing OCI Index/Manifest design enough?
  • We’ve been working with the assumption the existing OCI spec meets most of the capabilities, with some tweaks. But, that may not be the case.
  • Threat model team to focus on more documentation of the proposal and discussion.
  • Hoping to get more progress, as is reasonable, within the next week
  • Ask to wrap up the current PR for scenarios so we have a common doc to reference. We can and will likely iterate on additions, but lets get a Scenarios PR merged.
  • meeting minutes

March 30, 2020

Attendees:

  • Steve Lasker (Microsoft)
  • Joey Schorr (Red Hat)
  • Josh Dolitsky (Blood Orange)
  • Peter Engelbert (Blood Orange)
  • Miloslav Trmač (Red Hat)
  • Rita Zhang (Microsoft)
  • Richard Nguyen (AWS)
  • Samuel Karp (AWS)
  • Matthew Russo (AWS)
  • Tue Tran (AWS)
  • Shubhra Deshpande (AWS)
  • Vincent Batts
  • Adrian Mouat (Container Solutions)
  • Aaron Lynch (AWS)
  • Radu Matei (Microsoft)
  • Ram Chinchani (Cisco)

Agenda Items & Notes

  • 9:00am – 9:30 Artifacts update
    • Status of the spec
    • IANA mediaType registration updates
    • Josh - how many types would need anything more than the generic ones?
      • Steve - likely not many. But, if they do, they can
    • Joey - We need to make sure the proposal states that handling of downloaded layers/blobs is artifact specific. As well, if we are mixing different kinds of artifacts, it should be done via an index, not using different layers (IMO)
    • Repo: https://github.com/opencontainers/artifacts
  • 9:30-10:00: Getting the Distribution Spec to a 1.0
    • A set of proposals, such as the extension proposal #111 that could get incorporated into the 1.0 spec.
    • Hanging extensions off a repo enables ACL (Access Control Lists) to be enforced on the extnesion, in relation to the artifact.
    • Minor details - like the Readme.md need updates
    • Clarifications that are flushing out from the conformance testing.
    • Josh - Spec Language Updates
    • VBatts - Would like to get an RC2 out
  • 10:00-10:30: Supporting the Secure Supply Chain efforts
    • How OCI, Artifacts & Notary can support the Software Supply Chain efforts with SBoM, GPL Source and other content, stored in a registry, signed with Notary v2.
  • 10:30-11:00 Notary v2
    • Derek - Signatures in OCI Distribtuions
      • Fit into the existing OCI spec
      • Planning on having the extension design integrated to allow for signatures
    • Discussion of signing collections, querying a collection of signatures
    • Discussion of offline verification of signatures using snapshots
      • good conversation for the breakout groups

Threat model meeting 27 March 2020

Attendees:

  • Justin Cormack
  • Justin Cappos
  • Niaz Khan
  • Marina Moore
  • Samuel Karp
  • tuetran
  • lahiru

Agenda Items:

  • where are we with threat model?

Notes:

  • TODO: remove from scenarios doc any design pieces
  • TODO: improve wording on thread model: forward looking crypto agility
  • roles: operator, producer consumer
  • motivation vs what is wrong
  • do we have to trust the registry?
  • minimal possible trust.
  • how does user get trust of publisher. If user knows the key registry doesnt neeed trust.
  • naming vs location. third party vs first party.
  • registry A deletes software where you have in B. How can you continue to trust.
  • model of who the actors are and what they are trying to achieve.
  • TODO: list of roles (the length of the threat model) and basic use cases.
  • Which roles are providing signatures?
  • Information about them.
  • Signing collections is impossible.
  • discussion about properties of registries - privacy needs.
  • Niaz: key administrator role. Add as a TAP for TUF?

March 23, 2020

Attendees:

  • Steve Lasker (Microsoft)
  • Miloslav Trmač (Red Hat)
  • Dan Lorenc
  • Samuel Karp (AWS)
  • Carmen Puccio (AWS)
  • Trishank Karthik Kuppusamy (Datadog)
  • Marina Moore
  • add yourself

Agenda Items:

  • A quick check-in for folks
  • Breakout Updates
  • add your topics

Notes:

  • NOTE: we appreciate some may be coping with, assisting others at this time. While others are looking for something creative to do with their time. We’ll continue to the weekly meetings, with breakouts where possible. We will NOT make any fina/final decions as we recognize that some may not be able to engage right now. We expect things to get worse before they get better, so we’ll continue to adjust. If you’re leading a breakout, and need to step back, please just ask for some help to take the lead. We’re a diverse group of people that are here becuase we believe in community, which is made of people.- meeting minutes
  • Some were confused about the start time. Steve to update the heading of these notes. Please see the cncf calendar as Amye has been awesome to keep these updated.
  • Breakout Updates
  • Justin-Hoping to get a threat model this week
  • Steve - Discussion on status of scenarios. If we can get :eyes: on #15 we can wrap-up a baseline
    • Discussion of the mirroring PR, looking great. A minor clarification on the verification step so we can also merge.
  • Key Management - possibly create another slack channel
    • Trishank to send a draft of a key management HackMD
  • Please put breakout notes here, with a mid-week update if needed - AJust add another ## heading
  • Some teams may split out to another slack channel, with a link provided here for others to engage.
  • A bit of a concern about too many slack channels. If we do, lets try to keep them focused and not force folks to montior too many slacks.
    • We’ll update here weekly for those that want to hear, but don’t have time to egnage
  • Initial Design Ideas
    • should we move these to an issue, or another location?
    • Samuel - the requriements repo is a working location
      • we’ll continue it here, as issues doesn’t have good editing/comments
      • Justin spoke to the hackmd folks
      • VBatts - would be great if we could somehow integrate hackmd with github
      • At this point we’ll keep things where they are. As we get further along in design, or we may merge this in as it evolves.

March 16, 2020

Attendees:

  • Steve Lasker (Microsoft)
  • Justin Cormack (Docker)
  • Miloslav Trmač (Red Hat)
  • Niaz Khan (AWS)
  • Tue Tran (AWS)
  • Samuel Karp (AWS)
  • Marina Moore (NYU)
  • Trishank Karthik Kuppusamy (Datadog)
  • Evan Cordell (Red Hat)
  • Dave Trudgian (Sylabs)
  • Justin Cappos (NYU)
  • Aaron Lynch (AWS)
  • Ian Kaneshiro (Sylabs)
  • Dan Lorenc (Google)
  • Dave Billing (Cisco)
  • Vibhav Bobade (Red Hat)

Agenda Items:

Notes:

  • meeting minutes

March 9, 2020

Attendees:

  • Aaron Lynch (AWS)
  • Niaz Khan (AWS)
  • Justin Cormack (Docker)
  • Jon Johnson (Google)
  • Dave Billing (Cisco)
  • Marina Moore (NYU)
  • Joshua Lock (VMware)
  • Evan Cordell (Red Hat)
  • Justin Cappos (NYU)
  • Radu Matei (Microsoft)
  • Serge Hallyn (Cisco)
  • Miloslav Trmač (Red Hat)
  • Daniel Jiang (VMware)
  • Ram Chinchani (Cisco)

Agenda Items:

  • Breakout groups for Scenarios+UX and Key management+Threat model

Notes:

  • KubeCon meeting (Steve)
    • Witht the postponement of KubeCon, we moved to an online meeting. I will reschedule to start at 8am Pacific time, to account for Europe folks.
    • I’ll have other meetings for Artifacts and possibly the Pub/Sub work Joey has been working on that will happen from 10am to possibly noon. With the KubeCon plan confirmed, I’ll get these meetings finalized as well.
  • Breakout groups
    • Use Cases & UX (api/interaction model)
      • (Steve, Omar, Marina, Aaron, Ram, Tue)
    • Threat Model & Key Management
      • (JustinCr, Justin Cappos, Niaz, Evan, Dave B, Miloslav?, Serge. Tue)
    • Signature Storage within the OCI spec
      • (JustinCr, Vincent, Derek, Sam, Jon, Daniel J, Serge, Tue)
    • Reference Implementation
      • Docker Distribution?
      • How does it interact with k8s, OPA and SBoMs
      • Zot very interested in implementing asap
  • Keep the exising Monday meeting for status sync. Reduce to 30 minutes. Will move to the later hour to free up the first 30 minutes for groups to meet prior.
  • Naming: Will leave open for now, pending the threat model discussions. (serge asks - where will that discussion happen?)
  • Timeline
    • Going to hold to our original April timeline for an initial design.
  • How do we think about Notary v2 and registries? Does success of Notary v2 end with a registry conformance/implemenation? Or, is it assumed Notary v2 stands alone outside registries?
    • The ability to pull an artifact from a registry, validate it outside of a registry is part of our success.
    • End-to-end verification implies signing/verification outside registries; OTOH smooth usage ~requires registries natively supporting transport of signed data
  • meeting minutes

March 2, 2020

Attendees:

  • Steve Lasker
  • Stuart Hayton (IBM)
  • Brandon Lum (IBM)
  • Radu Matei (Microsoft)
  • Niaz Khan (AWS)
  • Joshua Lock (VMware)
  • Marina Moore (NYU)
  • Samuel Karp (AWS)
  • Dave Billing (Cisco)

Agenda Items:

  • Last Weeks On Site Meeting Recap - Steve
  • SBoM Integration - Steve
  • Divide & Conquer - Steve/Justin
  • add your topics

Notes:

  • With the focused conversation last week, we didn’t have much new content. We did a quick cover of the naming and CNAB notes from last week. See below.
  • SBoM conversations to verify alignmnet that there is a doc that would be put in a registry, which is then signed.
  • Divide & Conquer to start focused design meetings. Specific groups TBD.
  • Look into setting up irq on the slack channel - Serge
  • Notary Project Requirements for the current state of content, with Justin’s Google Doc here

February 24, 2020

  • Steve Lasker (Microsoft)
  • Samuel Karp (AWS)
  • Tue Tran (AWS)
  • Justin Cormack (Docker)
  • Aaron Lynch (AWS)
  • Niaz Khan (AWS)
  • Omar Paul (AWS)
  • Sajay Antony (Microsoft)
  • Radu Matei (Microsoft)
  • Trishank Karthik Kuppusamy (Datadog)
  • Jon Johnson (Google)
  • Marina Moore (NYU/TUF)
  • add yourself

Agenda Items:

Notes

  • Justin/Steve/Sam/Omar: Mirroring is not as straightforward in container registries as in package repos. An image is accessed with a location as core part of the image-therefore signing the image also signs where its stored/retrieved, therefore you today sign the image and where it comes from.
  • “Sam Q: What does a signature tell you?" Aaron - Gives you a hash over a bag of bits, gives you the publishers identity and lets you validate the publisher at a later time. Sam - specifically, lets you validate a key and only tells you the publisher is trusted and the object is what was signed, not anything inherent about the content outside of what a publisher says it is. Steve - tells me that this content is trusted because I trust the publisher that signed it. The name of that signed object should also be trusted. Justin - I have to be able to know that I signed something with a name, and if I access that later with a name, I should be able to trust that without checking the content hash again.
  • Should we let people change a name:tag and keep the signature valid - If we don’t allow this, existing container workflows will break.
  • Sajay - We need to be able to describe the discoverability and the signature validation seperately.
    • Extending Index to support storing signatures is one option.
  • Trishank - We can support different models of trust at the same time
    • Option 1: trust Docker to give me the keys for an image
    • Option 2: trust Docker only to give me the signatures and the images, and I will pin the keys
    • Options need not be mutually exclusive: there is no reason why we cannot support both weak and strong signing models; it should be flexible
    • Appears that we need mechanisms for transparent key distribution and revocation, as well as pinning your own keys, as well as ways to somehow order keys using some well-defined criteria for trust
  • What are we signing? - Justin signing the descriptor is the correct thing, and if the exact same content is pushed, then pulled and pushed into a second location, and the content hash changes - thats a tooling issue. Radu - insert comment here
  • Min. bar for Notary v2 of OCI needs to be Distribution Spec v1 - As a carrot/forcing function.
  • How much are we willing to change?
    • We’re changing the docker content trust workflow. Are we willing to change the workflows, such as other package managers like npm, rpm, nuget?
  • Diverging from TUF
    • Justin: So far, not seeing a use-case for using the snapshot role to sign a collection of images, since it’s ok to change the version/tag and not have the signature be invalid.
    • Marina: The snapshot role does prevent against rollback attacks of images.
    • Trishank: Also, how does this affect security guarantees the TUF project designed for Docker Hub hosting images on semi-trusted mirrors, where the mirrors may be able to switch images?

Notary v1

The entire path is signed docker pull org.exmple.com/team-a/mydb:1.0

Keeping the name, different path

docker pull org.exmple.com/team-a/mydb:1.0 docker pull org.exmple.com/staging/mydb:1.0 docker pull org.exmple.com/prod/mydb:1.0

Keeping the name, different registries

docker pull org-dev.exmple.com/team-a/mydb:1.0 docker pull org-staging.exmple.com/team-a/mydb:1.0 docker pull org-prod.exmple.com/team-a/mydb:1.0

Changing the tag, representing the env

docker pull org.exmple.com/team-a/mydb:1.0 docker pull org.exmple.com/team-a/mydb:1.0-staging docker pull org.exmple.com/team-a/mydb:1.0-prod

Tagging References

Docker Tagging: Best practices for tagging and versioning docker images

  • Comments
    • Trishank: I agree with the docker best practices for tagging and versioning docker images
    • Trishank: We cannot depend on the registry not changing the contents of the tags (unless you couple with something like immutable history with Transparent Logs, but that is a whole another can of worms by itself)
    • Jon: Definitely agree it seems like signing and tag verification can be solved separately… the go modules transparent log work seems to map pretty well to registry tags

Proposal to implement the above in Notary v2

Notary v2 will support this use case

  • com.docker.justin:foo <- canonical image name
  • justin:foo <- Docker Hub image name
  • registry.example.net/mirror/image:bar <- diff. location where this content is mirrored Example commands
  • docker pull justin:foo –from registry.example.net/mirror/image:bar
  • docker pull Sajay TBD
  • docker build –tag justin:foo –canonical-name com.docker.justin:foo –sign $KEY_ID

CNAB doc notes

  • Lets see if Notary v2 does not explicitly block what CNAB already does with TUF and Notary v1. Support TUF 1.0 delegation.
  • Radu and Trishank will file an issue on the Notary v2 requirements GitHub repository about exactly what we need. A lot of this touches hairy key management issues we will ultimately need to address anyway.

ToDos

  • Steve to merge in Justin Cappos scenarios
  • Sam to capture the naming conversation and next steps

By Kubecon EU, achieve what?

  • Sam: What are our goals and what are not. Do we know what we’re signing, and what does this mean for OCI?
  • Justin: How modular is this, what are the basic use cases, and what that usability is
  • Steve: Define scope of Notary v2, so we can share with others as well (SBoM, etc.) can understand what we will and won’t do. What is needed from the OCI spec?
  • Sajay: A containerd plugin PoC that shows what Notary v2 can be?
  • Niaz: Understand key management requirements, need to make sure its not super easy to do this - ensure we keep some friction here. [Action] Justin (Docker), Niaz (AWS) will start to meet up on this, with Steve (Msft) bringing someone onboard in the coming weeks.

February 18, 2020

Attendees:

  • Steve Lasker (Microsoft)
  • Samuel Karp (AWS)
  • Tue Tran (AWS)
  • Lahiru (AWS)
  • Justin Cormack (Docker)
  • Aaron Lynch (AWS)
  • Niaz Khan (AWS)
  • add yourself

Agenda Items:

Notes

  • Scenarios
    • JustinCappos Another scneario: what happens when things go wrong, and the keys are compromised? Or, what to do when a specific key was compromised.
    • Steve - are these the revoking scenarios?
    • (Niaz) - we don’t revoke keys as much as we revoke trust
    • JustinCappos - If we have a man in the middle attack -
      • It matters what was signed with the key, and when. But, how do you go from the bad state, back to a good state.
      • Should also incorporate offline/copied artifacts that were copied to another registry.
    • How do we want to scope in/out various topics to the scenarios doc.
      • For instance, key managmenet.
      • Scenarios should avoid the specific technology, such as HSM. Rather we refer to keys, regardless of how the key is “managed”.
    • New Scenarios
      • (Justin) #1 doesn’t mention how the developer would validate the base image is valid
      • (Niaz) How to accont for the scenario where the image is validated, then deployed. Between validation and deploy, how do verify the artifact wasn’t compromised. Basically, once the image has been unpacked, how do we validate it.
      • Should the hosting environemt be in-scope?
        • (JustinCormack) Or, is this more about specific artifact type validations?
      • (Raja) Should be careful to not design something that belongs in the artifact specific runtime.
    • For the artifact naming/moving, the existing scenarios aren’t crisp enough. Might cover the local mirroring for IoT/OnPrem or workflow from dev-prod.
      • What are the minimum set of scenarios, vs. stretch goals?
      • What are we signing? What does signing an artifact mean?
  • Threat Models
    • Agreement to create a separate threat-model.md document. (JustinCormack) - merged
    • Cappos - how to identify how the thing was compromised? It’s not just a scanning question.
    • We should valiate the integrity, not enforce a policy
    • (JustinCormack) - how do we account for names being verifiable? If I can’t verify by name, I can’t trust it, and will revert to @sha256 digest references
  • Merging
    • Agreed to merge the existing docuemnts (scenarios, def & terms, and threatmodel), and iterate upon them.
  • validation logic
    • What are we validating?
      • Key?
      • Name?
      • Version?
      • Entity?
    • What does a validation look like?
      • Produced with a key that I trust
      • Producted by any key (it was signed and traceable)
      • The signature has an identity (Microsoft vs. micosoft)
      • When was it signed
      • Does the signature expire
  • Open Topics
    • Naming & Signing
    • Validate before run
    • TOFU vs. Explicit
  • Definitions & Terms
    • _
  • Key Management
    • Where keys are stored aren’t completly in scope.
    • The usability for how keys are used are in scope for the usability goals of notary v2.
  • Design Discussions
    • Where to store the signature info?
  • Parking Lot
    • Key Management
    • Heirarchicy of keys
    • grpc key store client feature - will defer to a later conversation.
  • meeting minutes docker pull org.exmple.com/team-a/mydb:1.0 docker pull org.exmple.com/prod/mydb:1.0 docker pull org.exmple.com/prod/gibbly:v1dsdf0 –name mydb:1.0

February 3, 2020

Attendees:

  • Steve Lasker
  • Justin Cormack
  • Stuart Hayton (IBM/ICCR)
  • Jim Flanagan (AWS)
  • Jack Baines (IBM/ICCR)
  • Tue Tran (AWS)
  • Samuel Karp (AWS)
  • Niaz Khan (AWS)
  • Brandon Lum (IBM/Research)
  • Omar Paul (AWS)
  • Joey Schorr (Red Hat)
  • Evan Cordell (Red Hat)
  • Miloslav Trmač (Red Hat)
  • Ian Kaneshiro (Sylabs)
  • add yourself

Agenda Items:

Notes:

  • Overview of how to think of Notary signatures, versioning, etc: Dividing & Conquering with a Separation of Concerns
  • Mitr: Concerned about interoperability.
  • Justin: Package managers tend to sign a smaller set of metadata. If they uniquely sign the mysql:3.16 image, is that the minimal use case?
  • Discussion of what’s signed. The manifest, or the artifact:tag name.
  • Signature Lifetime: Should signatures have a lifetime?
  • meeting minutes

January 27, 2020

Attendees:

  • Steve Lasker (Microsoft)
  • Dave Trudgian (Sylabs)
  • Stuart Hayton (IBM/ICCR)
  • Ian Kaneshiro (Sylabs)
  • Omar Paul (AWS)
  • Lahiru Dissanayake (AWS)
  • Samuel Karp (AWS)
  • Niaz Khan (AWS)
  • Miloslav Trmač (Red Hat)
  • add youself

Agenda Items:

  • Remind ourselves to post agenda items the Friday before :)
  • KubeCon Schedule update - Amye is working with the KubeCon schedule folks
  • Repo update & discussion
  • Requirement of signing locally
  • Break out

Notes:

  • https://www.docker.com/blog/community-collaboration-on-notary-v2/
  • Kubecon Amsterdam planning is being looked at. Currently looks like mid-week (Mar 30-Apr 2), Steve is working with Amy to find a location and times.
  • Breakout updates:
    • Threat Model (Justin)
    • Key Managment (Justin)
      • AWS can help with the key management/crypto org participating
    • Integration with OCI & the Spec (Vincent)
      • Some early conversation with between Vincent & Jon. Would like to get Distribtuion 1.0 get out first, and we’ll be additive.
    • Scenarios (Steve)
    • Use Cases
    • UX (Omar)
      • Holding pattern for a couple of weeks as the scenarios and use cases flesh out
  • Steve - local signing, keys, registries
    • Sam - local signing makes sense
  • Glossary of terms is needed. Define terms so we can use them in discussion and everyone knows what they mean. Key, Signature, Artifact, Key Store, Artifact Store, Annotation, Manifest, Metadata, Artifact Version, Tag, …
  • Air-gapped/disconnected environments is a scenario that should be spec’d.
  • Artifact names and signature references:
  • When you sign a manifest, are we signing all the annotations? If so, then as annotations are added, consider an exampe scenario that vendor annotates, then subsequently some process adds(not change of image) something, that should not invalidate the vendor signature)
  • Mixing signed and unsigned annotations is out of scope.
  • Spec should refer to orhestrators generically.
  • fx:1.0 scenario was too abstract in some areas to articulate which element of the stack would enforce the scenario.

January 13, 2020

video available: https://youtu.be/_cNtDvaU-J8

Attendees:

  • Steve Lasker (Azure)
  • Justin Cormack (Docker)
  • Omar Paul (AWS)
  • Tue Tran (AWS)
  • Lahiru (AWS)
  • Dave Trudgian (Sylabs)
  • Samuel Karp (AWS)
  • Stuart Hayton (IBM/ICR)
  • Vincent Batts
  • Ian Kaneshiro (Sylabs)
  • Chad Metcalf
  • Jon Johnson (Google)
  • Phil Estes (IBM)
  • Raja jadeja (AWS)
  • Mike Brown (IBM)
  • Miloslav Trmac (RH)
  • Joseph Schorr (RH/Quay)
  • Evan Cordell (RH/Quay)

Agenda Items:

Notes:

  • (Justin) - Org things
  • (Justin) How do we account for the UX of how someone signs and/or validates signatures?
  • Steve/Justin - how do we account for general signatures? Should a customer have to state which signatures they support before? Or, is there a * like scenario where they require a signature, but not a specific signature? Or, is this up to specific hosts to implement? This has remnants of trust on first use
  • Need to account for mirroring scenario (steve)
  • Stuart/Justin: How do we account for heirarchy (root of trust) scenarios?
  • Need to account for revoking signature scenarios, including mirrored scenarios (steve)
  • Steve - have we thought about root signatures being in one-place, while the signed artifacts are in a different registry?
    • Justin - this was part of Notary v1, with the China mirror.
    • Miloslav - this is less of signature issue, but more of a content transport redirection scenario
    • Justin - we did implement this for things like edge/semi disconnected scenarios.
  • Miloslav - does scenario #1 imply the artifact can be signed before it’s compressed?
  • Sam - while the current docker implementation doesn’t store the compressed format, containerd does support both.
  • Justin - we do really want Docker to work this way (containerd), we just haven’t had a chance yet. Mainly a complicated migration scenario. Derek has a PR opened. It’s why we have this weird buildx plug-in.
  • David - we have signing and validation embedded into the single file. We currently work through the registry through ORAS.
  • Steve - we’ll account for whatever Notary v2 goes with into ORAS.
  • Stuart - mirroring: Justin was talking about the home location problem. Questions on the history of the name.
    • Justin - do you need to know the history of the name? If it’s my image docker.io/justincormack/foo, I may use docker.io/justincormack for my signing key/authority. However, other vendors like Microsoft may have it’s own key.
    • Joey - I agree, the name seems to be unimportant. If docker wants to sign every image, they can with docker.io/centralsignature, or there’s a specific signature. It’s up the client for which signatures they want to trust
    • Justin - we definitley can’t have anything change when moved between regsitries
    • Steve - we’re talkinga about seperating the signature name from the registry it’s stored within.
    • Mirek - the difference between signed “what the content is” and location is important. If the user asks for a specific version, they should get the specific version they asked for.
    • Joey - need to think about keys being tied to versions. I don’t want to end up with the tag name being put into the manifest. If one manifest list can refer to a remote manifest, … then it’s up to each user to make a determination on how they sign things. Expect most users will want to trust a general key, not a specific version. But, customers can opt-into the narrowness of what they need. Perhaps a key for major version, with an annotation for a minor version. Want to get away from the tag name being canonicalized into the annotations.
    • Steve - the scnearios capture naming can be different as the artifact moves.
    • Justin - most people do want to know by tag, and they’re running mysql:3.8, they really get something that was tagged mysql:3.8, and not something mysql:3.4
    • Steve - how much should we lean into SBOM, vs tied signatures to specific artfiacts. Should we dictate a flow, or enable a flow?
    • Justin - we definelty want to be flexible, but we defintiley want some standard policy/framework to apply the kind of policies they want. It’s important to know it’s mysql, but also what version is also important.

Notes from slack: From Red Hat NYC to Everyone: 11:01 AM We need to leave now, unfortunately, but wanted to comment that name resolution is already the job of the registry; it seems weird to have a second system to replace the very purpose of the registry that’s part of the reason we have a concern with how Notary V1 worked From Miloslav Trmač to Everyone: 11:01 AM The registry (or the registries involved, or the backing storage) is by definition untrusted or we, for the most part, don’t need signatures

Last modified November 8, 2021 : adding Notary v2 community notes archive (#59) (5cb1d02)