[Freeipa-devel] DNSSEC design page: key wrapping

Petr Spacek pspacek at redhat.com
Tue Mar 4 22:30:46 UTC 2014


On 4.3.2014 23:18, Dmitri Pal wrote:
>> 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.
>
> Do we need it on the server and if so can it be exposed by the vault rather
> than via LDAP?
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:
> 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.
AFAIK that is exactly the plan.

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

-- 
Petr^2 Spacek




More information about the Freeipa-devel mailing list