Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Key management scenarios #34

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
+20 −0
Open

Key management scenarios #34

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
1084b49
add initial key management scenarios
mnm678 Jun 15, 2020
1937f3f
Make descriptions more generic
mnm678 Jun 21, 2020
d85d1c9
images -> artifacts
mnm678 Jun 22, 2020
81f434d
Add clarifications
mnm678 Sep 2, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions key-management-scenarios.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
# Notary Key Management Scenarios
In order to allow for end to end signing of artifacts, Notary v2 will require the use of cryptographic keys. These scenarios define how these keys will be generated, distributed, and trusted in Notary v2.

## Scenarios

### Scenario #1: A developer signs a package for the first time
The first time a developer signs a package, they will need to set up a signing key and their local environment.
1. Generate a developer signing key.
1. Create a local environment that delegates to the developer key for testing.
1. The developer signs local content.

### Scenario #2: A developer is given permission to upload to a registry (for the first time)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By "upload to a registry", do you mean push artifact to the registry?
If the answer is yes, the permission has been enforced by the authentication mechanism of registry. I don't think the truest relationship between a registry and a developer needs to be covered in key mgmt scenario.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I can switch to that wording if that would be more clear.

I think there are two separate issues here: whether the new developer has permission to push artifacts to the registry and whether the new developer's keys are available and trusted by the registry or registry users. The first issue is certainly out of scope for key management, but I believe the second is something should be addressed by the key management solution.

Copy link

@marcofranssen marcofranssen Sep 25, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally agree @mnm678, I see this in a similar fashion as you would verify your SSH private public key pair before getting access to the server.

E.g. lets say my registry credentials got compromised, but the attacker doesn't have my private keys, In that case he won't be able to sign an image as my key is not there. He also won't be able to add his own key as for that he also would require a key more up in the key hierarchie to add his own.

Regarding the wording I think it depends. Current version of notary in theory also supports artifacts beyond the scope of Docker. So if notary v2 will also go that route I think terminology like upload is better and covers things better in general. However if we are entirely focusing on Docker then terminology like push and pull would be better.

The first time a developer uploads to a registry, they need to establish that they are a trusted developer.
1. Add the developer key to delegating party on the registry. There may be a single delegating party on a registry, or multiple that are trusted for different artifacts.

### Scenario #3: A developer updates their signing key
In the event of a compromised or lost key, a developer may need to switch to a new signing key.
1. The developer will generate a new signing key.
1. The new developer key will need to be added to the delegating party on the registry.
1. The previous developer key should no longer be trusted.
Copy link

@marcofranssen marcofranssen Aug 28, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this also mean a developer can't have multiple signing keys?

Currently in notary v1 this is possible.

Comparing this to SSH keys or GPG keys I could potentially use different keys on different systems, which are still linked to the same entity on a server.

Revoking a key is in those cases usually a manual step.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just referring to the single key that was compromised. If a developer has multiple keys, only the compromised key should be revoked. I will re-word to try to clarify this.