Signing and Verification

[gokarnm]

Discussion points to help with scoping and design of signing and verification flows.

Separation of concern between Docker CLI, Notary V2 and signing providers.

• Should NotaryV2 be tightly integrated with OCI artifacts or can it sign any kind of content?
• Should NotaryV2 be tightly integrated with Docker CLI?
  • Are there other container tools that pull/push images, and can be used to initiate signing?
  • Should Notary V2 support stand alone usage - to push signatures in addition to generating signatures? Should NotaryV2 produce signature blob and signature manifest? Or Docker CLI will create signature manifest?
  • Should Notary V2 support stand alone verify?

Extensibility points

• Signing providers
  • Interface
    • e.g. Sign (payload, keyid/signerId, other provider specific params) returns a signature envelope
  • Customer configures set of available signing providers in Notary V2 config file
  • Signing format - descriptor of signature blob should specify the envelope format + payload version
  • What kind of identity types should Notary V2 support in RC1/GA
    • Cloud based identity (e.g. AWS Signing Profile, Azure Key Vault)
      • Remote signing
    • PKCS#11 (Hardware token, yubikey)
    • Customer owned PKI
      • Local cert with private keys. Requires implementing Sign() operation in Notary V2.
    • Other?
• Verification - certain steps in signature verification may vary based on identity type
  • Public key retrieval - get public key for given logical key id
  • Revocation check
    • PKI - CRL/OCSP
    • Hardware tokens may not have a notion of revocation, if not linked with a PKI (verification policy can explicitly list untrusted keys)
    • Custom revocation check

[sudo-bmitch]

Discussion points to help with scoping and design of signing and verification flows.

Separation of concern between Docker CLI, Notary V2 and signing providers.

* Should NotaryV2 be tightly integrated with OCI artifacts or can it sign any kind of content?

It should be allowed to sign any descriptor. That descriptor may or may not be already pushed to a registry, and can point to a variety of media types.

* Should NotaryV2 be tightly integrated with Docker CLI?

No.

  * Are there other container tools that pull/push images, and can be used to initiate signing?

Yes.

  * Should Notary V2 support stand alone usage - to push signatures in addition to generating signatures? Should NotaryV2 produce signature blob and signature manifest? Or Docker CLI will create signature manifest?

Yes, there will be needs to sign in an isolated environment, possibly without docker or registry access, outputting either the blob or preferably the OCI Layout tar. The ability to push directly to the registry should also be included since many users will want the easy option for online use cases.

  * Should Notary V2 support stand alone verify?

Yes. For disconnected support.

Extensibility points

* Signing providers
  
  * Interface
    
    * e.g. _Sign (payload, keyid/signerId, other provider specific params)_ returns a signature envelope
  * Customer configures set of available signing providers in Notary V2 config file
  * Signing format - descriptor of signature blob should specify the envelope format + payload version
  * What kind of identity types should Notary V2 support in RC1/GA
    
    * Cloud based identity (e.g. AWS Signing Profile, Azure Key Vault)
      
      * Remote signing
    * PKCS#11 (Hardware token, yubikey)
    * Customer owned PKI
      
      * Local cert with private keys. Requires implementing Sign() operation in Notary V2.
    * Other?

Yes to all. I may have a key accessible only from an external system (e.g. HSM, Vault Transit iplugin) that I perform the signing with my own API (I may need to feed in other data to that API to get the approval, e.g. Spire workload attestation, in-toto link files, etc).

* Verification - certain steps in signature verification may vary based on identity type
  
  * Public key retrieval - get public key for given logical key id

There needs to be some way to transfer the certificate chain, and I'd prefer this was included directly in Notary. The client should have a root certificate (or intermediate) in their local trust store transmitted separately, outside of Notary. Having an additional way to add other ways to retrieve that chain may be useful for some organizations.

  * Revocation check
    
    * PKI - CRL/OCSP
    * Hardware tokens may not have a notion of revocation, if not linked with a PKI (verification policy can explicitly list untrusted keys)
    * Custom revocation check

Extending makes sense as long as the core capability is built into Notary.

[sudo-bmitch]

For reference, the OCI Layout for filesystem formatting of a registry object is defined here: https://github.com/opencontainers/image-spec/blob/main/image-layout.md