Enabling notary for other PKCS#11 users than Yubikey

[florianeichin]

The only hardware that notary supports as trustmanager is Yubikey. We would like to extend notary to support other devices that work according to PKCS#11 -- and for our case add support for devices that are used through the opencryptoki library. Our suggestion is to split this up into two steps:

1. Create an abstraction for pkcs11 (and move Yubikey in there).
2. add opencryptoki support

So essentially this results in a file structure like the following:

├─trustmanager 
│     ├─pkcs11
│     │   ├─yubikey
│     │   └─ opencryptoki

Other PKCS#11 exploiters can hook in at the level below PKCS#11. To keep enablement of other PKCS#11 trustmanagers simple in general, we think it would make sense, to abstract some of the yubikey files and code pieces to reuse them.
The abstraction could go that far, that just the following yubikeystore functions have to stay hardware specific, everything else could be reused by opencryptoki and other pkcs11 implementations:

• getECDSAKey(),
• addECDSAKey(),
• yubiRemoveKey(),
• Sign(),
• hardwareListKey(),
• listObjects(),
• SetupHSMEnv()

An (IMHO bad) alternative is to clone the entire trustmanager, which would create a lot of redundant code.
Prior to a PR, we wanted to discuss this structure. If the above approach sounds good to everyone, a PR with code will follow.

Related Issues:
#795
#957

[utzb]

@endophage @riyazdf could you PTAL whether this approach is good to go for a PR?

[endophage]

This is very closely aligned with what I've been wanting to do with our PKCS#11 support. As part of this it would also be great to address the fact that we only support root keys in hardware today. We should eventually support all keys in hardware.

[florianeichin]

That sounds great. We would suggest to setup a PR, containing two commits.

1. Abstraction and refactoring of the existing yubikey #PKCS11 implementation
2. Implementation of opencryptoki as a second trustmanager besides yubikey

If you're fine with that, we would setup the PR.

[optnfast]

I am also interested in improving HSM support in Notary. The approach I had in mind was a generic pkcs11 key store rather than one tied to a particular provider, described at https://gist.github.com/nfewx/839327740b1355f6fd2c9d36aa790190.

[jschintag]

To further seperate the specific HSM from notary i thought about 2 possible ways:

1. Using Go-Plugin

The Idea is to dynamically load the HSM implementation during runtime as an external library.
Unfortunatley Go Plugin does not wrk together with the vendor system:
golang/go#30838
The suggested approach with the experimental Go-Modules didn't work for me, as there seems to be a Problem with having Imports from notary. This seems to be a known issue golang/go#27751
A Solution would be to wait and see if it is fixed in Go1.13, when they Plan to support Modules.

2. Plugin over GRPC

The HSM would be available for notary via a unix socket. It could potentially also be used over a TCP-Socket on a remote machine.

[jschintag]

@endophage @justincormack can i get your input on this?

[justincormack]

I think RPC is the best option. I am actually in early stages of design for an RPC based API for hardware operations (not gRPC as one of the use cases is to support embedded systems) as well. It makes the code much more decoupled.

[jschintag]

@justincormack I started seperating the openCryptoki code with Go RPC. My Question is, do you want to keep yubikey inside the Notary Code or seperate it as well? If so, do you Plan to keep the decoupled code inside the Notary Repository or split it into seperate ones?

[justincormack]

I would be in favour of moving it out as well, it is more consistent.

[endophage]

To provide a counterpoint, it's much easier to use things like Yubikeys when you're not required to install and possibly configure extra services. To support hardware on servers, RPC seems fine, but for individual CLI users, it feels like an additional barrier.

[jschintag]

Then the easiest way for individual CLI users would be Go-Plugin. They would only have to choose the right Plugin for their Hardware. But unfortunately Plugins currently don't work this way.

[jschintag]

@endophage @justincormack I have developed a prototype with the RPC approach. #1465

What are your thoughts?
The HSM implementations are here:
https://github.com/jschintag/notary-yubikey-adapter
https://github.com/jschintag/notary-opencryptoki-adapter

[stafwag]

There is even a PR that add support for other HSM's

#1369

But this PR seem to be blocked...