# Notation-go Revocation Functionality

This document outlines how the revocation functionality from notation-core-go will be integrated into notation-go. This integration will allow for revocation checks to be conducted as part of the Verify process.

This change plans to address the following issues:

* Implement OCSP Support (https://github.com/notaryproject/notation-core-go/issues/124)
* Implement CRL Support (https://github.com/notaryproject/notation-core-go/issues/125)

The proposed integration is based upon previously defined specifications.

The following will be added/modified in the verifier package within the existing verifier.go file:

// The internal struct will have the caches added to it. These caches will be set up in the New function
type verifier struct {
    trustPolicyDoc *trustpolicy.Document
    trustStore     truststore.X509TrustStore
    pluginManager  plugin.Manager
    ocspCache      *revocation.Cache
    crlCache       *revocation.Cache
}

// The New function will be modified to set the ocspCache and crlCache
// It will use the default Cache that is defined in the notation-core-go revocation package until we develop an on-disk Cache
func New(trustPolicy *trustpolicy.Document, trustStore truststore.X509TrustStore, pluginManager plugin.Manager) (notation.Verifier, error)

// Since a section has already been added to Verify as a placeholder for revocation, it will be modified to incorporate the verifyRevocation function
func (v *verifier) Verify(ctx context.Context, desc ocispec.Descriptor, signature []byte, opts notation.VerifyOptions) (*notation.VerificationOutcome, error)

// The verifyRevocation function will use the revocation.Validate() function defined in notation-core-go to verify the revocation status
func verifyRevocation(outcome *notation.VerificationOutcome) *notation.ValidationResult

TypeRevocation has already been added to the ValidationTypes in the trustpolicy, so no change is needed there.

Since the Verify function is not persistent (i.e. it is part of a CLI not a long-lived program/server), we will need to use an on-disk cache rather than an in-memory cache. From my research, there are no go packages that are widely accepted for this task. Additionally, the existing solutions are not very robust. Thus, it is necessary to define our own on-disk caching implementation. For now, this caching will be the default in-memory cache that is defined in the notation-core-go revocation package (essentially just a map). This implementation will not provide any of the benefits of caching to the CLI. However, we can easily switch this out to a proper caching implementation in a later change. This will be tracked in a new GitHub Issue.