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@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
