[Freeipa-devel] DNSSEC design page

Petr Spacek pspacek at redhat.com
Tue Feb 25 10:08:20 UTC 2014


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




More information about the Freeipa-devel mailing list