[Freeipa-devel] DNSSEC: LDAP schema requirements

Wed Mar 12 17:29:59 UTC 2014

On 03/12/2014 06:08 PM, Petr Spacek wrote:
> On 12.3.2014 16:54, Ludwig Krispenz wrote:
>>
>> On 03/12/2014 04:28 PM, Petr Spacek wrote:
>>> On 12.3.2014 14:07, Ludwig Krispenz wrote:
>>>>
>>>> On 03/12/2014 01:09 PM, Petr Spacek wrote:
>>>>> On 12.3.2014 12:12, Ludwig Krispenz wrote:
>>>>>> On 03/11/2014 11:33 AM, Petr Spacek wrote:
>>>>>>> On 10.3.2014 12:08, Martin Kosek wrote:
>>>>>>>> On 03/10/2014 11:49 AM, Petr Spacek wrote:
>>>>>>>>> On 7.3.2014 17:33, Dmitri Pal wrote:
>>>>>>>>>> I do not think it is the right architectural approach to try 
>>>>>>>>>> to fix a
>>>>>>>>>> specific
>>>>>>>>>> use case with one off solution while we already know that we 
>>>>>>>>>> need a key
>>>>>>>>>> storage.
>>>>>>>>>> I would rather do things right and reusable than jam them 
>>>>>>>>>> into the
>>>>>>>>>> currently
>>>>>>>>>> proposed release boundaries.
>>>>>>>>> I want to make clear that I'm not opposed to Vault in general. 
>>>>>>>>> I'm
>>>>>>>>> questioning
>>>>>>>>> the necessity of Vault from the beginning because it will 
>>>>>>>>> delay DNSSEC
>>>>>>>>> significantly.
>>>>>>>>
>>>>>>>> +1, I also now see number of scenarios where Vault will be needed.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> One of the proposals in this thread is to use something simple 
>>>>>>>>> for DNSSEC
>>>>>>>>> keys
>>>>>>>>> (with few lines of Python code) and migrate DNSSEC with Vault 
>>>>>>>>> when
>>>>>>>>> Vault is
>>>>>>>>> available and stable enough (in some later release).
>>>>>>>>>
>>>>>>>>>> I understand that Vault brings a lot of work to the table. 
>>>>>>>>>> But let us
>>>>>>>>>> do it
>>>>>>>>>> right and if it does not fit into 4.0 let us do it in 4.1.
>>>>>>>>> We will have one huge release with DNSSEC + Vault at once if 
>>>>>>>>> we to
>>>>>>>>> postpone
>>>>>>>>> DNSSEC to the same release as Vault.
>>>>>>>>>
>>>>>>>>> As a result, it would be harder to debug it because we will 
>>>>>>>>> have to
>>>>>>>>> find if
>>>>>>>>> something is broken because of:
>>>>>>>>> - DNSSEC-IPA integration
>>>>>>>>> - Vault-IPA integration
>>>>>>>>> - DNSSEC-Vault integration.
>>>>>>>>>
>>>>>>>>> I don't think it is a good idea to make such huge release.
>>>>>>>>>
>>>>>>>>> "Release early, release often"
>>>>>>>>>
>>>>>>>>
>>>>>>>> I must say I tend to agree with Petr. If the "poor man's 
>>>>>>>> solution" of
>>>>>>>> DNSSEC
>>>>>>>> without Vault does not cost us too much time and it would seem 
>>>>>>>> that the
>>>>>>>> Vault
>>>>>>>> is not going to squeeze in 4.0 deadlines, I would rather 
>>>>>>>> release the poor
>>>>>>>> man's
>>>>>>>> solution in 4.0 and switch to Vault when it's available in 4.1.
>>>>>>>>
>>>>>>>> This would let our users test the non-Vault parts of our DNSSEC 
>>>>>>>> solution
>>>>>>>> instead of waiting to test a perfect solution.
>>>>>>>
>>>>>>> Yesterday we have agreed that DNSSEC support is not going to 
>>>>>>> depend on
>>>>>>> Vault
>>>>>>> from the beginning and that we can migrate to Vault later.
>>>>>>>
>>>>>>> Here I'm proposing safe upgrade path from non-vault to Vault 
>>>>>>> solution.
>>>>>>>
>>>>>>> After all, it seems relatively easy.
>>>>>>>
>>>>>>> TL;DR version
>>>>>>> =============
>>>>>>> Use information in cn=masters to detect if there are old 
>>>>>>> replicas and
>>>>>>> temporarily convert new keys from Vault to LDAP storage (until 
>>>>>>> all old
>>>>>>> replicas are deleted).
>>>>>>>
>>>>>>> Full version
>>>>>>> ============
>>>>>>> IPA 4.0 is going to have OpenDNSSEC key generator on a single 
>>>>>>> IPA server
>>>>>>> and
>>>>>>> separate key import/export daemon (i.e. script called from cron or
>>>>>>> something
>>>>>>> like that) on all IPA servers.
>>>>>>>
>>>>>>> In 4.0, we can add new LDAP objects for DNSSEC-related IPA 
>>>>>>> services (please
>>>>>>> propose better names :-):
>>>>>>> - key generator:
>>>>>>> cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - key imported/exporter:
>>>>>>> cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Initial state before upgrade:
>>>>>>> - N IPA 4.0 replicas
>>>>>>> - N DNSSECKeyImporterv1 service instances (i.e. key distribution 
>>>>>>> for IPA
>>>>>>> 4.0)
>>>>>>> - 1 OpenDNSSECv1 service instance (key generator)
>>>>>>>
>>>>>>> Now we want to upgrade a first replica to IPA 4.1. For 
>>>>>>> simplicity, let's
>>>>>>> add
>>>>>>> a *requirement* to upgrade the replica with OpenDNSSECv1 first. 
>>>>>>> (We can
>>>>>>> generalize the procedure if this requirement is not acceptable.)
>>>>>>>
>>>>>>> Upgrade procedure:
>>>>>>> - stop OpenDNSSECv1 service
>>>>>>> - stop DNSSECKeyImporterv1 service
>>>>>>> - convert OpenDNSSECv1 database to OpenDNSSECv2
>>>>>>> This step is not related to Vault. We need to covert local 
>>>>>>> SQLite database
>>>>>>> from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC.
>>>>>> do we need to convert SQLite ? I thought in phase 1 we would have 
>>>>>> scripts
>>>>>> exporting from OpenDNSSEC database and store in ldap, then the 
>>>>>> data already
>>>>>> exist in ldap. We would ned to replace the sofhthsm module by our 
>>>>>> own pkcs11
>>>>>> module using ldap dn directly
>>>>>
>>>>> I'm sorry for not being clear.
>>>>>
>>>>> The short-term plain is going to be executed without significant 
>>>>> changes:
>>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This discussion is more about potential problems with upgrade from
>>>>> short-term solution to the long-term one - I'm updating
>>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm 
>>>>>
>>>>>
>>>>> right now.
>>>>>
>>>>> To answer your question about SQLite database:
>>>>> We will have *encryption keys* in LDAP already from the very 
>>>>> beginning
>>>>> (exported to LDAP by a script) so upgrade from export script to 
>>>>> PKCS#11
>>>>> module should be be smooth.
>>>>>
>>>>> The problem is with various metadata stored in OpenDNSSEC's 
>>>>> database so we
>>>>> will have to convert them to LDAP. In short-term we have neither 
>>>>> intent nor
>>>>> time to design a LDAP schema for OpenDNSSEC database, just for the 
>>>>> keys.
>>>> the schema proposal contains attributes for the metadata, so this 
>>>> should be
>>> The current schema stores only PKCS#11 metadata but nothing about
>>> key&signing policy and other DNSSEC-related stuff.
>>>
>>> We don't have complete schema and we don't have to have it now. Look 
>>> at the
>>> SQLite database in opendnssecv143.sqlite3.bz2 - it is pretty complex.
>> ok, so this is not the softhsm pkcs11 sqlite database, but  a db 
>> containing
>> other dnssec data, you didn't say that we need ldap schema for this 
>> and for
>> which subset of it
>
> I'm sorry for the confusion. Let me clarify it:
>
> For short-term we need this:
> ===========================
> 1) A future-proof schema for key material storage.
> This will be used by scripts in short-term and my PKCS#11 module in 
> long-term. It needs to be same. There is nothing specific to DNSSEC.
> This schema is being designed on
> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema
> (This is your original proposal - I have moved it to freeipa.org :-))
thanks, I will then do the updates there
>
> 2) Some minimal subset of DNSSEC-specific metadata required for 
> converting key material from LDAP to BIND key files as we already 
> discussed before. This will include just few timestamps, nothing huge.
> This small schema will be used by scripts in short-term and by 
> OpenDNSSEC in long-term. So we also need to design it in a 
> future-proof way but this should be relatively simple in comparison 
> with the PKCS#11 schema.
> There is no design page for it right now because I'm still looking 
> into OpenDNSSEC sources to make sure that I'm not missing something 
> important.
>
>
> For long-term we need this:
> ==========================
> 3) Prepare full LDAP schema for OpenDNSSEC v2 and migration scripts 
> from OpenDNSSEC v1 (with SQL backend) to v2 (with LDAP backend).
ok, this was not clear to me
>
> 4) (optionally) Prepare a schema amendment for PKCS#11 which will 
> allow us to store keys in Vault instead of plain LDAP. This will be 
> most probably one new objectClass for private keys or something like 
> that. Maybe we can design it now and make PKCS#11 to return 
> ENOTIMPLEMENTED if it encounters the new objectClass.
>
> Petr^2 Spacek
>
>>> We don't have time to prepare schema & port OpenDNSSECv1 to LDAP 
>>> backend.
>>> (Other aspect is that the schema is different for OpenDNSSEC v2.)
>>>
>>>> ok. But I think right now the export function available in 
>>>> opendnsssec/softhsm
>>>> only exports keys. We would have to have sql scripts to read and 
>>>> convert the
>>>> sqlite3 database
>>>
>>> Yes, we will have to have such script for upgrades from short-term ->
>>> long-term solution.
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel