[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