<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 03/04/2014 05:30 PM, Petr Spacek wrote: <blockquote cite="mid:53165416.50000@redhat.com" type="cite">On 4.3.2014 23:18, Dmitri Pal wrote: <blockquote type="cite"> <blockquote type="cite">We need PKCS#11 for CA certificates, BIND and OpenDNSSEC anyway so we need to design schema for *public* data. All private data can be stored in Vault if we agree on that. </blockquote> Do we need it on the server and if so can it be exposed by the vault rather than via LDAP? </blockquote> We need standard PKCS#11 interface because applications like BIND and OpenDNSSEC do not care about IPA-specifics. However applications see only PKCS#11 interface and nothing else, there could be LDAP or some other protocol behind the API. Honza's plan is to integrate PKCS#11 module to SSSD somehow so it will be available on all client machines, it will use caching facilities, fail-over etc. Replying to the other thread to join both threads to one: <blockquote type="cite">Also about PKCS#11 interface. I am all for PKCS#11 interface for client exposed from SSSD that uses whatever means to fetch the central keys it being SSH keys, gnome keyring keys or something else. </blockquote> AFAIK that is exactly the plan. <blockquote type="cite">I do not see a reason for IPA to expose a remote PKCS#11 interface. If we need a remote PKCS#11 interface (please insert why here) then it should be a part of the vault API rather than anything else. </blockquote> I'm not sure that I understand... PKCS#11 is just a set of functions, for an application it is a library. An application just calls the PKCS#11 API and knows nothing about implementation details so there is nothing like 'remote PKCS#11'. As I said above, SSSD will be behind scenes. Everything is local except the data storage in LDAP or vault, it doesn't matter. Maybe I misunderstood you, sorry. </blockquote> Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... <img src="cid:part1.00000603.09070008@redhat.com" alt=""> <pre class="moz-signature" cols="72">-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? <a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a> </pre> </body> </html>