[Freeipa-devel] DNSSEC design page: key wrapping

[Jan Cholasta]

On 5.3.2014 05:10, Simo Sorce wrote:
> On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote:
>> 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...
>
> Yes this is the setting we are discussing, the actual specific
> discussion is how SSSD gets the information.
>
> Honza proposed to use a PKCS#11-like schema to store data in LDAP given
> DNS will need something similar, however the more we wandered into the
> discussion the more I got convinced the Vault is probably a better place
> to store this material than the LDAP tree itself at least for prvate
> keys.

I only proposed something that would work for my needs (i.e. storing 
certificates and associated trust policy) and would be ready for 4.0. 
Can you say the same thing about the vault?

>
> For public key material only though I am not sure a pkcs#11 schema will
> necessarily be useful. It might, but we do not use it for public SSH
> keys. And we also already have schema for public User or Servers X509
> certs.

Support for SSH public keys was implemented like 2 years ago, way before 
any talk about the vault or PKCS#11 even started. As for certs, the 
proposed schema works on top of RFC 4523, which is the cert schema you 
mention.

>
> We need to define something for DNS public keys, but they are already
> published in DNS Records too if I am not wrong, would that be sufficient
> as a storage for the public part ? I am assuming the private keys are
> stored in the Vault and they can be files in the format used by bind ?

So the information would be scattered in different places, using 
different formats and accessed using different protocols? I'm fine with 
that, but it is way beyond my original idea, so please let whoever is in 
charge of the vault implement the PKCS#11 module themselves.

>
> Simo.
>>


-- 
Jan Cholasta