<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 03/12/2014 04:28 PM, Petr Spacek wrote: </div> <blockquote cite="mid:53207D0F.7020403@redhat.com" type="cite">On 12.3.2014 14:07, Ludwig Krispenz wrote: <blockquote type="cite"> On 03/12/2014 01:09 PM, Petr Spacek wrote: <blockquote type="cite">On 12.3.2014 12:12, Ludwig Krispenz wrote: <blockquote type="cite">On 03/11/2014 11:33 AM, Petr Spacek wrote: <blockquote type="cite">On 10.3.2014 12:08, Martin Kosek wrote: <blockquote type="cite">On 03/10/2014 11:49 AM, Petr Spacek wrote: <blockquote type="cite">On 7.3.2014 17:33, Dmitri Pal wrote: <blockquote type="cite">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. </blockquote> 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. </blockquote> +1, I also now see number of scenarios where Vault will be needed. <blockquote type="cite"> 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). <blockquote type="cite">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. </blockquote> 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" </blockquote> 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. </blockquote> 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. </blockquote> 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 </blockquote> I'm sorry for not being clear. The short-term plain is going to be executed without significant changes: <a class="moz-txt-link-freetext" href="https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm">https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm</a> This discussion is more about potential problems with upgrade from short-term solution to the long-term one - I'm updating <a class="moz-txt-link-freetext" href="https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm">https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm</a> 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. </blockquote> the schema proposal contains attributes for the metadata, so this should be </blockquote> 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. </blockquote> 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 <blockquote cite="mid:53207D0F.7020403@redhat.com" type="cite"> We don't have time to prepare schema & port OpenDNSSECv1 to LDAP backend. (Other aspect is that the schema is different for OpenDNSSEC v2.) <blockquote type="cite">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 </blockquote> Yes, we will have to have such script for upgrades from short-term -> long-term solution. <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ Freeipa-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-devel@redhat.com">Freeipa-devel@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-devel">https://www.redhat.com/mailman/listinfo/freeipa-devel</a></pre> </blockquote> </body> </html>