NetworkManager & PKCS#11 remoting

David Woodhouse dwmw2 at
Tue Jun 21 09:36:47 UTC 2016

On Tue, 2016-06-21 at 11:12 +0200, Nikos Mavrogiannopoulos wrote:
> I think this is what Lubomir is suggesting. He has a URL but doesn't
> necessarily have a module name. That's why he would like to use p11-kit 
> remote with a URL instead of specifying a specific module.

> My understanding is that he would like to make process A:
> p11-kit remote 'pkcs11:mykey'

That's... such a strange way of saying it that I suspect there's a

The existing p11-kit remote appears to the consumer as just a module. A
module which can have any number of slots. It typically works over SSH:

remote:|ssh root at shinybook p11-kit remote /usr/lib64/pkcs11/

It's strange to talk of using it "with a URL instead of specifying a
specific module". Yes, we'll use the loaded module with a URL, just as
we use *any* module with a URL to find the specific object we want.

But if we focus on just the remoting, it's still a *module*. The
question is *which* module shall be proxied by the providing side.

Lubomir wants to proxy just the *specific* module in which the desired
object (specified by the URI) is found. It's not clear how we'll *know*
that from the consumer side, since we can't know the contents of the
tokens until we've got access to them.

> and pass the "remote" file descriptors to process B. His problem (which
> his patches address) then in process B, as I understand it, is how to
> use these file descriptors as a proper PKCS#11 module.

This bit is easy enough. Instead of spawning a command like ssh, as
shown in the above config snippet, we want to use the same RPC protocol
over a pre-existing file descriptor. All that seems sane(ish; qv).

It's just the question of *which* module is being proxied.

-------------- 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