NetworkManager & PKCS#11 remoting
dwmw2 at infradead.org
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/opensc-pkcs11.so
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...
Size: 5760 bytes
Desc: not available
More information about the p11-glue