[Impl] Signing plugin integration - Local on disk key/key-file signing

[iamsamirzon]

Summary
Intended Outcome
The APIs are implemented in GO programming language; Add optional password protection for keys stored on local storage
Additional context
Part of this was done as alpha-1. The remaining parts are - password protection and adding a certificate chain
We need a spec on what format(s) to support and, am implementation. For RC-1 we can use one format.

---

Impl context

• Along with signingKey(private key) we will need signing certificate and certificate chain as signing certificate and certchain will be embedded in signature envelope.
• Also, how about using default name for default identity? Although this works better with INI format.

"signing-identites": [
  {
      "name": "default",
      "signing-certificate": "~/./notary/keys/wabbit-networks.crt",
      "signing-certificate-chain": ""~/./notary/keys/wabbit-networks-chain.crt",
      "private-key": "~/./notary/keys/wabbit-networks.key"
  },
  {
      "name": "import-acme-rockets",
      "signing-certificate": "~/./notary/keys/import-acme-rockets.crt",
      "signing-certificate-chain": ""~/./notary/keys/import-acme-rockets-chain.crt",
      "private-key": "~/./notary/keys/import-acme-rockets.key"
  }
]

The implementation details was copied from notaryproject/notation#89

[iamsamirzon]

We should specify the default signing experience and how it is protected ( with a password etc).

[iamsamirzon]

Part of "E2E signing workflow with local keys" in the spreadsheet. This is the implementation part

[yizha1]

Hi,

The remaining work for this issue is to support encrypted local key, however, due to lack of go library and limited dev capacity, the proposal is to move this issue out of RC1 scope.

It is also proposed to keep the support of signing with local key, which was implemented as first part of this issue. If this function is removed, user need to set up Key Vault or KMS environment in order to try notation signing function, which may not be affordable or feasible for the user. In other words, the following use cases will not be supported:

• As a user, I want to experience notation signing using a self-signed local key
• As a user, I want to sign using a local key where remote signing is not enabled

We could add some notes in the document or tips for the local sign commands to emphasis that it is for testing purpose only.

cc @FeynmanZhou @shizhMSFT

Thanks,
Yi

[roywill]

Since we don't have existing libraries for Go that handle the PKCS scenarios we think we need, I see we have four options:

1. delay\punt this feature to next release,
2. invest in the time to implement the go library features,
3. Offer it as a standalone signing tool leveraging another language where the libraries exist, or
4. Allow third party tools to do this.

The interesting thing to be aware of is that if we wanted something like SigStore to sign then their move to adopt COSE would still have to wait until we accept that format.

If that is a future goal, then planning to build a solution that would have to change in the near term and should enable SCITT and other services to sign.

[iamsamirzon]

@gokarnm - Could you look at this proposal from @roywill above? If this functionality is removed from RC-1, then doing automated testing will require some other approach.

[iamsamirzon]

@roywill - @gokarnm suggestion is to maintain the test certificate generation for RC-1 that allows users to test locally. https://github.com/notaryproject/notation/blob/main/docs/hello-signing.md#signing-a-container-image

[iamsamirzon]

This is related on having the spec finalized in #44

[iamsamirzon]

Based on the agreement in NV2 community call on 12/5/2022, moving this out of RC-2