Please make tuftool more HSM friendly

[udf2457]

At present, tuftool is largely written from the perspective of storing keys on-disk in files.

For people who use PKCS#11 (e.g. Yubikey) or cloud HSM (e.g AWS KSM or Azure KV) it would be very useful to be able to:

1. Load pubkey representations (i.e. provide DER or PEM file and it gets parsed into the correct format)
2. Load external signatures (I.e. provide hex signed string which gets parsed into correct format)

[zmrow]

Hi @udf2457 - thanks for the interest!

tuftool subcommands generally take a --key argument that allows you to use local files, AWS SSM/KMS. Additional sources are also possible, they would need to be implemented as additional crates, like the tough-ssm, and tough-kms creates in the repo.

[webern]

I don't quite understand the Yubikey use case well enough to understand if our current traits would support it. How would you use tuftool with a Yubikey?

[udf2457]

@webern TL;DR the Yubikey presents as PIV to the host, which means any compatible third-party tool that can be pointed to the libykcs11 library that Yubi provide, so taking ssh-keygen as an example, you could do:
ssh-keygen -s $name-9a.ssh.pub -D /usr/local/lib/libykcs11.dylib -I 9a -n $name -V -5m:+60m $userFil
(to sign an ssh cert using a key stored on a YubiKey).

I believe libykcs11 is basically a helper layer between PKCS#11 and any Yubi proprietary aspects (such as touch and/or PIN requirements which can be configured ... e.g. libykcs just makes sure the "wait for touch" is handled).

I think this is probably the correct starting page for more info about the lib: https://developers.yubico.com/yubico-piv-tool/YKCS11/

Note that I'm talking about the Yubikey here, rather than the (more expensive) Yubi HSM product which IIRC talks to the host in slightly different way (but I suspect like many people, I can't afford a Yubi HSM to play with !).

[webern]

I was searching for "rust" "libykcs11" and didn't come up with much. Even so, I'm thinking that library dependency wouldn't be something we would want to take on in the tuftool build. That makes me wonder if we could move to a plugin system so that not every key source would need to be compiled into the tuftool code (i.e. so that key types could be used with tuftool without forking the project).

[udf2457]

@webern Whilst I'm no subject-matter expert, I'd think perhaps "pkcs11" is what you ought to be searching for ?

Reverting back to my ssh-keygen example for a moment, given that ssh comes from the land of OpenBSD and with that their hard-core "open" stance, I would think it very unlikely that they did any YubiKey specific work. My guess instead is that libykcs11 presents a "standard" pkcs11 interface and what it does behind the scenes is not something for the developer to worry about.

The ssh-keygen man page for the -D flag certainly seems to imply this:

-D pkcs11
Download the public keys provided by the PKCS#11 shared library pkcs11. When used in combination with -s, this option indicates that a CA key resides in a PKCS#11 token

Whilst I agree wholeheartedly with your general suggestion of a plugin system to enable support for obscure sources, I would also argue the other side of the coin that PKCS#11 is perhaps worthy of first-class support ?

[udf2457]

@webern @zmrow

maybe this might be of interest: https://github.com/iqlusioninc/yubikey.rs

Also Yubico themselves publish something for use with the YubiHSM series : https://github.com/Yubico/yubihsmrs