Configuration file spec by SteveLasker · Pull Request #76 · notaryproject/notation

SteveLasker · 2021-08-27T22:19:32Z

Capturing the configuration file, at its current state

Signed-off-by: Steve Lasker <stevelasker@hotmail.com>

Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>

specs/notation-config.md

shizhMSFT · 2021-08-30T05:46:44Z

specs/notation-config.md

+  "verificationCerts": {
+    "certs": [
+      {
+        "name": "wabbit-networks.io",
+        "path": "~/./notary/keys/wabbit-networks.crt"
+      },
+      {
+        "name": "import.acme-rockets.io",
+        "path": "~/./notary/keys/import-acme-rockets.crt"
+      }
+    ]
+  },


Why do we need certs inside of verificationCerts? It is redundant.

I was trying to align with keys which has default nested, so it needed keys.
Suggestions?

Leaving for this PR, and lets address how we want to handle verificationCerts and signingKeys
Do we want to pull default out to a root node?

@SteveLasker - Moving this into the notary location exposes the notation CLI to need ACLs and policise that are present with notaryV1. My recommendatiaon is to have this under .notation for now and open an issue to unify the config location with notaryv1 if that is the requirement.
/cc @gokarnm

How about naming it verification-identities and changing structure to something like this?

"verification-identities": [ { "name": "wabbit-networks.io", "certificate-path": "~/./notary/keys/wabbit-networks.crt" }, { "name": "import.acme-rockets.io", "certificate-path": "~/./notary/keys/import-acme-rockets.crt" } ]

If we are planning to support only referencing(using path) not inlining of certificate then we can rename certificate-path to certificate.

Also, are we thinking of supporting truststore and trustpolicy evaluation using this cli or its just that signature leads to a trusted certificate? If its former then we might not need verificationCerts instead we can refer trusstore+trustpolicy.

@SteveLasker - Moving this into the notary location exposes the notation CLI to need ACLs and policise that are present with notaryV1. My recommendatiaon is to have this under .notation for now and open an issue to unify the config location with notaryv1 if that is the requirement.
/cc @gokarnm

@sajayantony @SteveLasker would like to understand better if there is a requirement, and the motivation for unifying config with notary V1.

is a requirement, and the motivation for unifying config with notary V1.

It was more about reducing folder sprawl. I'm trying to avoid end users having to "feel the pain" of multiple folders being created as a result of using v1 and v2.
We don't have much usage of notary v1, so it's a minimal issue.
It's not the most pressing issue, so you could also argue, if most users don't have notary v1, is it really folder sprawl as they'll only have a single folder, "./notation".
I'll update to use notation and not be something to take more time for us to think about

are we thinking of supporting truststore and trustpolicy evaluation

Yes, we should incorporate truststore policy. However, suggesting we add that as we iterate the details of the trust store policy. This will document the current state, so we can release a notation cli that we can iterate with.
As we complete the truststore policy design and implementation, we can update this config spec.

shizhMSFT · 2021-08-30T05:47:32Z

specs/notation-config.md

+- `enabled` - bool, which acts as an on/off switch for default notation behavior. --enabled false would disable all automatic validations
+- `verificationCerts` - collection of name/value pairs for a collection of public certs that are used for verification. These may be replaced with a future policy configuration.
+  - `name` - a named reference to the certificate
+  - `path` - a location by which the certificate can be found by the notation cli or notation libraries


We need to define whether it is an absolute path or it can be a relative path or both.

Good question. What do you think from a security perspective?

It is better if it is an absolute path.

shizhMSFT · 2021-08-30T05:48:46Z

specs/notation-config.md

+  - `path` - a location by which the certificate can be found by the notation cli or notation libraries
+- `signing-keys` - a collection of name/value pairs of signing keys.
+  - `name` - a named reference to the key
+  - `path` - a location by which the key can be found by the notation cli or notation libraries


Same here for absolute or / and relative path.

Good question. What do you think from a security perspective?

specs/notation-config.md

Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>

shizhMSFT · 2021-08-31T06:35:10Z

specs/notation-config.md

+
+Property | Type |  Value
+------ | ------ | ---
+`enabled`|_bool_|on/off switch for default notation behavior. --enabled false would disable all automatic validations


enabled is used for docker-notation. This field is not meaningful for the notation CLI.

Whats the purpose of enabled field? When will customer actually use it?

@shizhMSFT, this is in the current config file. Are we having separate configs for docker-notation and notation?

priteshbandi · 2021-09-01T20:51:46Z

specs/notation-config.md

+  "signingKeys": {
+    "default": "wabbit-networks.io",
+    "keys": [
+      {
+        "name": "wabbit-networks.io",
+        "path": "~/./notary/keys/wabbit-networks.key"
+      },
+      {
+        "name": "import.acme-rockets.io",
+        "path": "~/./notary/keys/import-acme-rockets.key"
+      }
+    ]
+  },


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" } ]

+1 on requiring signing certificate in addition to private key.

opened issue: #89

priteshbandi · 2021-09-01T21:01:13Z

specs/notation-config.md

+  "verificationCerts": {
+    "certs": [
+      {
+        "name": "wabbit-networks.io",
+        "path": "~/./notary/keys/wabbit-networks.crt"
+      },
+      {
+        "name": "import.acme-rockets.io",
+        "path": "~/./notary/keys/import-acme-rockets.crt"
+      }
+    ]
+  },


How about naming it verification-identities and changing structure to something like this?

"verification-identities": [ { "name": "wabbit-networks.io", "certificate-path": "~/./notary/keys/wabbit-networks.crt" }, { "name": "import.acme-rockets.io", "certificate-path": "~/./notary/keys/import-acme-rockets.crt" } ]

If we are planning to support only referencing(using path) not inlining of certificate then we can rename certificate-path to certificate.

Also, are we thinking of supporting truststore and trustpolicy evaluation using this cli or its just that signature leads to a trusted certificate? If its former then we might not need verificationCerts instead we can refer trusstore+trustpolicy.

priteshbandi · 2021-09-01T21:02:30Z

specs/notation-config.md

+
+Property | Type |  Value
+------ | ------ | ---
+`enabled`|_bool_|on/off switch for default notation behavior. --enabled false would disable all automatic validations


Whats the purpose of enabled field? When will customer actually use it?

priteshbandi · 2021-09-01T21:12:13Z

specs/notation-config.md

+`key.name`|_string_|a named reference to the key
+`key.path`|_string_|a location by which the key can be found by the notation cli or notation libraries
+`signing-keys.default`|_string_|the signing key to be used when `notation sign` is called without `--name`
+`insecureRegistries`|_array_|a list of registries that may be used without https


How is insecureRegistries related to notary?

notation pushes and pulls content to a registry using the oras-go libraries. insecureRegistires is a list of registries enables the flow, as an exception to the normal HTTPS required flag.
It's not just for local instances of distribution. Many IoT scenarios run non https scenarios.

Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>

SteveLasker · 2021-09-03T20:02:55Z

This reflects the current implementation of #83

Suggestion to merge this and #83, and open Issues and PRs for the proposed name changes.
This provides a baseline to test and iterate with issues on functioning bits from main.

NiazFK

LGTM with #89

* Configuration file spec * move under the specs folder * Incorporate feedback on table layout and naming Signed-off-by: Steve Lasker <stevelasker@hotmail.com>

Steve Lasker and others added 6 commits June 19, 2020 17:39

Notary v2 prototye process

1db7a79

Signed-off-by: Steve Lasker <stevelasker@hotmail.com>

Notary v2 prototye process

bd6054b

Signed-off-by: Steve Lasker <stevelasker@hotmail.com>

Notary v2 prototye process updates

f1ea87a

Signed-off-by: Steve Lasker <stevelasker@hotmail.com>

Rev of sketch, w/oci-index v3-index.config

531a109

Signed-off-by: Steve Lasker <stevelasker@hotmail.com>

merge

9b64000

Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>

Configuration file spec

321db15

Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>

SteveLasker requested a review from a team August 27, 2021 22:19

SteveLasker added 2 commits August 27, 2021 16:05

move under the specs folder

0838141

Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>

move under the specs folder

fe46a2e

Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>

juliusl approved these changes Aug 28, 2021

View reviewed changes

specs/notation-config.md Show resolved Hide resolved

shizhMSFT requested changes Aug 30, 2021

View reviewed changes

shizhMSFT reviewed Aug 30, 2021

View reviewed changes

specs/notation-config.md Outdated Show resolved Hide resolved

jonjohnsonjr reviewed Aug 30, 2021

View reviewed changes

specs/notation-config.md Show resolved Hide resolved

Incorporate feedback on table layout and naming

3f91b78

Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>

SteveLasker added the cli Issue or PR released to Notation CLI label Aug 30, 2021

shizhMSFT reviewed Aug 31, 2021

View reviewed changes

priteshbandi reviewed Sep 1, 2021

View reviewed changes

priteshbandi mentioned this pull request Sep 2, 2021

Added certificates generate command #68

Closed

shizhMSFT mentioned this pull request Sep 3, 2021

Notation CLI baseline #83

Merged

Updates to reflect the current release

894e6c9

Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>

SteveLasker added this to the alpha-1 milestone Sep 3, 2021

priteshbandi mentioned this pull request Sep 10, 2021

[Local Key Signing] Support signing certificate and certificate chain in Configuration file #89

Closed

NiazFK approved these changes Sep 14, 2021

View reviewed changes

SteveLasker merged commit af8b2b3 into notaryproject:main Sep 14, 2021

iamsamirzon added cli Issue or PR released to Notation CLI and removed cli Issue or PR released to Notation CLI labels Sep 22, 2021

Comments

Conversation

SteveLasker commented Aug 27, 2021

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SteveLasker commented Sep 3, 2021

Uh oh!

NiazFK left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants