---
# System prepended metadata

title: Notary v2 - Rescinding Signature Validity
tags: [notary]

---

# Notary v2 - Rescinding Signature Validity 

###### tags: `notary`

Artifact Publishers need mechanisms to indicate that a signature they generated is still trustworthy. 

#### Scenarios
- A Publisher vends a new version of an artifact, and wants to indicate the new version as trusted in addition to older versions already published.

#### Discussion Areas
- Code signing is a mechanism for Publishers to explicitly indicate trust which is implicitly trusted by Consumer given some conditions are satisfied (based on trust policy, signature being valid and unrevoked)
    - An explicit allowlist is not required
    - A denylist is required in addition to indicate which artifacts are no longer trusted

- Signature Allowlist explicitly specifies the list of trusted artifacts.
    - Pros
        - Anything not in the list is implicitly untrusted, no separate revocation mechanism is required
        - If signed allowlist are used, the artifacts themselves may not need to be signed.
    - Cons
        - The allowlist needs to be updated for every version of artifact being published
        - May need to maintain a large allowlist which may be an overhead to distribute
- Signature Denylist
    - For Consumers, denylist allows explicitly indicating that an artifact or dependency is untrusted
    - For Publishers, this allows communicating to Consumers that specific versions of artifact are untrusted.

- Centralized/local public/private lists
    - The list can be local to repository, requiring update to the list in each repository, and requires keeping track of all repositories where the artifact needs to be published/revoked.
    - The list can be centralized
        - Centralized deny list (e.g. CRL maintaned by public CAs) can be used. The endpoint infomation is included in the signature, and signature verification step checks against this list.
            - Customers can define network topology with restricted network access, where these endpoints may not be accesible for hosts where signature verification occurs.
            - These endpoints may not be available in air-gapped environments.
    - Public lists (e.g. transparency logs) may not be suitable for enterprise customers who don’t want their artifact updates to be disclosed publicly.