doc: remove Notary v2 reference

requirements/key-revocation.md

@@ -1,6 +1,6 @@
 # Key Revocation
 
-One of the goals of Notary v2 is to build in solutions for key revocation that are easy to use and ensure that users will always use non-compromised keys.
+One of the goals of Notary Project is to build in solutions for key revocation that are easy to use.
 This document discusses some potential mechanisms for key revocation.
 
 In existing systems, there are three main approaches to key revocation: automatic revocation through key expiration, key revocation lists, and providing a list of trusted keys.

requirements/requirements.md

@@ -1,9 +1,10 @@
 # Requirements
 
-A collection of requirements and scenarios, framing the scope of the Notary v2 project.
+A collection of requirements and scenarios, framing the scope of Notary Project.
 
 ## TOC
 
+<!-- no toc -->
 - [Goals](#goals)
 - [Non Goals](#non-goals)
 - [Scenarios](./scenarios.md)
@@ -14,27 +15,27 @@ A collection of requirements and scenarios, framing the scope of the Notary v2 p
 
 ## Goals
 
-Notary v2 aims to address the learnings and gaps of v1, while prioritizing a set of goals and [scenarios](./scenarios.md).
+Notary Project aims to address the learnings and limitations of [TUF-based implementation](https://github.com/notaryproject/notary), while establishing and prioritizing a set of goals and [scenarios](./scenarios.md) for new implementation (this repository).
 
 1. Offline signature creation
 1. Signatures attesting to authenticity and/or certification
 1. Maintain the original artifact digest and collection of associated tags, supporting existing dev through deployment workflows
 1. Multiple signatures per artifact, enabling the originating vendor signature, public registry certification and user/environment signatures
-1. Native persistance within an [OCI Artifact][oci-artifacts] enabled, [distribution-spec][distribution-spec] based registry
-1. Artifact and signature copying within and across [OCI Artifact][oci-artifacts] enabled, [distribution-spec][distribution-spec] based registries
+1. Native persistance within an [OCI image specification v1.1][oci-image-spec] enabled, [OCI distribution specification v1.1][oci-distribution] compliant registry
+1. Artifact and signature copying within and across an [OCI image specification v1.1][oci-image-spec] enabled, [OCI distribution specification v1.1][oci-distribution] compliant registries
 1. Support multi-tenant registries enabling cloud providers and enterprises to support managed services at scale
 1. Support private registries, where public content may be copied to, and new content originated within
 1. Air-gapped environments, where the originating registry of content is not accessible
 1. Key hierarchies and delegation
 1. Key revocation, including private and air-gapped registries
 1. Key acquisition must support users from hobbyists, open source projects to large software vendors
-1. Usable workflows, enabled for the masses to easily create and consume Notary v2 signatures
+1. Usable workflows, enabled for adopters to easily create and consume Notary Project signatures
 
 ## Non Goals
 
 1. Trust on first use
 1. Implicit permissions on rotated keys
-1. Compatibility with Notary v1
+1. Compatibility with [TUF-based implementation](https://github.com/notaryproject/notary)
 
 ## Key Stake Holders & Contributors
 
@@ -58,22 +59,20 @@ As we identify the requirements and constraints, a number of key contributors wi
   - [Mirantis Container Runtime (formerly Docker Engine – Enterprise)][mirantis-runtime]
   - [Mirantis Kubernetes Engine (mke, formerly Docker Enterprise/UCP)][mke]
 - Artifact Types
-  - [OCI & Docker Container Images][image-spec]
+  - [OCI & Docker Container Images][oci-image-spec]
   - [Helm Charts][helm-registry]
   - [Singularity][singularity]
   - Operator Bundles
 
 ## Contributing & Conversations
 
-Regular conversations for Notary v2 occur on the [Cloud Native Computing Slack](https://app.slack.com/client/T08PSQ7BQ/CQUH8U287?) channel.
+Regular conversations for Notary Project occur on the [Cloud Native Computing Slack](https://app.slack.com/client/T08PSQ7BQ/CQUH8U287?) channel.
 
 Weekly meetings occur each Monday.
 Please see the [CNCF Calendar](https://www.cncf.io/community/calendar/) for details.
 
 Meeting notes are captured on [hackmd.io](https://hackmd.io/_vrqBGAOSUC_VWvFzWruZw).
 
-[distribution-spec]:    https://github.com/opencontainers/distribution-spec
-[oci-artifacts]:        https://github.com/opencontainers/artifacts
 [acr]:                  https://aka.ms/acr/artifacts
 [artifacts-repo]:       https://github.com/opencontainers/artifacts
 [docker-hub]:           https://hub.docker.com/
@@ -86,12 +85,10 @@ Meeting notes are captured on [hackmd.io](https://hackmd.io/_vrqBGAOSUC_VWvFzWru
 [harbor]:               https://goharbor.io/
 [icr]:                  https://icr.io/
 [helm-registry]:        https://v3.helm.sh/docs/topics/registries/
-[image-spec]:           https://github.com/opencontainers/image-spec
 [jfrog]:                https://jfrog.com/integration/docker-registry/
 [oci-distribution]:     https://github.com/opencontainers/distribution-spec
-[oci-image]:            https://github.com/opencontainers/image-spec
+[oci-image-spec]:       https://github.com/opencontainers/image-spec
 [oci-index]:            https://github.com/opencontainers/image-spec/blob/master/image-index.md
-[oci-manifest]:         https://github.com/opencontainers/image-spec/blob/master/manifest.md
 [oci-tob]:              https://github.com/opencontainers/tob
 [singularity]:          https://github.com/sylabs/singularity
 [quay]:                 https://quay.io/

requirements/scenarios.md

@@ -1,23 +1,23 @@
-# Notary v2 Signing Scenarios
+# Notary Project Signing Scenarios
 
 As containers and cloud native artifacts become the common unit of deployment, users want to know the artifacts in their environments are authentic and unmodified.
 
-These Notary v2 scenarios define end-to-end scenarios for signing artifacts in a generalized way, storing and moving them between OCI compliant registries, validating them with various artifact hosts and tooling.
-Notary v2 focuses on the signing of content, enabling e2e workflows, without specifying what those workflows must be.
+Notary Project signing scenarios define end-to-end scenarios for signing artifacts in a generalized way, storing and moving them between OCI compliant registries, validating them with various artifact hosts and tooling.
+Notary Project focuses on the signing of content, enabling end-to-end (e2e) workflows, without specifying what those workflows must be.
 
-By developing a generalized solution, artifact authors may develop their unique artifact types, allowing them to leverage Notary for signing and OCI Compliant registries for distribution.
+By developing a generalized solution, artifact authors may develop their unique artifact types, allowing them to leverage [Notary Project signature specification](../specs/signature-specification.md) for signing and OCI Compliant registries for distribution.
 
 ## Scenarios
 
-Notary v2 aims to solve the core issue of trusting content within, and across registries.
-There are many elements of an end to end scenario that are not implemented by Notary v2, rather enabled because the content is verifiable.
+Notary Project aims to solve the core issue of trusting content within, and across registries.
+There are many elements of an e2e scenario that are not in the scope of Notary Project, rather enabled because the content is verifiable.
 
 ### Scenario #0: Build, Publish, Consume, Enforce Policy, Deploy
 
-To put Notary v2 in context, the following end-to-end scenario is outlined.
-The blue elements are the scope of Notary v2, with the other elements providing generic references to other projects or products that demonstrate how Notary v2 may be utilized.
+To put Notary Project in context, the following end-to-end scenario is outlined.
+The blue elements are the scope of Notary Project, with the other elements providing generic references to other projects or products that demonstrate how Notary Project may be utilized.
 
-![Notary e2e Scenarios](/media/notary-e2e-scenarios.svg)
+![Notary Project e2e Scenarios](/media/notary-project-e2e-scenarios.svg)
 
 In a world of consuming public software, we must account for content that's acquired from a public source, copied into a trusted environment, then deployed.
 In this scenario, the consumer is not re-building or adding additional content.
@@ -26,7 +26,7 @@ However, they do wish to add attestations to the validity of the content.
 1. The Wabbit Networks company builds their `net-monitor` software.
       - As a result of the build, they produce an [OCI Image][oci-image], a Software Bill of Materials (`SBoM`) and to comply with gpl licensing, produce another artifact which contains the source (`src`) to all the gpl licensed projects.
       - The `SBoM` and `src` artifacts are created as reference types to the image, creating a graph of artifacts.
-      - Each of the artifacts are signed with the Notary v2 wabbit-networks key.
+      - Each of the artifacts are signed with the wabbit-networks key.
 1. The Wabbit Networks signed contents are pushed to a public OCI compliant registry.
       - Docker can provide an additional Docker hub signature providing an extra level of certification confidence.
 1. ACME Rockets consumes the `net-monitor` software, importing the referenced artifacts into their private registry.
@@ -45,7 +45,7 @@ However, they do wish to add attestations to the validity of the content.
 
 - Signatures can be placed on any type of [artifact](artifacts-repo) stored in an OCI compliant registry using an [OCI Manifest][oci-manifest]
 - Signatures can be persisted as references to the [OCI Manifest][oci-manifest], allowing a entity to define a collection of artifacts.
-- Signatures and their public keys can be moved within, and across OCI compliant registries which support Notary v2.
+- Signatures and their public keys can be moved within, and across OCI compliant registries which support Notary Project signatures.
 - Because content is trusted, an ecosystem of other projects and products can leverage information in various formats.
 
 ### Scenario #1: Local Build, Sign, Validate
@@ -89,8 +89,8 @@ Once the developer has locally validated the build, sign, validate scenario, the
 - The artifact can be renamed from the unique build id `net-monitor:abc123` to a product versioned tag `wabbitnetworks.example.com/networking/net-monitor:1.0` without invalidating the signature.
 - Users may reference the `sha256` digest directly, or the `artifact:tag`.
   While tag locking is not part of the [OCI Distribution Spec][oci-distribution], various registries support this capability, allowing users to reference human readable tags, as opposed to long digests.
-  Either reference is supported with Notary v2, however it's the unique manifest that is signed.
-- Notary v2 supports a pattern for signing any type of artifact, from OCI Images, Helm Charts, Singularity to yet unknown types.
+  Either reference is supported with Notary Project, however it's the unique manifest that is signed.
+- Notary Project supports a pattern for signing any type of artifact, from OCI Images, Helm Charts, Singularity to yet unknown types.
 - Orchestrators may require signatures, but not enforce specific specific signatures.
   This enables a host to understand what content is deployed, without having to manage specific keys.
 
@@ -213,8 +213,7 @@ They pushed unsigned content to existing tags.
 1. How a registry implements the rollback to the previously secured state is a differentiating capability.
    The scenario simply calls out a compromise that must be discoverable through forensic logging of who, when and what was pushed.
    The logged updates must include previous digests that represented updated tags allowing a registry, or external tools, to reset its original state.
-1. A registry may choose to make repos, or the entire registry, restricted to pushing only signed content, and potentially only signed content with one or more keys.
-   Notary v2 doesn't require this capability, rather highlights the scenario for registry operators to innovate means to secure from this scenario.
+1. A registry may choose to restrict repositories or the entire registry to pushing only signed content, and potentially only signed content with one or more keys. With this, attackers cannot push unsigned content to the registry, mitigating the threat described by scenario #7.
 
 #### Scenario #7.1: Repository Compromise - Mutable Tags Modified
 
@@ -253,9 +252,9 @@ A developer accidentally discloses the private key they use to certify their sof
 
 **Implications of this requirement:**
 
-1. All Notary v2 implementations support key revocation as part of their implementation to assure signed content is still valid content.
+1. All implementations of the [Notary Project signature specification](../specs/signature-specification.md) support key revocation as part of their implementation to assure signed content is still valid content.
 1. Registry operators routinely check for revoked keys and remediate the exploited content.
-1. Notary v2 clients routinely check for revoked keys and block the content.
+1. Implementations of the [Notary Project verification specification](../specs/signing-and-verification-workflow.md) routinely check for revoked keys and block the content.
 
 ### Scenario #9: A Crypto Algorithm Is Deprecated
 
@@ -282,7 +281,7 @@ Maybe this is an internally created artifact with a known signing key.
 This key may be distributed using a trusted third party mechanism.
 
 1. The user obtains a trusted key for a particular artifact.
-1. The user downloads and verifies the artifact using Notary v2 and their known key.
+1. The user downloads and verifies the artifact using implementations of the [Notary Project verification specification](../specs/signing-and-verification-workflow.md) and their public key.
 
 **Implications of this requirement:**
 
@@ -310,7 +309,7 @@ It should be possible for the signer to revoke the trust in that vulnerable arti
 If a user does not have a specific key for a given artifact, verified using a third party system, they will need to determine the trusted signing key(s) for an artifact by chaining from a trusted key.
 
 1. The user determines the trusted key(s) for a specific artifact using delegations from a trusted root.
-1. The user downloads and verifies an artifact using Notary v2 and the trusted key(s) discovered in the previous step.
+1. The user downloads and verifies an artifact using implementations of the [Notary Project verification specification](../specs/signing-and-verification-workflow.md) and the trusted key(s) discovered in the previous step.
 
 **Implications of this requirement:**