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 misunderstanding. 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@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. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ p11-glue mailing list p11-glue@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/p11-glue
