Add PKCS#11 / p11-kit verifier for Linux

[zecakeh]

As mentioned in several places, the current problems with Linux are that the certificates are loaded only once and there are no trust decisions available.

Several distributions use p11-kit as a way to list certificates on the system and to list other PKCS#11 modules, and expose them via its API or a PKCS#11 proxy module. By interacting with it, we get an up-to-date list of certificates, and each certificate has a trust decision.

There is support for this in other TLS libraries:

• GnuTLS links p11-kit directly
• There is a PKCS#11 provider for OpenSSL, that uses p11-kit's proxy module by default.
• p11-kit can replace NSS's PKCS#11 module with its own.

[djc]

What are you trying to achieve exactly? What is the problem motivating your suggestion? Concretely, which (popular) distributions rely on p11-kit by default?

[zecakeh]

My use case is that we have a Linux desktop application that uses reqwest to make HTTP requests. With the current choice of TLS connectors, we cannot access user-provided certs in some environments. Particularly when the application is bundled with Flatpak, the only way to access user-provided certs on the system is to use p11-kit (although it is poorly documented). So for example users have a difficult time using proxies.

The distributions that I know use p11-kit by default (there might be others):

• Fedora, Red Hat, CentOS
• Arch Linux and derivatives

[djc]

@complexspaces have you run into issues with this kind of isolation at your employer?

Personally I'm not excited about doing FFI with a bunch of GLib-encumbered C code, but I agree that this might be a half way reasonable thing to do for these environments.

It doesn't inspire confidence that the link to PKCS #11 from the p11-kit homepage is broken (ends up at the rsa.com homepage) -- apparently it now lives at OASIS.

I'd be more interested in ways to have Rust versions of the code dealing with JSON/filesystem interfaces, but I guess that might mean we'd miss out on the C modules people are already using and installing? Do we know what kind of default installed modules one might encounter on Fedora, Red Hat or Arch Linux systems?

[ctz]

Since PKCS#11 can't do trust decisions¹ this would be more along the lines of rustls-native-certs (which hooks up assorted sources of root certs suitable for server authentication) than rustls-platform-verifier (which hooks up the platform's verifier API).

I think if we want to do something with PKCS#11, my strong preference would be to divest that interaction into a subprocess to keep them in their own resource and memory space. Arbitrary PKCS#11 providers are obviously of varying quality, and resource management in a dynamic library is notoriously fraught.

However, p11-kit provides some such programs that we could use as subprocesses, eg this:

$ trust extract --format pem-bundle --filter=ca-anchors --purpose=server-auth certs.pem
$ export SSL_CERT_FILE=certs.pem

Means rustls-native-certs will pick up those certs.

Footnotes

1. in other words, it cannot tell you if a certificate chain is valid for a particular purpose/name, only which certificates exist and what their properties are, and also let you verify signatures with them ↩