HSM besides Yubikey

[lewiada-zz]

Currently Notary will look for a Yubikey inserted into the USB drive. It also is using standard PKCS11. Is there anything that would prevent a different PKCS compliant HSM from being used?

In a DevOps pipeline, it would be great if we could use a combination of on-line / off-line root-keys such that a developer could initialize a new repo simply by authenticating to a service that hosts the HSM and request new tagging keys to be generated.

It would also be really great if the targets key could be stored in the HSM ... this way a Jenkins server that builds the images could sign the metadata without having a plaintext private key on disk or needing a human to touch the yubikey.

[riyazdf]

Hi @lewiada - we definitely agree that other HSMs would be useful! While the standard pkcs11 implementation in Notary should suffice for integrating with other HSMs, we haven't tested anything other than yubikeys and need to make sure that the integration will be compatible with other HSMs. We have a tracking issue for notary 1.0 #795

We also have a tracking issue for allowing storing keys for other roles in yubikeys #306 (and a first-crack WIP PR here: #653).

Is there any functionality not captured by these two issues that we should follow as an additional issue (or more detail to those issues themselves), or should I close this issue to dedupe?

[endophage]

I would also note that the Yubikey implementation uses one of the fields available for manufacturer custom behaviour (to enable the touch to sign feature), so simply pointing the existing code at a non-Yubikey HSM may have unexpected results as another manufacturer won't be using that field for the same thing. If they aren't using the field at all it could simply get ignored and work fine, or could cause some undefined behaviour. If they are using the the field for their own purposes, anything could happen.

[endophage]

Closing this as a duplicate of #795

Please feel free to continue the conversation on that issue.