[TEP-0091]Update TEP with design evaluaitons and api changes

This commit adds more details of design evaluation. Since we need to
pull in sigstore to make this proposal work, this needs to be
included in this TEP.

teps/0091-trusted-resources.md

@@ -21,10 +21,10 @@ authors:
 - [Proposal](#proposal)
   - [Risks and Mitigations](#risks-and-mitigations)
   - [User Experience](#user-experience)
-  - [Performance (optional)](#performance-optional)
 - [Design Details](#design-details)
 - [Test Plan](#test-plan)
 - [Design Evaluation](#design-evaluation)
+  - [Performance](#performance)
 - [Drawbacks](#drawbacks)
 - [Alternatives](#alternatives)
 - [Infrastructure Needed (optional)](#infrastructure-needed-optional)
@@ -179,10 +179,6 @@ The verification will be done in the pipeline's reconciler. By default we will s
 
 During verification, the signature will be extracted from the resource (or fetched from a remote source can be supported later), and the public keys are fetched from cluster deployed ConfigMap and CRD. Public keys and signature are used to verify the resources.
 
-### Performance
-
-The verification should not introduce too much latency into the reconciler. We propose to do the verification after resolution in the reconciler. So no duplicate resolution is needed compared to doing verification at webhook.
-
 ## Design Details
 
 ### Sign the Resources
@@ -292,15 +288,16 @@ type VerificationPolicy struct {
 }
 
 type VerificationPolicySpec struct {
-	// Resources defines the patterns of Resources names that should be subject to this policy. For example, we may want to apply this Policy only from a certain github repo. Then the ResourcesPattern should include the path. If using gitresolver, and we want to config keys from a certain git repo. `ResourcesPattern` can be `https://github.com/tektoncd/catalog.git`, we will use regex to filter out those resources.
-	Resources []ResourcePattern `json:"resources"`
-	// Authorities defines the rules for validating signatures.
-	Authorities []Authority `json:"authorities"`
+	// ResourceAuthorities defines the list of ResourceAuthority, where each contains resource pattern and
+	// corresponding keys
+	ResourceAuthorities []ResourceAuthority `json:"resourceAuthorities"`
 }
 
-type ResourcesPattern struct {
-	// Pattern defines a resource pattern. Regex is created to filter resources based on `Pattern`
+type ResourceAuthority struct {
+	// Pattern defines a resource pattern. The pattern is used to filter out remote resources by their sources, by default is "*"
 	Pattern string `json:"pattern"`
+	// AuthoritityList defines the list of keys used to verify
+	AuthoritityList []Authority `json:"authoritiyList"`
 }
 
 // The authorities block defines the rules for discovering and
@@ -314,9 +311,6 @@ type Authority struct {
 	// Keyless sets the configuration to verify the authority against a Fulcio instance.
 	// +optional
 	Keyless *KeylessRef `json:"keyless,omitempty"`
-	// Sources sets the configuration to specify the sources from where to consume the signatures if the signature is not stored in the resource.
-	// +optional
-	Sources []Source `json:"source,omitempty"`
 }
 
 type KeyRef struct {
@@ -407,6 +401,71 @@ How does this proposal affect the reusability, simplicity, flexibility
 and conformance of Tekton, as described in [design principles](https://github.com/tektoncd/community/blob/master/design-principles.md)
 -->
 
+### Reusability
+
+<!--
+https://github.com/tektoncd/community/blob/main/design-principles.md#reusability
+
+- Are there existing features related to the proposed features? Were the existing features reused?
+- Is the problem being solved an authoring-time or runtime-concern? Is the proposed feature at the appropriate level
+authoring or runtime?
+-->
+
+There are no existing features in Tekton which can be reused.
+
+This problem is runtime-concern and the proposed feature is at runtime level.
+
+
+### Simplicity
+
+<!--
+https://github.com/tektoncd/community/blob/main/design-principles.md#simplicity
+
+- How does this proposal affect the user experience?
+- What’s the current user experience without the feature and how challenging is it?
+- What will be the user experience with the feature? How would it have changed?
+- Does this proposal contain the bare minimum change needed to solve for the use cases?
+- Are there any implicit behaviors in the proposal? Would users expect these implicit behaviors or would they be
+surprising? Are there security implications for these implicit behaviors?
+-->
+
+This proposal doesn't have any effect if users don't enable it. If enabled, users need to sign the resources and config the public key in cluster to bypass verification, the mutating webhook will be skipped for API resources to avoid the failing verification.
+
+### Flexibility
+
+<!--
+https://github.com/tektoncd/community/blob/main/design-principles.md#flexibility
+
+- Are there dependencies that need to be pulled in for this proposal to work? What support or maintenance would be
+required for these dependencies?
+- Are we coupling two or more Tekton projects in this proposal (e.g. coupling Pipelines to Chains)?
+- Are we coupling Tekton and other projects (e.g. Knative, Sigstore) in this proposal?
+- What is the impact of the coupling to operators e.g. maintenance & end-to-end testing?
+- Are there opinionated choices being made in this proposal? If so, are they necessary and can users extend it with
+their own choices?
+-->
+
+Dependencies need to be pulled into tekton pipelines for this proposal:
+*	github.com/sigstore/sigstore
+
+We are coupling Tekton and Sigstore in this proposal.
+
+What is the impact of the coupling to operators e.g. maintenance & end-to-end testing?
+
+* Need to install sigstore in dogfooding cluster to sign & verify official resources as part of testing
+
+Reason why this is required.
+
+* It is a convenient library to load keys because it supports KMS from major cloud providers, and also supports rsa, ecdsa, ed25519 keys loading.
+
+Are there opinionated choices being made in this proposal? If so, are they necessary and can users extend it with
+
+* We choose to use Sigstore to create signer and verifier, users cannot extend/replace it with other options. But users can use whatever keys supported by Sigstore.
+
+### Performance
+
+The verification should not introduce too much latency into the reconciler. We propose to do the verification after resolution in the reconciler. So no duplicate resolution is needed compared to doing verification at webhook.
+
 ## Drawbacks
 
 See [risks and mitigations](#risks-and-mitigations).