method to export timestamp key from notary-signer

[lewiada-zz]

There are use cases where a developer will deploy software to multiple production sites, some of which may not have connectivity to the master notary server / signer. In these scenarios, there is a need to securely export the timestamp key (and even the snapshot key in the case of delegation) so that it can be imported into a local notary server/signer at the production site. Is there currently a means to do this?

[cyli]

@lewiada Not currently. How do you anticipate this to be used?

1. Migrating your source of trust from one notary server to another, and not using that first one again?
2. Mirroring one notary server to another site which doesn't have connectivity?
3. Alternating between pushing to either content trust server, sort of like git remotes?

For the first two cases, Notary server has a changefeed API now, and we have been thinking about providing mirroring capabilities. That means only one notary server will be writable, and the other one will just get updated from the main one. (Possibly the changes could be exported, if the second cannot connect to the first).

In the meantime, you could rotate the snapshot and timestamp keys before pushing, so long as you have the root key.

However, this means that you cannot constantly switch back and forth between pushing between notaryserver1 and notaryserver2.

---

Update:

As I was testing this out, however, I realized that you can't rotate 2 keys at once, and it publishes as soon as you attempt to rotate the key, so it will always fail. We should probably also fix that.

For instance, right now, if the notary server only had the timestamp key:

$ # download from first notary server
$ notary -s https://notaryserver1 list myrepo
...

$ notary -s https://notaryserver2 publish myrepo
Enter passphrase for snapshot key with ID b114798: 
* fatal: An error occurred during validation: rpc error: code = 5 desc = key 938edfd0b0c881872cefed7f161fa4e877ff51503f4652240ba3c37b5c96a733 not found

$ # rotate the timestamp key to ones the new notary server has
$ notary -s https://notaryserver2 key rotate myrepo timestamp -r
Enter passphrase for root key with ID 76a4ff5: 
Enter passphrase for snapshot key with ID b114798: 
Successfully rotated timestamp key for repository myrepo

$ # You don't actually need to publish again, the key rotation publishes, just illustrating the point
$ notary -s https://notaryserver2 publish myrepo
Enter passphrase for snapshot key with ID b114798: 
Successfully published changes for repository myrepo

[HuKeping]

and we have been thinking about providing mirroring capabilities.

@cyli this is an interesting feature! But is there a explicit scenario for this?

[cyli]

@cyli this is an interesting feature! But is there a explicit scenario for this?

Originally we were thinking of it as a way to provide migration from a RethinkDB to a MySQL setup, since the company behind RethinkDB has shut down. It's was just a consideration. :) Am trying to get a feel for if such a thing would be useful for other use cases.

[lewiada-zz]

@cyli My use case is your number 2. Using some inspiration from RFC7591, consider the separation of a software developer creating docker images, and the deployment organization. ACME is the software developer, and offers a SaaS product hosted in AWS with connectivity to a notary server/signer also hosted in AWS. However ACME also sells their software to government organizations that for security reasons do not connect to the Internet. Docker Images are sneakernet'd over an air gap to a deployment organization's docker registry, as is the signed metadata from the Notary server. However because of the air gap, the notary server at the deployment organization will not be able to communicate with the notary-signer in AWS. My thought was to export the timestamp key from the central notary signer and import it into an install of a notary signer deployed behind the air gap. Does this shed light on the use case? This is an actual need, not a hypothetical.

I suppose another way might be to create all new tagging keys at the deployment organization while in a secure, offline enviornment. Might be more than one way to solve this.

tx!

[cyli]

@lewiada And the reason for exporting the timestamp key is that sneakernet syncs don't occur very often (e.g. less often than the 2 weeks in which it'd take the timestamp file to expire)?

[lewiada-zz]

@cyli That's right ... some might just be on a quarterly basis for example. In some cases, even longer depending on the deployment organization and how often they want to upgrade software releases.

[endophage]

@lewiada this has come up in discussions in the past, so far we've been suggesting the air-gapped network would sign things in with their own keys. In addition to solving the key sharing problem, it provides them with better accountability on when the data entered their system and potentially (with appropriate delegation setups) who introduced it.

I guess it would be useful/desirable to keep a backup of the upstream data so maybe it makes sense to have some kind of "sync" operation between 2 notary repositories. You could import the SaaS provider's notary data to a repo named something like "upstream" then perform a sync of targets to your internal repository. That would bypass any key sharing necessity and provide both external and internal auditability.

[cyli]

@endophage Wondering whether we can just some public keys from the airgapped notary server deployment, and sign them in as alternate timestamp/snapshot keys in the AWS notary deployment. Thus no shared keys, but it's still easy to just sync all the repo data.

@lewiada Also, would the repos be updated much more frequently in the AWS notary deployment, and then once a quarter the latest version of the repos in the AWS notary server would be synced with the airgapped notary server? Or would the sync include all the previous versions of the repos in the AWS notary server?

I'm asking because #942 updated the server to require the root versions to be monotonically increasing, so if the AWS notary server's repo has moved several root versions ahead, syncing only the latest version with the airgapped notary server may be difficult.

[endophage]

@cyli interesting idea. My main concern would be you're now handing over a copy of the root.json that would allow a malicious downstream to MITM your other users and execute an undetectable freeze (and to some degree mix-and-match, via selective target/delegation file updating) by substituting their own timestamp/snapshots.

[cyli]

@endophage Ah that's true, I was thinking that you owned both upstream and downstream, but on re-reading the case above yes it seems like you can't necessarily trust the downstream.