NetworkManager & PKCS#11 remoting

David Woodhouse dwmw2 at
Tue Jun 21 12:25:15 UTC 2016

On Mon, 2016-06-20 at 15:50 +0200, Lubomir Rintel wrote:
> The overall design & the prototype is described here; I'm wondering if
> it looks sane to you?
> Issues
> ======
> * p11-kit-remote requires a module name and what we have is a PKCS#11 URI
> * Need a way to make p11-kit use file descriptor

I think we've covered (or are talking about) those.

> * How do we tell if we have a p11-kit version that would be able to do the
>   above and fail sensibly instead of using a local p11-kit?

I suppose if we do this just by v-remote-fd in the URI, then it just
falls back to *not* remoting?

> * Do we need remoting for all PKCS#11 accesses? Probably not.

Almost certainly not. Some certs might actually be root-owned. In our
corporate setup I'm trying to move to a model where the cert is issued
to the AD *machine* account, never a specific user.

> * UI changes are not done. Need a certificate picker and a way to preserve the
>   file certificates for existing connections.

As you note, Tyagi is working on this. More eyes on it would be good.

> * Is there a file-backed PKCS#11 module that could be used with PEM files?

Well yes, we have nsspem because NSS can't deal with PEM files without
it. But it's cumbersome to use.

> * When using a GNOME Keyring software token it always asks for a PIN. Storing
>   the password to the keyring along with other secrets in NetworkManager is
>   perhaps a bad idea.

Hm, not quite. As I understand it, GNOME Keyring won't ever ask for a
PKCS#11 PIN. It supports the "keypad" login model where its C_Login()
method is invoked with NULL as a PIN, and it actually demands its
password out-of-band. Through the GNOME session.

> * Some VPN daemons are bad at using PKCS#11. OpenVPN doesn't seem to use
>   PKCS#11 for the CA certificate; Librewswan would need a way to pass the
>   p11-kit remoting fd through the control socket.

For the CA certificate it's a whole different game anyway. You have to
have interaction with the user there for the case where the server's
cert *isn't* "naturally" trusted and you need to ask the user. What you
want there is for OpenVPN to present the certificate it got from the
server, and ask you a simple yes/no question... and can't it already do
that through the management interface?

Note that OpenVpn also has a client cert and 'sign' method available
through the management interface, so you don't actually have to use its
PKCS#11 facilities at all. Perhaps the same model could work with
libreswan. I haven't actually looked at fixing libreswan.

wpa_supplicant, on the other hand, is basically already working with
PKCS#11. Not the remoting, but PKCS#11 tokens visible to root. See bug — the only remaining
problem is that we treat the PKCS#11 URI as if it were a filename and
abort because that "file" doesn't exist.

We'd want a new NM_SETTING_802_1X_CK_SCHEME_PKCS11_URI or something
like that, except it shouldn't be specific to 802.1x it should be a
generic way of describing a cert or key. And as well as the URI it
probably needs to contain the user to operate as (or none for no

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <>

More information about the p11-glue mailing list