Key management scenarios

[mnm678]

This reopens #23 on the new branch.

[marcofranssen]

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.

[mnm678]

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.

[reasonerjt]

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.

[mnm678]

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.

[marcofranssen]

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.

[marcofranssen]

In general I have one question.

Do we need to document some steps in the scenarios regarding the following?

• If I used my compromised key to sign any releases in any target collection that means I will have to resign those releases with a new key (notary v1) before I can remove that compromised key.

  Should we include that step in the scenario? I think that could be automated server side when swapping out a key.

• What if that delegation key was added on multiple targets? shouldn't we have a scenario where a end-user can easily swap out that key with a new one on all the given targets (or server side recursively find those targets it was used). Also here the automation to resigning/rotating releases using that key could/should be automated for convenience of the end-user.

  Should we include this kind of scenario as well? Currently in notary v1 I think the focus on end-user is lacking. E.g. the IT support user managing that for a group of people in the organization or the junior developer who just wants to make a release and has no deep knowledge on the topic of encryption and TUF.

[gillg]

Why not speaking about the best practice in term of key management which is to use a physical or virtual HSM device ?

As an exemple Azure KeyVault is certified HSM fips 140-2 level 2, so it allows to generate signing key, associate a cert to it and let you sign with an API call without never being able to retrieve the key. No one can read the key, including Azure admins.
On AWS a lot more expensive solution is AWS CloudHSM, and after there is other options.

But for information, if you want to buy an Extended Validation (EV) Signing cert, you have to store the key on a fips 140-2 level 2 to be able to buy your cert. That means, you certify that no one, including you, can retrieve the key.
After that... Obviously you have to secure your HSM API access ^^

[yizha1]

@mnm678 Would you mind closing this PR since no activities for more than 6 months? You can create a new issue to describe the problem if needed. Thanks.

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 30 days.