Giters

smallstep / crypto

Crypto is a collection of packages used by Smallstep products

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Use p11-kit-proxy.so as default provider where available

dwmw2 opened this issue · comments

commented

Ideally, users shouldn't need to specify a module-path in the URI and we could omit it from most of the examples. Most *nix systems have p11-kit which provides a system-wide configuration for PKCS#11 providers, and modern packaging of providers will include a p11-kit module file which makes it visible automatically.

So all I need to do to use a certificate/key from my Yubikey for a VPN connection, for example, is

$ sudo dnf install opensc
$ openconnect vpn.example.com --certificate 'pkcs11:manufacturer=piv_II;id=%01'

Having to specify a module-path is the pathological case. And even when it's needed, it would usually be better to fix the missing p11-kit config instead.

commented

What makes more sense is to automatically locate p11-kit-client.so if the environment variable P11_KIT_SERVER_ADDRESS is set and use that as the module-path. The token label, serial or slot-id would still be necessary.

Here are some locations on some systems:

  • macOs (homebrew): /usr/local/lib/pkcs11/p11-kit-client.so
  • Fedora (amd64): /usr/lib64/pkcs11/p11-kit-client.so
  • Debian (arm64): /usr/lib/aarch64-linux-gnu/pkcs11/p11-kit-client.so
  • Debian (armel): /usr/lib/arm-linux-gnueabi/pkcs11/p11-kit-client.so
  • Debian (armhf): /usr/lib/arm-linux-gnueabihf/pkcs11/p11-kit-client.so
  • Debian (i386): /usr/lib/i386-linux-gnu/pkcs11/p11-kit-client.so
  • Debian (mips): /usr/lib/mips-linux-gnu/pkcs11/p11-kit-client.so
  • Debian (mips64el): /usr/lib/mips64el-linux-gnuabi64/pkcs11/p11-kit-client.so
  • Debian (mipsel): /usr/lib/mipsel-linux-gnu/pkcs11/p11-kit-client.so
  • Debian (ppc64el): /usr/lib/powerpc64le-linux-gnu/pkcs11/p11-kit-client.so
  • Debian (s390x): /usr/lib/s390x-linux-gnu/pkcs11/p11-kit-client.so
  • Debian (amd64): /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-client.so
  • Alpine (all): /usr/lib/pkcs11/p11-kit-client.so
  • Arch Linux (amd64): /usr/lib/pkcs11/p11-kit-client.so
  • Arch Linux (amd64): /usr/lib32/pkcs11/p11-kit-client.so
  • Others ...
commented

What makes more sense is to automatically locate p11-kit-client.so if the environment variable P11_KIT_SERVER_ADDRESS is set and use that as the module-path.

p11-kit-client.so and $P11_KIT_SERVER_ADDRESS are for something different; they're for remote access to a token.

We're after p11-kit-proxy.so which is a single provider that makes all the system-configured tokens available.

The module-path for it can be found from pkg-config, e.g.:

 $ pkg-config --variable=proxy_module p11-kit-1
/usr/lib/x86_64-linux-gnu/p11-kit-proxy.so

It's normally just in $(libdir) so it can be found easily on the library path. As I was playing with aws/rolesanywhere-credential-helper#34 I found that literally just p11-kit-proxy.so worked with no path.

The token label, serial or slot-id would still be necessary.

The PKCS#11 URI includes those.

Strictly speaking, in many cases it isn't actually necessary for the user to specify the token. Since certs generally don't have the CKA_PRIVATE attribute set, you can iterate over the available slots without logging in, and find a cert by its CKA_LABEL or CKA_ID. Then it's reasonable to assume that you will find the key in that same token if you log in to it.

cf. http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.8

commented

Thanks, @dwmw2. I never used p11-kit before and I looked at the p11-kit manual and they only mentioned the client library, and I got it working, so I assumed that.

commented

Strictly speaking, in many cases it isn't actually necessary for the user to specify the token. Since certs generally don't have the CKA_PRIVATE attribute set, you can iterate over the available slots without logging in, and find a cert by its CKA_LABEL or CKA_ID. Then it's reasonable to assume that you will find the key in that same token if you log in to it.

The high-level library that we use doesn't allow it. It can be possible to implement it directly using github.com/miekg/pkcs11, but for the current purpose of this library, I prefer to be explicit about it. However, supporting multiple tokens simultaneously might be added in the future.

commented

The high-level library that we use doesn't allow it. It can be possible to implement it directly using github.com/miekg/pkcs11, but for the current purpose of this library, I prefer to be explicit about it. However, supporting multiple tokens simultaneously might be added in the future.

Understood. Since you're using the PKCS#11 URI to specify the token rather than forcing the user to use some weird separate configuration, that's fair enough.