Updated Key Management Scenarios

[NiazFK]

Made some language modifications, added personas, diagrams, and definition placeholders.

[marcofranssen]

In general I see there is only discussed 2 type of keys.

• Root Keys
• Delegation Keys

What about the Target Keys as we know them in notary v1?

Do we need a scenario or feature to migrate notary v1 certificates to nv2?
If we start with fresh keys in notary v2, do we need a scenario to migrate v1 signatures?

[trishankatdatadog]

These are all very good points.

I will note that these problems have been largely solved with TUF, if not Notary v1, which made key management more complicated than it needed to be. We can simplify them in v2.

If v2 is going to support multiple signing solutions beyond TUF (such as OpenPGP), then they will need to somehow handle these scenarios, but right now, I fail to see how they would do it without basically reinventing TUF or using something more complicated like x509.

[SteveLasker]

A bunch of nits, but mostly great.
Just need to figure out what we want to fix and merge now, vs. other content to keep discussing.
Would suggest merging the top half and move the prototype content to an issue for us to start implementing.

[sudo-bmitch]

We could use some discussion on what the root key distribution method looks like, and what options we have. TOFU is universally disliked. I'm not sure the ssh style "do you trust this new root" is any better, particularly since that requires interactive users. If the only option is out-of-band, we should spell that expectation out in the document.

I'm also interested in how we will distribute the certificate chains to the deployers. For example, if a signer has a longer expiration time than a parent in the chain, and we include the signing chain in the artifact signature, then updating the chain when the parent updates their certificate would require updating each artifact signature, which I'd like to avoid.

I also want to be sure we always have the ability to run this in a stand-alone environment, with a small organization deploying their own registry server, and hopefully not much else, to have a functional implementation. Adding features like external TSAs are useful for added security, but I'd like to keep anything external as "should" rather than "must", where the deployer defaults to secure settings with the option to disable features.

[mnm678]

Thanks for all the work on this! I left a couple comments/ideas. What's the process going to be for making decisions about the issues discussed here? It would be nice to have a formalized process to make sure we're making the right design choices.

[mnm678]

For TSAs, I believe the internet is also required for verification to ensure that the signature was valid when created. There might be a way to pass this verification through an entity outside the air-gapped environment, but this does add an additional step.