[Freeipa-devel] DNSSEC design page: key wrapping

[Jan Cholasta]

On 5.3.2014 14:21, Simo Sorce wrote:
> On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote:
>> On 5.3.2014 08:48, Jan Cholasta wrote:
>>> 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?
>> I agree with Honza. I think that proposed LDAP schema is perfectly fits the
>> purpose *for public* information like certificates and public keys.
>
> And I agree with you and Honza as well that the proposal is ok for
> *public* information.
>
>>>> 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
>> No, we need full PKCS#11 for OpenDNSSEC at least.
>
> Well, you need a pkcs#11 library interface, the backing store could be anything,
> but I do see the advantage of using a common schema so that SSSD can retrieve data
> to present through that interface in a simplified and consistent way.
>
>> Note that PKCS#11 in SSSD will give us generic mechanism for process/key
>> separation (it is practically the same thing GSS-Proxy, just general purpose).
>> This comes 'for free' if we implement PKCS#11 so please stop searching for
>> workarounds :-)
>
> I am not looking for workarounds for the interface between SSSD and
> consuming libraries. I am trying to evaluate what we could use this
> schema for before jumping into it.
>
>>>> stored in the Vault and they can be files in the format used by bind ?
>> BIND files are very hackish and we need to do PKCS#11->BIND files conversion
>> anyway because OpenDNSSEC supports only PKCS#11 and nothing else.
>>
>> I plan to use PKCS#11 directly from BIND so we can drop the format conversion
>> code and rely on pure PKCS#11 instead of bunch of hacks scripts.
>
> Ok.
>
>>> 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.
>
> Honza, clearly if something different is proposed work will be split
> between those that need to implement it in various ways, this will
> simply require to separate the pkcs#11 module into 2 parts, a 'feeder'
> that implements the pkcs#11 interface and a pluggable 'gatherer' that
> implements retrieval for specific stuff. No worries there.

Sounds good. (But I must admit I was a little bit scared for a moment :-)

>
>> - IMHO public information should be stored in LDAP schema as proposed.
>> - I agree that Vault is the right choice to store secrets.
>> - I propose to combine these two: Store public information in LDAP and store
>> private keys in PKCS#8 blob as a secret in Vault.
>> - This LDAP+Vault combo can be accessible over PKCS#11 interface.
>> - Note that this will work even without vault if you want to store public
>> information only (like CA certs and NSS trust objects).
>
> Works for me.

+1

>
>> The only problem is that we need to use REST API from SSSD. Plain LDAP is
>> already implemented in SSSD so it requires less code. I guess that we will
>> need something like libipavault library...
>
> We'll need a helper process unless we can find a fully async library to
> deal with the vault. Authentication to the vault over REST-like APIs
> will also be an interesting problem ...
>
> Simo.
>


-- 
Jan Cholasta