On 24.2.2014 20:20, Simo Sorce wrote:
On Mon, 2014-02-24 at 13:11 +0100, Ludwig Krispenz wrote:
Hi,
here is a draft to start discussion. Lt me know if it is the right
direction and what you're missing.
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema
I think we need to think hard if you really can make all those
attributes a MUST for the private key, as not all the attributes seem to
apply to all encryption algorithms. Would have to have to add bogus
attributes in some cases.
Also can you add some examples on how we would use these classes to
store DNS keys ?
We need to think about it a bit more. We plan to use PKCS#11 for key
manipulation and data signing so the key itself will be unaware of any
DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary objectClass.
I'm discussing this with CZ.NIC guys and they propose to add a 'layer of
indirection' between DNS zones and keys so one key set can be used by more DNS
zones. They claim that it is relatively common practice and I trust them.
Note that I'm not saying that IPA should use one key for multiple DNS zones by
default, but the schema should be future-proof and allow that if necessary.
Let's start with this proposal:
DNS zone: idnsname=dnssec.test, cn=dns, dc=example
There will be multi-valued attribute idnsseckey pointing to DNs of keys stored
somewhere else.
Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns and store
keys there.
I expect that PKCS#11 module will handle keys scattered over the LDAP tree
somehow.
Ideally the example would show the LDAP tree and some example data in
detail, and also what operation we think would be common.
--
Petr^2 Spacek
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
