Cleanup import-export and key architecture

[endophage]

Thought there was an issue, apparently not. As discussed in the past, key storage should be cleaned up to have clear logical divisions. At the top level, a CryptoService should deal in operations: sign, create, etc... trustmanager.KeyStore should speak Public/PrivateKey objects, and the trustmanager.Storage interface should speak in []byte.

Import/Export should then operate against a either the KeyStore, or Storage interface (TBD, based on password requirements).

We're going to go about cleaning this up in 3 steps as trying to do it all at once turned into a big mess that prevented me getting it commited last time. In order the steps are:

• Remove all existing import/export functionality - PR #806 part 1: tear out import/export #807
• Refactor CryptoService, KeyStore, and Storage to strictly abide by the rules above, acting on operations, Public/PrivateKey objects, and []byte, respectively - PR #806 Part 2: Cleanup KeyStore Implementations #808
• Re-implement import/export on top of this new, cleaner stack - PR #806 Part 3: Reimplement import export #825

[HuKeping]

Maybe we should put on a label like breaking-change with red background color here to remind people that it could be not any guarantee of backwards compatibility with importing already exported keys.

But since it was not on a v1.0 yet, it's fine to do so.

[endophage]

@HuKeping great idea! Will create and add the label now

[endophage]

@HuKeping @andrewhsu I've been talking with the team here at Docker and we think an easy way to re-implement import/export is to use .pem files which already support containing multiple unique PEM blocks.

Export will pack all the keys being exported into a single .pem file, each delineated as a unique PEM block. Import can take any number of .pem files and will unpack each individual PEM block into a separate file.

I propose the following command formats:

notary export     # with no further arguments, exports all private keys on the host
notary export --gun my_gun [--gun my_gun]    # online operation that exports all keys currently valid within the gun(s). Flag can be provided multiple times 
notary export --key <keyID> [--key <keyID>]...   # exports only the provided key IDs. Flag can be provided multiple times.

notary import file1.pem file2.pem ...

All export commands will output to stdout by default and will take a -o flag to provide an output file. Current I do not intend to allow mixing the --gun and --key flags, but I may make it possible depending on the emergent ease/difficulty found during implementation. That flexibility could also be added at a later time, there's no inherent reason why it shouldn't be possible.

cc @riyazdf @cyli

[HuKeping]

Sounds good and I also think the scenario that wants to export all keys of one gun and one/two keys of another is not that common.