extracting pkcs11 implementation from notary and replacing it with RPC interface

[jschintag]

This PR extracts the pkcs11 HSM implementation from notary and replaces it with an RPC interface.
New HSM implementations can now implement their own adapter independent from notary through using the RPC interface.

Closes #1289

[docker-jenkins]

Can one of the admins verify this patch?

[jschintag]

I have an example implementation of an adapter in this repositorys:
yubikey
opencryptoki

The PKCS11 Tests currently only pass for the externalstore package. All other pkcs11 tests with go test fail because the credentials are not included.

[jschintag]

@justincormack Hey, i rebased the PR to upstream. Any news on this?

[Silvanoc]

@jschintag I'd like to test your patch. How do I select the usage of an opencryptoki token for a specific role? Does it get automatically selected only for 'root' if available, as for the Yubikey? I haven't seen any new CLI option, therefore I suppose that it works automatically.

[jschintag]

@Silvanoc The patch works by replacing yubikey with an RPC interface. So instead of calling the HMS directly, notary will call the interface. So which HMS you are using depends on which Adapter you are running as a daemon. As mentioned above i have example imlementations for opencryptoki (https://github.com/jschintag/notary-opencryptoki-adapter) and yubikey (https://github.com/jschintag/notary-yubikey-adapter)

[garantir-km]

What is the benefit from switching from PKCS11, a very standard cryptographic interface, to RPC? If someone wants to integrate their RPC-enabled cryptograhic token, they can just provide a PKCS11 library to do so. However, forcing all other cryptographic tokens to have an RPC implementation/wrapper is just requiring more work for other use cases.

[jschintag]

I'm closing this PR since it is quite old and never really received attention from the maintainers